Embedded device, firmware upgrade method and device

Abstract

The present application discloses an embedded device firmware, a firmware upgrade method and an apparatus, wherein the embedded device firmware divides the root file system partition into two, one is a miniRootfs partition, and the other is a rootfs partition; the miniRootfs partition takes up very little space and has only network and upgrade functions; once the full-function rootfs partition upgrade fails, the miniRootfs partition will be started for upgrade recovery; and the common modules of the miniRootfs partition and the rootfs partition are extracted to set a common baseLibs library partition. In this way, in the case of small memory, not only the functions of the embedded device are not reduced, but also flash space is saved, thereby reducing the production cost of the product, ensuring fast and safe firmware upgrades, and remedial measures can be implemented when problems occur in the firmware upgrade.

Description

Technical Field

[0001] The present application relates to the technical field of embedded devices, and in particular to an embedded device firmware, a firmware upgrade method and a device. Background Art

[0002] Embedded devices have been widely used in various fields such as industry, agriculture, education, national defense, scientific research and daily life due to their small size, high reliability, strong functions, flexibility and convenience. Embedded devices have played an extremely important role in promoting technological transformation, product upgrading, accelerating automation and improving productivity in various industries. Especially in the increasingly frequent use of smart terminal electronic products, the functions are often iterated, so firmware upgrades are becoming more and more important.

[0003] However, embedded devices usually have high cost requirements, and existing embedded devices not only have a harsh working environment, but also have problems such as random power outages, small memory, and small flash space, while the firmware is placed in the flash. Therefore, in the case of small memory, how to save flash space to ensure fast and safe firmware upgrades, and when problems occur during firmware upgrades, remedial measures can be taken to restore the problematic partitions are technical problems that need to be solved urgently by those skilled in the art. Summary of the invention

[0004] The present application provides an embedded device firmware, a firmware upgrade method and an apparatus, which are used to save the flash space of the embedded device in the case of small memory, thereby ensuring that the firmware is upgraded quickly and safely, and when problems occur during the firmware upgrade, remedial measures can be taken to restore the problematic partition.

[0005] In order to achieve the above-mentioned purpose, in a first aspect, the present application provides an embedded device, including: a UBoot partition, a Kernel kernel area, a baseLibs library partition, a miniRootfs partition, a rootfs partition and a Config parameter partition, wherein the miniRootfs partition is a minimum root file system area, and the baseLibs library partition is a common library partition for the miniRootfs partition and the rootfs partition;

[0006] The UBoot partition, the Kernel kernel area, the baseLibs library partition, the miniRootfs partition and the Config parameter partition constitute a first operating system, which is used for emergency treatment of damage to the embedded device;

[0007] The UBoot partition, the Kernel kernel area, the baseLibs library partition, the rootfs partition and the Config parameter partition constitute a second operating system for normal operation of the embedded device.

[0008] By adopting the above technical solution, flash space can be saved and the production cost of the product can be saved, thereby ensuring fast and safe firmware upgrades, and remedial measures can be taken when problems occur during firmware upgrades.

[0009] In order to achieve the above object, in a second aspect, the present application also provides a firmware upgrade method, which is applied to the embedded device as described above, comprising:

[0010] Powering on the embedded device;

[0011] Entering the second operating system to work;

[0012] Run the preset normal function program;

[0013] Communicate with the upgrade server to obtain new firmware for upgrading;

[0014] According to the new firmware, the rootfs partition of the second operating system is upgraded.

[0015] By adopting the above technical solution, the firmware is upgraded based on the embedded device, which not only saves flash space and meets the small memory situation, but also ensures the normal upgrade function of the firmware.

[0016] Optionally, the entering the second operating system to work specifically includes:

[0017] The program of the UBoot partition reads the kernel system of the Kernel kernel area;

[0018] Starting the kernel system;

[0019] The kernel system reads the address of the rootfs partition and loads the root file system of the rootfs partition;

[0020] The kernel system loads the baseLibs library partition and reads files of the baseLibs library partition;

[0021] According to the files in the baseLibs library partition, the kernel system loads the corresponding driver module of the normal function program.

[0022] By adopting the above technical solution, not only the cutting difficulty is overcome, but also the flash space is saved, thereby ensuring that the second operating system can work normally.

[0023] Optionally, communicating with the upgrade server to obtain new firmware for upgrading includes:

[0024] Communicate with the upgrade server within a preset fixed time to detect whether there is new firmware;

[0025] If yes, downloading the new firmware from the upgrade server;

[0026] If not, enter the next round of communication detection.

[0027] By adopting the above technical solution, regular communication inspection and upgrade can ensure the normal operation of embedded devices without delaying firmware upgrades, thereby improving the efficiency of normal operation and upgrades.

[0028] Optionally, the communicating with the upgrade server within a preset fixed time to detect and determine whether there is new firmware specifically includes:

[0029] Get the first version number of the current firmware;

[0030] Communicate with the upgrade server within a preset fixed time to obtain a second version number of the firmware of the upgrade server;

[0031] Compare whether the first version number and the second version number are the same;

[0032] If they are not the same, confirming that the firmware of the upgrade server is the new firmware, and generating a firmware download instruction;

[0033] If they are the same, a communication detection instruction is generated.

[0034] By adopting the above technical solution, it is possible to detect whether there is new firmware and compare whether the first version number and the second version number are the same, thereby accurately judging and launching subsequent upgrade functions.

[0035] Optionally, the communicating with the upgrade server within a preset fixed time to detect and determine whether there is new firmware specifically includes:

[0036] Get the first modification date of the current firmware;

[0037] Communicate with the upgrade server within a preset fixed time to obtain a second modification date of the firmware of the upgrade server;

[0038] Determining whether the first modification date is less than the second modification date;

[0039] If it is less than, confirm that the firmware of the upgrade server is the new firmware, and generate a firmware download instruction;

[0040] If it is not less than, a communication detection instruction is generated.

[0041] By adopting the above technical solution, it is possible to detect and determine whether there is new firmware, and to compare the first modification date and the second modification date, so as to accurately determine and launch subsequent upgrade functions.

[0042] Optionally, the step of upgrading the rootfs partition of the second operating system further includes:

[0043] Determine whether the rootfs partition of the second operating system is upgraded successfully;

[0044] If yes, restart the embedded device;

[0045] If not, an upgrade failure flag is generated in the Config parameter partition, and the embedded device is restarted.

[0046] By adopting the above technical solution, in order to ensure that the firmware can be successfully upgraded, it is also necessary to determine whether the rootfs partition of the second operating system is successfully upgraded. The Config parameter partition is configured with parameters required by the application, and can perform read and write operations to generate an upgrade failure flag, so that when a failure occurs during the firmware upgrade process, recovery can be performed to ensure successful firmware upgrade.

[0047] Optionally, the embedded device is powered on, and then further comprises:

[0048] Determine whether the Config parameter partition has the upgrade failure flag;

[0049] If not, generating a work instruction for entering the second operating system;

[0050] If so, generate a work instruction for entering the first operating system; enter the first operating system to work according to the work instruction of the first operating system; run a preset upgrade program; download the new firmware from the upgrade server; upgrade the rootfs partition; delete the upgrade failure mark of the Config partition; restart the embedded device.

[0051] By adopting the above technical solution, in the case of small memory, not only fast and safe upgrade is guaranteed, but also once upgrade problems occur, they can be remedied and the problematic partition can be restored.

[0052] Optionally, the entering the first operating system to work specifically includes:

[0053] The program of the UBoot partition reads the kernel system of the Kernel kernel area;

[0054] Starting the kernel system;

[0055] The kernel system reads the address of the miniRootfs partition and loads the minimum root file system of the miniRootfs partition;

[0056] The kernel system loads the baseLibs library partition and reads files of the baseLibs library partition;

[0057] According to the files in the baseLibs library partition, the kernel system loads the corresponding driver module of the upgrade program.

[0058] By adopting the above technical solution, the miniRootfs partition occupies very little space and has only network and upgrade functions, and the first operating system and the second operating system jointly use the baseLibs library partition, which greatly saves flash space without reducing functions.

[0059] In order to achieve the above-mentioned purpose, the present application further provides a firmware upgrade device in a third aspect, including:

[0060] A power-on module, used for powering on the embedded device;

[0061] An execution module, used for entering the second operating system to work;

[0062] The execution module is also used to run a preset normal function program;

[0063] An upgrade module is used to communicate with an upgrade server to obtain new firmware for upgrading;

[0064] The upgrade module is further used to upgrade the rootfs partition of the second operating system according to the new firmware.

[0065] By adopting the above technical solution, the power-on module powers on the embedded device; the execution module enters the second operating system and runs the preset normal function program; the upgrade module communicates with the upgrade server to obtain the new firmware for upgrading, and upgrades the rootfs partition of the second operating system according to the new firmware. Firmware upgrade based on the embedded device not only saves flash space and meets the small memory situation, but also ensures the normal firmware upgrade function.

[0066] In summary, the present application provides an embedded device firmware, a firmware upgrade method and an apparatus having the following technical effects:

[0067] The root file system partition is divided into two, one is miniRootfs partition and the other is rootfs partition. The miniRootfs partition takes up very little space and has only network and upgrade functions. Once the full-function rootfs partition fails to upgrade, the miniRootfs partition will be started for upgrade recovery. In addition, the common modules of the miniRootfs partition and the rootfs partition are extracted to set up a common baseLibs library partition. This not only greatly saves flash space and product production costs without reducing functions, but also ensures fast and safe firmware upgrades, and can also perform remedial measures when problems occur during firmware upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Figure 1 It is a schematic diagram of a partition structure of an embedded device provided in an embodiment of the present application.

[0069] Figure 2 It is a flowchart of an embodiment of a firmware upgrade method provided by the present application.

[0070] Figure 3 It is a flowchart of a second embodiment of a firmware upgrade method provided by the present application.

[0071] Figure 4 It is a flowchart of a third embodiment of a firmware upgrade method provided by the present application.

[0072] Figure 5 This is a flowchart of a fourth embodiment of a firmware upgrade method provided by the present application.

[0073] Figure 6 This is a flowchart of the fifth embodiment of a firmware upgrade method provided by the present application.

[0074] Figure 7 This is a flowchart of the sixth embodiment of a firmware upgrade method provided by the present application.

[0075] Figure 8 It is a structural diagram of an embodiment of a firmware upgrade device provided by the present application. DETAILED DESCRIPTION

[0076] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work should fall within the scope of protection of the present application.

[0077] It should be noted that when an element is referred to as being "fixed on" or "set on" another element, it can be directly on the other element or indirectly set on the other element; when an element is referred to as being "connected to" another element, it can be directly connected to the other element or indirectly connected to the other element.

[0078] It should be understood that the terms "length", "width", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0079] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, "multiple" and "several" mean two or more, unless otherwise clearly and specifically defined.

[0080] It should be noted that the structures, proportions, sizes, etc. illustrated in the drawings of this specification are only used to match the contents disclosed in the specification for people familiar with this technology to understand and read, and are not used to limit the conditions under which this application can be implemented. Therefore, they have no substantive technical significance. Any structural modification, change in proportional relationship or adjustment of size should still fall within the scope of the technical content disclosed in this application without affecting the effects and purposes that can be achieved by this application.

[0081] The relevant professional terms in this application are explained as follows:

[0082] Linux is a free-to-try and free-to-distribute Unix-like operating system. It is a multi-user, multi-tasking operating system based on Posix and Unix that supports multi-threading and multi-CPU. It can run major Unix tool software, applications and network protocols. It is a multi-user network operating system with stable performance.

[0083] FLASH flash memory, the English name is "Flash Memory", generally referred to as "Flash", it is a kind of memory device, the content of which can be modified directly on the motherboard without unplugging the IC.

[0084] Firmware is a program written into the flash memory, EROM, or EPROM (programmable read-only memory) of an application-specific integrated circuit (ASIC) or a programmable logic device (PLC). It is commonly understood as "cured software."

[0085] U-Boot, the full name of Universal Boot Loader, is an open source project. Its core function is to start the kernel system of the operating system. It is essentially a program.

[0086] Kernel is the core of an operating system. It is the first layer of software expansion based on hardware. It is a software layer that provides secure access to computer hardware for other applications. It provides the most basic functions of the operating system and is the basis for the operation of the operating system.

[0087] Rootfs, the root file system, is first of all a file system. This file system not only has the function of storing data files of ordinary file systems, but compared with ordinary file systems, it is the first file system mounted when the kernel starts. The image file of the kernel code is stored in the root file system. The system boot program will load some initialization scripts and services from the root file system into the memory to run after the root file system is mounted. The root file system and the kernel system are two completely independent parts.

[0088] miniRootfs is a custom name, meaning a minimal root file system.

[0089] baseLibs is a library partition shared by miniRootfs and rootfs.

[0090] Config is configured with the parameters required by the application.

[0091] Please Figure 1As shown, an embodiment of the present application provides an embedded device, including: a UBoot partition, a Kernel kernel area, a baseLibs library partition, a miniRootfs partition, a rootfs partition and a Config parameter partition, wherein the miniRootfs partition is a minimum root file system area, and the baseLibs library partition is a common library partition for the miniRootfs partition and the rootfs partition;

[0092] The UBoot partition, Kernel kernel area, baseLibs library partition, miniRootfs partition and Config parameter partition form the first operating system, which is used for emergency treatment of damage of embedded devices;

[0093] The UBoot partition, Kernel kernel area, baseLibs library partition, rootfs partition and Config parameter partition constitute the second operating system, which is used for the normal operation of the embedded device.

[0094] The implementation principle of this embodiment is: with the continuous development of technology, modifying the firmware to adapt to the constantly updated hardware environment has become an urgent requirement of users, so rewritable programmable and erasable read-only memory EPROM (Erasable Programmable read only memory), EEPROM (Electrically EPROM) and flash have appeared, which can be repeatedly flashed to allow the firmware to be modified and upgraded. However, existing embedded devices either require user intervention and external memory in advance, and once the upgrade fails, it needs to be repeatedly upgraded to repair; or the upgrade time is long, and once it fails, it will not be able to continue to upgrade; or it wastes flash space and cannot save costs.

[0095] To this end, the present application provides an embedded device that divides the root file system partition into two, one is a miniRootfs partition and the other is a rootfs partition. The miniRootfs partition takes up very little space and has only network and upgrade functions; once the full-function rootfs partition fails to be upgraded, the miniRootfs partition will be started for upgrade recovery. In addition, the common modules of the miniRootfs partition and the rootfs partition are extracted, and a common baseLibs library partition is set. In this way, without reducing the functions, not only the flash space is greatly saved, but also the production cost of the product is saved, thereby ensuring fast and safe firmware upgrades, and remedial measures can be taken when problems occur in the firmware upgrade.

[0096] In the above Figure 1The embodiment shown specifically describes an embedded device, and the firmware upgrade method applied to the embedded device is described below through an embodiment.

[0097] like Figure 2 As shown, the present application also provides a firmware upgrade method, which is applied to the embedded device described in the above embodiment, comprising:

[0098] S201, embedded device powered on;

[0099] S202, entering the second operating system to work;

[0100] S203, running a preset normal function program;

[0101] S204, communicating with the upgrade server to obtain new firmware for upgrading;

[0102] S205: Upgrade the rootfs partition of the second operating system according to the new firmware.

[0103] The implementation principle of this embodiment is: upgrading is a necessary function of the firmware, and downloading new firmware through the network with the upgrade server, and then successfully putting the downloaded new firmware into the designated falsh area is called upgrading. To this end, the embedded device is powered on; enters the second operating system to work; runs the preset normal function program; communicates with the upgrade server to obtain the new firmware for upgrading; according to the new firmware, the rootfs partition of the second operating system is upgraded. Firmware upgrade based on the embedded device not only saves flash space and meets the situation of small memory, but also ensures the function of normal firmware upgrade.

[0104] Optional, in Figure 2 In the embodiment shown, the operation of entering the second operating system in step S202 is described in detail. Figure 3 As shown, specifically including:

[0105] S301, the program of the UBoot partition reads the kernel system of the Kernel area;

[0106] S302, start the kernel system;

[0107] S303, the kernel system reads the address of the rootfs partition and loads the root file system of the rootfs partition;

[0108] S304, the kernel system loads the baseLibs library partition and reads files in the baseLibs library partition;

[0109] S305 . According to the files in the baseLibs library partition, the kernel system loads the corresponding driver module of the normal function program.

[0110] The implementation principle of this embodiment is: in order to save flash space and ensure that the second operating system can work normally, it is necessary to be very familiar with the kernel system and root file system of the Kernel kernel area, so as to cut and remove things that are not needed by the firmware. However, sometimes a module will involve many modules, and you need to understand and rewrite a part of it when cutting, which is very difficult. Therefore, based on the embedded device provided by this application, when the second operating system is working, the program of the UBoot partition reads the kernel system of the Kernel kernel area; starts the kernel system; the kernel system reads the address of the rootfs partition and loads the root file system of the rootfs partition, at this time, you can see various files of the normal system; the kernel system loads the baseLibs library partition and reads the files of the baseLibs library partition. The application does not have these files and cannot run; according to the files of the baseLibs library partition, the kernel system loads the corresponding driver module of the normal function program. Not only does it overcome the difficulty of cutting, but it also saves flash space, thereby ensuring that the second operating system can work normally.

[0111] Optional, in Figure 2 In the embodiment shown, step S204 of communicating with the upgrade server to obtain new firmware for upgrading is described in detail, such as Figure 4 As shown, specifically including:

[0112] S401, communicating with the upgrade server within a preset fixed time to detect whether there is new firmware;

[0113] S402: If yes, download new firmware from the upgrade server;

[0114] S403: If not, enter the next round of communication detection.

[0115] The implementation principle of this embodiment is: within a preset fixed time, network communication is performed with the upgrade server to check whether there is new firmware. If so, the new firmware is downloaded from the upgrade server to the memory; if not, the next round of communication detection is entered. Regular communication inspection and upgrade can ensure the normal operation of the embedded device without delaying the firmware upgrade, thereby improving the efficiency of normal operation and upgrade. The preset fixed time communication can be set according to actual needs and is not limited to a fixed value.

[0116] Optional, in Figure 4 In the illustrated embodiment, a detailed description is given of an embodiment of step S401 of communicating with the upgrade server within a preset fixed time to detect and determine whether there is new firmware, which specifically includes:

[0117] Get the first version number of the current firmware;

[0118] Communicate with the upgrade server within a preset fixed time to obtain a second version number of the firmware of the upgrade server;

[0119] Compare the first version number and the second version number to see if they are the same;

[0120] If they are not the same, confirm that the firmware of the upgrade server is the new firmware and generate a firmware download instruction;

[0121] If they are the same, a communication detection instruction is generated.

[0122] The implementation principle of this embodiment is: to detect whether there is new firmware, the first version number and the second version number can be compared to see if they are the same; if they are not the same, the firmware of the upgrade server is confirmed to be new firmware, and a download firmware instruction is generated; if they are the same, a communication detection instruction is generated. Subsequent operations can be performed according to the download firmware instruction or the communication detection instruction. It should be noted that the version number includes letters, numbers and other characters. Thereby accurately determining whether there is new firmware and launching subsequent upgrade functions.

[0123] Optional, in Figure 4 In the embodiment shown, another embodiment of step S401 of communicating with the upgrade server within a preset fixed time to detect and determine whether there is new firmware is described in detail, specifically including:

[0124] Get the first modification date of the current firmware;

[0125] Communicate with the upgrade server within a preset fixed time to obtain a second modification date of the firmware of the upgrade server;

[0126] Determine whether the first modification date is less than the second modification date;

[0127] If it is less than, it confirms that the firmware of the upgrade server is the new firmware and generates a firmware download instruction;

[0128] If it is not less than, a communication detection instruction is generated.

[0129] The implementation principle of this embodiment is: to detect and determine whether there is new firmware, you can also compare the first modification date and the second modification date; if the second modification date is larger, it is confirmed that the firmware of the upgrade server is new firmware, and a download firmware instruction is generated; otherwise, a communication detection instruction is generated to perform the next round of detection. In this way, it is accurately determined whether there is new firmware and the subsequent upgrade function is launched.

[0130] Optional, in Figure 2 In the embodiment shown, after the rootfs partition of the second operating system is upgraded in step S205, Figure 5 As shown, it also includes:

[0131] S501, determining whether the rootfs partition of the second operating system is successfully upgraded;

[0132] S502: If yes, restart the embedded device;

[0133] S503: If not, an upgrade failure flag is generated in the Config parameter partition, and the embedded device is restarted.

[0134] The implementation principle of this embodiment is: in order to ensure that the firmware can be successfully upgraded, it is also necessary to determine whether the rootfs partition of the second operating system is successfully upgraded. If successful, the embedded device is restarted; otherwise, an upgrade failure flag is generated in the Config parameter partition, and the embedded device is restarted. The Config parameter partition is configured with parameters required by the application, and can perform read and write operations, generate an upgrade failure flag, so that when a failure occurs during the firmware upgrade process, it can be entered for recovery to ensure successful firmware upgrade.

[0135] Optional, in Figure 5 In the embodiment shown, after the embedded device is powered on in step S201, Figure 6 As shown, it also includes:

[0136] S601, determining whether the Config parameter partition has an upgrade failure flag;

[0137] S602: If not, generate a work instruction to enter the second operating system;

[0138] S603, if yes, generate a work instruction for entering the first operating system; enter the first operating system according to the work instruction for the first operating system; run a preset upgrade program; download new firmware from the upgrade server; upgrade the rootfs partition; delete the upgrade failure mark of the Config partition; restart the embedded device.

[0139] The implementation principle of this embodiment is: based on the embedded device provided by this application, it is determined whether the Config parameter partition has an upgrade failure mark, and the corresponding upgrade failure recovery or normal operation processing is performed according to the first operating system working instruction or the second operating system working instruction. Therefore, in the case of small memory, not only a fast and safe upgrade is guaranteed, but also once a problem occurs in the upgrade, it can be remedied and the partition with the problem can be restored.

[0140] Optional, in Figure 6 In the embodiment shown, the operation of entering the first operating system in step S603 is described in detail, as shown in FIG. Figure 7 As shown, specifically including:

[0141] S701, the program of UBoot partition reads the kernel system of Kernel area;

[0142] S702, start the kernel system;

[0143] S703, the kernel system reads the address of the miniRootfs partition and loads the minimum root file system of the miniRootfs partition;

[0144] S704, the kernel system loads the baseLibs library partition and reads files in the baseLibs library partition;

[0145] S705 . According to the files in the baseLibs library partition, the kernel system loads the corresponding driver module of the upgrade program.

[0146] The implementation principle of this embodiment is: when the Config parameter partition has an upgrade failure mark, the UBoot partition, Kernel kernel area, baseLibs library partition, miniRootfs partition and Config parameter partition are entered to form the first operating system for damage emergency processing. The miniRootfs partition occupies very little space and has only network and upgrade functions. The first operating system and the second operating system share the baseLibs library partition. In this way, the flash space is greatly saved without reducing the functions.

[0147] Based on the firmware upgrade method described in the above embodiment, the present application also provides a firmware upgrade device, which has the corresponding effect of the firmware upgrade method provided in the embodiment of the present application. Figure 8 , which is a schematic diagram of the structure of a firmware upgrade device provided by the present application.

[0148] The present application also provides a firmware upgrade device, comprising:

[0149] Power-on module 801, used for powering on embedded devices;

[0150] An execution module 802 is used to enter the second operating system to work;

[0151] The execution module 802 is also used to run the preset normal function program;

[0152] The upgrade module 803 is used to communicate with the upgrade server to obtain new firmware for upgrading;

[0153] The upgrade module 803 is further used to upgrade the rootfs partition of the second operating system according to the new firmware.

[0154] The implementation principle of this embodiment is as follows: the power-on module 801 powers on the embedded device; the execution module 802 enters the second operating system and runs the preset normal function program; the upgrade module 803 communicates with the upgrade server to obtain the new firmware for the upgrade, and upgrades the rootfs partition of the second operating system according to the new firmware. Firmware upgrade based on the embedded device not only saves flash space and meets the small memory situation, but also ensures the normal firmware upgrade function.

[0155] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An embedded device, characterized in that: include: UBoot partition, Kernel kernel area, baseLibs library partition, miniRootfs partition, rootfs partition and Config parameter partition, wherein the miniRootfs partition is a minimum root file system area, and the baseLibs library partition is a common library partition for the miniRootfs partition and the rootfs partition; The UBoot partition, the Kernel kernel area, the baseLibs library partition, the miniRootfs partition and the Config parameter partition constitute a first operating system, which is used for emergency treatment of damage to the embedded device; The UBoot partition, the Kernel kernel area, the baseLibs library partition, the rootfs partition and the Config parameter partition constitute a second operating system for normal operation of the embedded device; Powering on the embedded device; Determine whether the Config parameter partition has an upgrade failure flag; If so, generate a work instruction to enter the first operating system; according to the work instruction of the first operating system, the program of the UBoot partition reads the kernel system of the Kernel kernel area; start the kernel system; the kernel system reads the address of the miniRootfs partition and loads the minimum root file system of the miniRootfs partition; the kernel system loads the baseLibs library partition and reads the files of the baseLibs library partition; according to the files of the baseLibs library partition, the kernel system loads the corresponding driver module of the upgrade program to enter the first operating system; run the preset upgrade program; download the new firmware from the upgrade server; upgrade the rootfs partition; delete the upgrade failure mark of the Config parameter partition; restart the embedded device; If not, generate a work instruction to enter the second operating system; according to the work instruction of the second operating system, the program of the UBoot partition reads the kernel system of the Kernel kernel area; start the kernel system; the kernel system reads the address of the rootfs partition and loads the root file system of the rootfs partition; the kernel system loads the baseLibs library partition and reads the files of the baseLibs library partition; according to the files of the baseLibs library partition, the kernel system loads the corresponding driver module of the normal function program to enter the second operating system; run the preset normal function program; communicate with the upgrade server to obtain new firmware for upgrading; according to the new firmware, upgrade the rootfs partition of the second operating system; determine whether the rootfs partition of the second operating system is upgraded successfully; if so, restart the embedded device; if not, generate an upgrade failure mark in the Config parameter partition and restart the embedded device.

2. A firmware upgrade method, characterized in that: Applied in the embedded device as claimed in claim 1, comprising: Powering on the embedded device; Determine whether the Config parameter partition has an upgrade failure flag; If so, generate a work instruction to enter the first operating system; according to the work instruction of the first operating system, the program of the UBoot partition reads the kernel system of the Kernel kernel area; start the kernel system; the kernel system reads the address of the miniRootfs partition and loads the minimum root file system of the miniRootfs partition; the kernel system loads the baseLibs library partition and reads the files of the baseLibs library partition; according to the files of the baseLibs library partition, the kernel system loads the corresponding driver module of the upgrade program to enter the first operating system; run the preset upgrade program; download the new firmware from the upgrade server; upgrade the rootfs partition; delete the upgrade failure mark of the Config parameter partition; restart the embedded device; If not, generate a work instruction to enter the second operating system; according to the work instruction of the second operating system, the program of the UBoot partition reads the kernel system of the Kernel kernel area; start the kernel system; the kernel system reads the address of the rootfs partition and loads the root file system of the rootfs partition; the kernel system loads the baseLibs library partition and reads the files of the baseLibs library partition; according to the files of the baseLibs library partition, the kernel system loads the corresponding driver module of the normal function program to enter the second operating system; run the preset normal function program; communicate with the upgrade server to obtain new firmware for upgrading; according to the new firmware, upgrade the rootfs partition of the second operating system; determine whether the rootfs partition of the second operating system is upgraded successfully; if so, restart the embedded device; if not, generate an upgrade failure mark in the Config parameter partition and restart the embedded device.

3. The firmware upgrade method according to claim 2, characterized in that: The communicating with the upgrade server to obtain the new firmware for the upgrade includes: Communicate with the upgrade server within a preset fixed time to detect whether there is new firmware; If yes, downloading the new firmware from the upgrade server; If not, enter the next round of communication detection.

4. The firmware upgrade method according to claim 3, characterized in that: The communication with the upgrade server within a preset fixed time to detect and determine whether there is new firmware specifically includes: Get the first version number of the current firmware; Communicate with the upgrade server within a preset fixed time to obtain a second version number of the firmware of the upgrade server; Compare whether the first version number and the second version number are the same; If they are not the same, confirming that the firmware of the upgrade server is the new firmware, and generating a firmware download instruction; If they are the same, a communication detection instruction is generated.

5. The firmware upgrade method according to claim 3, characterized in that: The communication with the upgrade server within a preset fixed time to detect and determine whether there is new firmware specifically includes: Get the first modification date of the current firmware; Communicate with the upgrade server within a preset fixed time to obtain a second modification date of the firmware of the upgrade server; Determining whether the first modification date is less than the second modification date; If it is less than, confirm that the firmware of the upgrade server is the new firmware, and generate a firmware download instruction; If it is not less than, a communication detection instruction is generated.

Images