Restart method and device of embedded system, electronic equipment and readable storage medium

Abstract

Embodiments of the present application provide a kind of embedded system's restart method, device, electronic equipment and readable storage medium, belong to embedded system technical field.The method includes: boot program loads the file of operating partition, judges whether operating partition exists abnormal file;Boot program judges whether the restart of embedded system is triggered by watchdog or Linux panic according to the state value of register;If the restart of embedded system is triggered by watchdog or Linux panic, then the abnormal restart number recorded by counter is added 1;If abnormal restart number exceeds threshold value, boot program reads the state value and position index information of register, switches current operating partition to corresponding target backup partition, and restarts embedded system.Through the restart scheme of embedded system, operating partition containing abnormal file is switched to corresponding target backup partition, and embedded system is restarted, which increases the restart probability of embedded system.

Description

Technical Field

[0001] This application relates to the field of embedded systems, and more particularly to a method, apparatus, electronic device, and readable storage medium for restarting an embedded system. Background Technology

[0002] Currently, with the popularization of broadband access, more and more network terminal devices are being introduced into home and enterprise networks. Due to application scenarios and security factors, larger storage and more frequent software updates are required. This can easily lead to problems such as the embedded system failing to boot due to corrupted files required for the embedded system to start after storage device or software updates. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, electronic device, and readable storage medium for restarting an embedded system.

[0004] In a first aspect, embodiments of this application provide a method for restarting an embedded system, applied to an embedded system including a memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers have built-in location index information, which is used to indicate the association between the running partitions and the backup partitions. The method includes:

[0005] The bootloader loads the files in the running partition and determines whether there are any abnormal files in the running partition.

[0006] If the abnormal file exists in the running partition, the embedded system will trigger a restart, set the status value of the register, and load the boot program;

[0007] The bootloader determines whether the restart of the embedded system is triggered by a watchdog timer or a Linux panic based on the status value of the register.

[0008] If the restart of the embedded system is triggered by a watchdog timer or a Linux panic, the number of abnormal restarts recorded by the counter is incremented by 1;

[0009] If the number of abnormal restarts exceeds the abnormal restart threshold, the bootloader reads the status value of the register and the location index information, switches the running partition to the corresponding target backup partition, and restarts the embedded system.

[0010] In one embodiment, the bootloader loads the running partition and determines whether there are abnormal files in the running partition, including:

[0011] The bootloader reads the checksum value and obtains the total file length and file byte data;

[0012] Determine whether the sum of the total file length and the file byte data is equal to the checksum value;

[0013] If the sum of the total file length and the file byte data is not equal to the checksum value, then the running partition contains the abnormal file.

[0014] In one embodiment, the method further includes:

[0015] After the embedded system completes startup, it copies the normal files from the target backup partition to the running partition according to the location index information, replacing the abnormal files in the running partition.

[0016] In one embodiment, the method further includes:

[0017] After the embedded system completes startup, if the embedded system is not restarted by the watchdog or Linux panic within a preset time interval, the number of abnormal restarts will be reset to zero.

[0018] In one embodiment, after the embedded system completes its startup, the method further includes:

[0019] A dedicated partition is set up in the memory. If abnormal information is generated during the operation of the embedded system, the abnormal information is input into the dedicated partition and saved.

[0020] In one embodiment, the method further includes:

[0021] After the embedded system restarts, it receives log collection instructions and log return instructions from a third-party server via SNMP.

[0022] The embedded system parses the log collection instruction, collects the exception information from the dedicated partition, and generates a log.

[0023] The embedded system parses the log transmission command and transmits the log back to the third-party server at fixed intervals.

[0024] In one embodiment, the logs are divided according to severity level, and the third-party server selects which logs to receive based on the severity level.

[0025] The third-party server reads the exception information from the log through the SNMP MIB node.

[0026] Secondly, embodiments of this application provide a reboot device for an embedded system, applied to an embedded system including a memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers have built-in location index information, which is used to indicate the association between the running partitions and the backup partitions. The device includes:

[0027] The first judgment module is used by the boot program to load the files of the running partition and determine whether there are abnormal files in the running partition;

[0028] The second judgment module is used to trigger a restart of the embedded system if the abnormal file exists in the running partition, set the status value of the register, and load the boot program. The boot program determines whether the restart of the embedded system is triggered by a watchdog or a Linux panic based on the status value of the register.

[0029] The counting module increments the number of abnormal restarts recorded by the counter by 1 if the restart of the embedded system is triggered by a watchdog timer or a Linux panic.

[0030] The restart module is used to, if the number of abnormal restarts exceeds the abnormal restart threshold, have the bootloader read the status value of the register and the location index information, switch the running partition to the corresponding target backup partition, and restart the embedded system.

[0031] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory is used to store a computer program, and the computer program executes the embedded system restart method provided in the first aspect when the processor is running.

[0032] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a processor, executes the embedded system restart method provided in the first aspect.

[0033] The embedded system restart method provided in this application is applied to an embedded system, which includes a memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers contain built-in location index information, which indicates the association between the running partitions and the backup partitions. The method includes: the bootloader loading files from the running partitions and determining whether there are any abnormal files in the running partitions; if the abnormal files exist in the running partitions, the embedded system triggers a restart, sets the status value of the registers, and loads the bootloader; the bootloader determines whether the restart of the embedded system is triggered by a watchdog timer or a Linux panic based on the status value of the registers; if the restart of the embedded system is triggered by a watchdog timer or a Linux panic, the number of abnormal restarts recorded by the counter is incremented by 1; if the number of abnormal restarts exceeds an abnormal restart threshold, the bootloader reads the status value of the registers and the location index information, switches the running partition to the corresponding target backup partition, and restarts the embedded system. By switching the running partition containing the abnormal files to the corresponding target backup partition and restarting the embedded system, the restart probability of the embedded system is increased. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be considered as a limitation on the scope of protection of this application. In the various drawings, similar components are numbered similarly.

[0035] Figure 1 This paper illustrates a flowchart of a method for restarting an embedded system according to an embodiment of this application.

[0036] Figure 2 This illustration shows yet another flowchart of the method for restarting an embedded system provided in an embodiment of this application;

[0037] Figure 3 A schematic diagram of the structure of a restart device for an embedded system provided in an embodiment of this application is shown.

[0038] Icons: 300 - Reboot device for embedded system, 301 - First judgment module, 302 - Second judgment module, 303 - Counting module, 304 - Reboot module. Detailed Implementation

[0039] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0040] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0041] In the following, the terms “comprising,” “having,” and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as excluding, firstly, the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations thereof.

[0042] Furthermore, the terms "first," "second," and "third" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0043] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0044] Example 1

[0045] This application provides a method for restarting an embedded system.

[0046] See Figure 1 A method for restarting an embedded system, applied to an embedded system including a memory, registers, a bootloader, and a counter, wherein the memory includes multiple running partitions and multiple backup partitions, the registers have built-in location index information, the location index information being used to indicate the association between the running partitions and the backup partitions, and the method includes:

[0047] S101: The bootloader loads the files in the running partition and determines whether there are any abnormal files in the running partition;

[0048] In this embodiment, the multiple running partitions include three running partitions: Linux kernel, device tree, and file system. The Linux kernel is the operating system kernel of the embedded system, providing the basic functions and resource management of the operating system. The kernel is responsible for managing hardware resources, memory, file system, and network connections, and provides low-level services such as system call interfaces and drivers. The device tree partition is a data structure used to describe hardware configuration and device information. It is represented in a tree structure and contains configuration information of various hardware devices in the embedded system, such as processors, memory, hard disks, and graphics cards. In the Linux system, the device tree is usually used to pass hardware information to the Linux kernel when the embedded system starts up, so that the kernel can correctly configure and initialize the hardware devices. The file system is the core file system of the Linux system, containing the files and directories necessary for the operating system to run. It includes key programs and library files required when the system starts up, as well as user data files and applications. The bootloader is usually loaded first in the embedded system. It is responsible for tasks such as initializing hardware, loading the operating system kernel, and initializing the file system.

[0049] In this embodiment, when the embedded system starts, the bootloader runs first. It is responsible for initializing hardware devices, loading the device tree and Linux kernel. The bootloader reads the device tree and Linux kernel from the storage device into memory one after the other by specifying the storage location and size of the device tree and Linux kernel image, and transfers control from itself to the Linux kernel. Once the Linux kernel image is loaded into memory, the bootloader will hand over control to the Linux kernel, and the Linux kernel will start executing subsequent programs. The bootloader can also initialize hardware devices and file systems. If there are abnormal information when loading the Linux kernel, device tree, or file system, loading the running partition may fail, which will cause the embedded system's operating system to fail to load.

[0050] S102: If the abnormal file exists in the running partition, the embedded system triggers a restart, sets the status value of the register, and loads the bootloader; the bootloader determines whether the restart of the embedded system is triggered by a watchdog or a Linux panic based on the status value of the register.

[0051] In this embodiment, if an abnormal file fails to load the running partition, the embedded system will trigger a restart and set the status values ​​of the registers accordingly. For example, if device tree initialization fails, the embedded system will set the status values ​​of the device tree-related registers, changing the register bits. For instance, register bit 0 indicates that the files in the device tree partition are normal, while register bit 1 indicates that there are abnormal files in the device tree partition. By checking the register status, it can be determined whether there are erroneous files during device tree initialization. After setting the register status values ​​accordingly, the bootloader begins loading. The bootloader has a built-in checker that can check whether the embedded system's restart is triggered by the watchdog timer based on the register status values. It should be noted that in the embedded system, the watchdog timer can be set to be in a dormant state during normal operation. When the embedded system fails to load the running partition such as the Linux kernel, the watchdog timer will be awakened, and the embedded system will restart abnormally. Linux panic is a serious error in the Linux kernel. If a Linux panic error is encountered when the bootloader is loading the Linux kernel, the Linux panic prevents the Linux kernel from being loaded further, causing the embedded system to restart. The bootloader will then attempt to reload the backup partition of the Linux kernel. It should be noted that OOPS or OOM errors may occur during the bootloader's loading of the Linux kernel. Different handling methods are usually adopted depending on the type and severity of the error. In some cases, the bootloader will attempt to repair or handle OOPS or OOM errors so that it can load the Linux kernel normally.

[0052] S103: If the restart of the embedded system is triggered by a watchdog timer or a Linux panic, the number of abnormal restarts recorded by the counter is incremented by 1;

[0053] In this embodiment, if the restart of the embedded system is triggered by a watchdog timer, a counter is used to record the number of abnormal restarts of the embedded system. This counter can be an independent hardware register in the embedded system or a counter variable implemented in software in the embedded system. In this embodiment, no limitation is made. When the watchdog timer triggers a restart operation, the counter will automatically increment by 1 to record the number of abnormal restarts of the embedded system.

[0054] S104: If the number of abnormal restarts exceeds the abnormal restart threshold, the bootloader reads the status value of the register and the location index information, switches the running partition to the corresponding target backup partition, and restarts the embedded system.

[0055] In this embodiment, the register stores the location index information of the running partition and the backup partition in memory, as well as the status information of whether there are abnormal files in the running partition. This information includes the type, format, size, and start and end addresses of the files in the running partition in memory. When the number of abnormal restarts of the embedded system exceeds the abnormal restart threshold, the embedded system reloads the bootloader. The bootloader reads the running partition status information in the register and the location index information of the running partition and the backup partition, and switches the running partition to the corresponding target backup partition. For example, the bootloader determines the status of the running partition and the backup partition based on the register status value. If there are abnormal files in the running partition, the bootloader reloads the backup partition of the running partition according to the location index information. In this way, if a file abnormality occurs when the embedded system loads and starts the running partition, it automatically switches to the target backup partition corresponding to the running partition and reloads the code and data that can run normally in the backup partition. This helps improve the reliability and stability of the embedded system and reduces the possibility of the embedded system failing to run normally due to problems with the running partition, such as the file system.

[0056] In one embodiment, the bootloader loads the running partition and determines whether there are abnormal files in the running partition, including: the bootloader reads the checksum value and obtains the total file length data and file byte data; determines whether the sum of the total file length data and the file byte data is equal to the checksum value; if the sum of the total file length data and the file byte data is not equal to the checksum value, then there are abnormal files in the running partition.

[0057] In this embodiment, the first step is to read the total length and size of the file. This information can be obtained by using system commands provided by the embedded system. For example, the "stat" command can be used to obtain the total length and size of the file. Next, the method calculates the sum of the byte data of the total length and size of the file and compares it with the checksum value pre-stored in the bootloader. The checksum value is used to check the integrity and consistency of the data in the file. If the sum of the byte data of the file length and size does not match the checksum value, it means that there is an anomaly in the file in the running partition, and the file may have been modified or corrupted.

[0058] In one embodiment, after the embedded system completes startup, it copies the normal files of the target backup partition to the running partition according to the location index information, replacing the abnormal files in the running partition.

[0059] In this embodiment, the register stores the location index information of the running partition and the backup partition in the memory, including the file type, format, size, and start and end addresses in the memory. Based on the location index information, file read and write operations are used to read normal file content from the backup partition, write the normal file content to the running partition, and replace the abnormal file in the original running partition.

[0060] In one embodiment, after the embedded system completes startup, if the embedded system is not restarted by the watchdog or Linux panic within a preset time interval, the abnormal restart count is reset to zero.

[0061] In this embodiment, if the embedded system does not restart within a predetermined time interval due to a watchdog timer or Linux panic while maintaining a stable network state, it indicates that the embedded system is running stably during this time. In this case, the number of abnormal restarts needs to be reset to zero so that the next time an abnormal file appears in the partition, triggering a watchdog timer or Linux panic and causing the embedded system to restart, the counter can recount the number of abnormal restarts and correctly determine the number of times the threshold has been reached. It should be noted that the predetermined time interval is generally a time interval of five minutes or ten minutes.

[0062] In one embodiment, after the embedded system has started up, the method further includes: setting a special partition in the memory, and if abnormal information is generated during the operation of the embedded system, inputting the abnormal information into the special partition and saving it.

[0063] In this embodiment, a dedicated partition is set up in the memory. This dedicated partition can take various forms, such as a separate folder, disk partition, or database. Within this dedicated partition, abnormal information can be organized according to certain rules or strategies, such as categorizing and storing it based on the type of abnormal information, timestamps, or other identifiers. Setting up a dedicated partition in the memory provides an independent and secure storage environment specifically for storing abnormal information that occurs after the embedded system has been running. This prevents other abnormal information from being accidentally overwritten or deleted, while improving the efficiency of processing abnormal information. Once abnormal information is detected during normal operation of the embedded system, it can be input into the dedicated partition and saved. This process can be implemented through programming. After saving the abnormal information, the operating status of the embedded system can continue to be monitored, and new abnormal information can be collected. If new abnormal information is detected, the above process can be repeated to save it to the dedicated partition. This allows for the gradual accumulation and retention of the embedded system's historical records for subsequent analysis, troubleshooting, and incident handling.

[0064] In one embodiment, refer to Figure 2 Methods for restarting embedded systems also include:

[0065] S105: After the embedded system restarts, the embedded system receives log collection instructions and log return instructions from a third-party server via SNMP;

[0066] In this embodiment, after the embedded system restarts, it receives log collection and log return commands from a third-party server via Simple Network Management Protocol (SNMP). In issuing the log collection command, the third-party server uses an SNMP GET request message to send the command to the embedded system. This message may contain a specific Object Identifier (OID) to specify the type or entry of logs to be collected. In issuing the log return command, the embedded system encapsulates the retrieved log entries into an SNMP response message and sends it back to the third-party server. This response message may contain a specific OID to identify the returned log entry.

[0067] S106: The embedded system parses the log collection instruction, collects exception information from the dedicated partition, and generates a log;

[0068] In this embodiment, after the embedded system receives the log collection instruction from the SNMP request message, it uses the corresponding parsing algorithm to parse the log collection instruction in the SNMP request message. It parses the OID and extracts the log entries corresponding to the specified OID to determine the type, level, and source of the abnormal information that needs to be collected from a special partition.

[0069] S107: The embedded system parses the log transmission instruction and transmits the log back to the third-party server at fixed intervals.

[0070] In this embodiment, the embedded system uses a corresponding parsing algorithm to parse the received log return command. This command includes information such as the target server address, port number, and transmission protocol. After receiving the log collection command issued by the third-party server via SNMP, the embedded system extracts the specified log entries to be returned, processes or stores them, encapsulates the retrieved log entries into an SNMP response message, and sends these log entries back to the third-party server via the log return command according to a preset time interval. This time interval can be fixed or dynamically adjusted according to system load or other factors; it is not limited in this embodiment.

[0071] In one embodiment, the logs are divided according to severity level, and the third-party server selects which logs to receive based on the severity level; the third-party server reads exception information from the logs through the SNMP MIB node.

[0072] In this embodiment, after categorizing logs according to severity levels, the severity levels include: Critical Errors (which require timely handling and repair); Errors (which require timely handling but not immediate repair); Warnings (which require timely attention and handling to prevent further escalation of the problem); and Information (which can be used to monitor the system's operational status but does not require special processing). Third-party servers can choose to receive logs of different severity levels as needed. For example, if a third-party server only needs to receive logs of critical errors and error levels, it can choose to receive only those levels and ignore other levels, thus reducing the amount of logs received and improving processing efficiency.

[0073] In this embodiment, log information is encapsulated into a Management Information Base (MIB) via SNMP, allowing it to be accessed and managed by the SNMP protocol, thus enabling third-party servers to read exception information from the logs. Specifically, the OID of the HwResetReason node corresponds to the hardware reset reason; the OID of the ResetReasonLogTable node corresponds to the reset reason log table, which contains multiple reset reason log entries, each recording information such as the reason and time of the embedded system reset; the OID of the ResetReasonLogEntry node corresponds to a single entry in the reset reason log table, such as the reason and time information; the OID of the ResetReasonLogIndex node corresponds to the index of the device reset reason log table; and the OID of the ResetReasonLogText node corresponds to the specific reset reason text content. The third-party server uses the ResetReasonLogText node to obtain the specific text description of the entry, such as the reason for the embedded system reset.

[0074] This embodiment provides a method for restarting an embedded system. The embedded system includes a memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers contain built-in location index information, which indicates the association between the running partitions and the backup partitions. The method includes: the bootloader loading files from the running partitions and determining if any abnormal files exist in the running partitions; if the abnormal files exist, the embedded system triggers a restart, sets the status value of the registers, and loads the bootloader; the bootloader determines whether the restart is triggered by a watchdog timer or a Linux panic based on the register status value; if the restart is triggered by a watchdog timer or a Linux panic, the counter increments the number of abnormal restarts; if the number of abnormal restarts exceeds an abnormal restart threshold, the bootloader reads the register status value and the location index information, switches the running partition to the corresponding target backup partition, and restarts the embedded system. By switching the running partition containing abnormal files to the corresponding target backup partition and restarting the embedded system, the restart probability of the embedded system is increased.

[0075] Example 2

[0076] Furthermore, this application provides a restart device for an embedded system, which is applied to the embedded system. The embedded system includes a memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers have built-in location index information, which is used to indicate the association between the running partitions and the backup partitions.

[0077] like Figure 3 As shown, the restart device 300 of the embedded system includes:

[0078] The first judgment module 301 is used for the boot program to load the files of the running partition and determine whether there are abnormal files in the running partition;

[0079] The second judgment module 302 is used to trigger a restart of the embedded system if the abnormal file exists in the running partition, set the status value of the register, and load the boot program. The boot program determines whether the restart of the embedded system is triggered by a watchdog or a Linux panic based on the status value of the register.

[0080] The counting module 303 is used to increment the number of abnormal restarts recorded by the counter by 1 if the restart of the embedded system is triggered by a watchdog or a Linux panic.

[0081] The restart module 304 is used to, if the number of abnormal restarts exceeds the abnormal restart threshold, have the boot program read the status value of the register and the location index information, switch the running partition to the corresponding target backup partition, and restart the embedded system.

[0082] The first judgment module 301 is further configured to load the running partition by the boot program and determine whether there are abnormal files in the running partition, including: the boot program reads the checksum value and obtains the total file length data and file byte data; determines whether the sum of the total file length data and the file byte data is equal to the checksum value; if the sum of the total file length data and the file byte data is not equal to the checksum value, then there are abnormal files in the running partition.

[0083] The restart module 304 is further configured to, after the embedded system completes startup, copy the normal files of the target backup partition to the running partition according to the location index information, replacing the abnormal files in the running partition; after the embedded system completes startup, if the embedded system is not restarted by a watchdog or Linux panic within a preset time interval, the number of abnormal restarts is reset to zero; after the embedded system completes startup, a special partition is set in the memory, and if abnormal information is generated during the operation of the embedded system, the abnormal information is input into the special partition and saved.

[0084] The restart module 304 is further configured to: after the embedded system restarts, receive log collection instructions and log return instructions from a third-party server via SNMP; parse the log collection instructions, collect exception information from the dedicated partition, and generate logs; parse the log return instructions, and return the logs to the third-party server at fixed intervals; classify the logs according to severity levels, and the third-party server selects which logs to receive based on the severity level; and read exception information from the logs via the SNMP MIB node.

[0085] The embedded system restart device 300 provided in this embodiment can implement the embedded system restart method provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0086] The embedded system restart device provided in this embodiment is applied to an embedded system, which includes a memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers contain built-in location index information, which indicates the association between the running partitions and the backup partitions. The bootloader loads files from the running partitions and determines whether there are any abnormal files in the running partitions. If the abnormal files are present in the running partitions, the embedded system triggers a restart, sets the status value of the registers, and loads the bootloader. The bootloader determines whether the restart of the embedded system is triggered by a watchdog timer or a Linux panic based on the status value of the registers. If the restart is triggered by a watchdog timer or a Linux panic, the number of abnormal restarts recorded by the counter is incremented by 1. If the number of abnormal restarts exceeds the abnormal restart threshold, the bootloader reads the status value of the registers and the location index information, switches the running partition to the corresponding target backup partition, and restarts the embedded system. By switching the running partition containing abnormal files to the corresponding target backup partition and restarting the embedded system, this device increases the probability of restarting the embedded system.

[0087] Example 3

[0088] Furthermore, this application provides an electronic device, including a memory and a processor. The memory stores a computer program, and the computer program executes the embedded system restart method provided in Embodiment 1 when it runs on the processor.

[0089] The electronic device provided in this embodiment can implement the restart method of the embedded system provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0090] Example 4

[0091] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the restart method of the embedded system provided in Embodiment 1.

[0092] In this embodiment, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0093] The computer-readable storage medium provided in this embodiment can implement the restart method of the embedded system provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0094] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0095] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. 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 (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0096] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for restarting an embedded system, characterized in that, The method is applied to an embedded system, which includes memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers contain built-in location index information, which indicates the association between the running partitions and the backup partitions. This location index information includes the file type, format, size, and start and end addresses in the memory. The multiple running partitions include a Linux kernel running partition, a device tree running partition, and a file system running partition. The bootloader loads the files in the running partition and determines whether there are any abnormal files in the running partition. If the abnormal file exists in the running partition, the embedded system triggers a restart, sets the register status value related to the running partition where the abnormal file is located, and loads the boot program; The bootloader determines whether the restart of the embedded system is triggered by a watchdog timer or a Linux panic based on the status value of the register. If the restart of the embedded system is triggered by a watchdog timer or a Linux panic, the number of abnormal restarts recorded by the counter is incremented by 1; If the number of abnormal restarts exceeds the abnormal restart threshold, the bootloader reads the status value of the register and the location index information, switches the running partition to the corresponding target backup partition, and restarts the embedded system. The bootloader loads the running partition and determines whether there are any abnormal files in the running partition, including: The bootloader reads the checksum value and obtains the total file length and file byte data; Determine whether the sum of the total file length and the file byte data is equal to the checksum value; If the sum of the total file length and the file byte data is not equal to the checksum value, then the abnormal file exists in the running partition; The method further includes: After the embedded system completes startup, if the embedded system is not restarted by the watchdog or Linux panic within a preset time interval, the number of abnormal restarts will be reset to zero. After the embedded system completes startup, it copies the normal files from the target backup partition to the running partition according to the location index information, replacing the abnormal files in the running partition.

2. The method for restarting an embedded system according to claim 1, characterized in that, After the embedded system completes its startup, the method further includes: A dedicated partition is set up in the memory. If abnormal information is generated during the operation of the embedded system, the abnormal information is input into the dedicated partition and saved.

3. The method for restarting an embedded system according to claim 2, characterized in that, The method further includes: After the embedded system restarts, it receives log collection instructions and log return instructions from a third-party server via SNMP. The embedded system parses the log collection instruction, collects the exception information from the dedicated partition, and generates a log. The embedded system parses the log transmission command and transmits the log back to the third-party server at fixed intervals.

4. The method for restarting an embedded system according to claim 3, characterized in that, The method further includes: The logs are divided according to severity level, and the third-party server selects which logs to receive based on the severity level. The third-party server reads the anomaly information from the log through the SNMP MIB node.

5. A restart device for an embedded system, characterized in that, An embedded system is used, comprising memory, registers, a bootloader, and a counter. The memory includes multiple running partitions and multiple backup partitions. The registers contain built-in location index information indicating the association between the running partitions and backup partitions, including file type, format, size, and start and end addresses in the memory. The multiple running partitions include a Linux kernel running partition, a device tree running partition, and a file system running partition. The device includes: The first judgment module is used by the boot program to load the files of the running partition and determine whether there are abnormal files in the running partition; The second judgment module is used to trigger a restart of the embedded system if the abnormal file exists in the running partition, set the register status value related to the running partition where the abnormal file is located, and load the boot program. The boot program determines whether the restart of the embedded system is triggered by a watchdog or Linux panic based on the register status value. The counting module is used to increment the number of abnormal restarts recorded by the counter by 1 if the restart of the embedded system is triggered by a watchdog or a Linux panic. The restart module is configured to, if the number of abnormal restarts exceeds the abnormal restart threshold, have the bootloader read the status value of the register and the location index information, switch the running partition to the corresponding target backup partition, and restart the embedded system. The first judgment module is further configured to, when the bootloader loads the running partition, determine whether the running partition contains an abnormal file, including: the bootloader reads the checksum value and obtains the total file length data and file byte data; determines whether the sum of the total file length data and the file byte data is equal to the checksum value; if the sum of the total file length data and the file byte data is not equal to the checksum value, then the running partition contains the abnormal file; The restart module is further configured to, after the embedded system has completed startup, reset the number of abnormal restarts to zero if the embedded system is not restarted by a watchdog or Linux panic within a preset time interval; after the embedded system has completed startup, copy the normal files of the target backup partition to the running partition according to the location index information, replacing the abnormal files of the running partition.

6. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores a computer program that executes a restart method for an embedded system according to any one of claims 1 to 4 when the processor is running.

7. A computer-readable storage medium, characterized in that, It stores a computer program that, when run on a processor, executes a restart method for an embedded system according to any one of claims 1 to 4.

Images