Firmware security upgrading method for compact embedded linux system

Abstract

A compact embedded linux system firmware security upgrading method comprises the steps that a main application module obtains upgrading firmware and completes verification, and an upgrading command is sent to an application management module through process communication; the application management module starts a monitoring task, when an upgrading command message is received, a main application module and related system services are stopped, a dynamic library file needed by upgrading is copied to a memory directory, a system dynamic library environment path is repositioned to the memory directory, and an upgrading module is started; and the upgrading module calls the graphics library, and the obtained upgrading firmware is programmed to complete system firmware upgrading. Relevant necessary dynamic library files are copied to a specified directory through application management, an environment variable points to the directory, a main application is stopped, firmware is programmed, a dynamic library path is dynamically relocated, the relocated dynamic library is safely used in the upgrading process, the upgrading safety is guaranteed, and the upgrading efficiency is improved. And meanwhile, additional space backup firmware is not needed.

Description

Technical Field

[0001] The present invention relates to the field of firmware upgrade and update, and particularly to a method for securely upgrading the firmware of a compact embedded Linux system. Background Art

[0002] Compared with the RTOS real-time operating system, the embedded Linux system is more powerful, with an efficient, stable, and secure kernel; it is open-source, free, highly customizable, and has a rich software and toolchain support and selection. Due to software function updates or problems found during use, it is necessary to upgrade the software firmware. Due to its own design, end-users of the embedded Linux system generally see a main application (such as a network player). This main application has complex functions and, during operation, many necessary services (processes) are started. These services (processes) basically run in the form of dynamic libraries, that is, they are loaded into memory only when the application runs. Even during operation, they may also access dynamic libraries. If the dynamic libraries are stored in the root file system (romfs) in read-only form, during the flash burning stage of the system upgrade process, if the main application accesses the dynamic libraries in the flash, there is a risk of upgrade failure.

[0003] Therefore, the flash burning of many embedded Linux systems is carried out in the Bootloader. The Bootloader is often a small system with a simple operating environment, not many services, and no application execution, so the upgrade is safe. For the secure firmware upgrade of the embedded Linux system, there are many different methods, but ultimately, the flash burning process is basically the following several practices:

[0004] (1) The embedded Linux system has abundant resources and sufficient flash space. There are two firmware partitions in the flash, one is the currently used firmware partition, and the other is the backup firmware partition. In this case, the upgrade can be directly carried out in the main application. After the firmware is downloaded, it is directly burned to the backup firmware partition. If the burning fails, after startup, the main partition firmware is still used; if the burning is successful, after startup, the backup partition and the original main partition flags are swapped, and the backup partition firmware is used to run, and the new backup partition is upgraded next time. This method is the safest and there is no risk of the burned device becoming a brick.

[0005] (2) When the system resources are compact and there is no extra flash space. The firmware is downloaded to an external non-volatile memory (usually a USB device) in the application, and then restarted into the Bootloader, and the firmware in the external non-volatile memory is burned to the flash running position. The function of this is that the Bootloader upgrade environment is simple, without too many system services, and the flash can be burned safely.

[0006] The firmware upgrade methods of the above-mentioned prior art have the following disadvantages:

[0007] (1) For the firmware upgrade method of the dual-partition system, it can be seen that additional costs are required and sufficient flash space is needed. In the fierce market competition, the cost advantage is insufficient.

[0008] (2) For the upgrade method of burning the flash in the Bootloader, since the Bootloader has a simple function and no download function such as network download, etc., it is generally downloaded in the main Linux application. As for where to place the downloaded firmware, there are only two options: one is to save it to the memory, restart to the Bootloader, and burn the firmware in this memory to the flash. However, there is a great risk whether the firmware data in the memory will be modified after the hardware reset during restart, so this method cannot be used; the other is to connect an external USB device, and the main application saves the firmware to the USB device, then starts the Bootloader and burns the firmware of the USB device to the flash. This method requires an external USB device, is inconvenient to use, and is not applicable to products without a USB interface. The Bootloader has a single function and limited resources, and often supports a very simple graphical interface, or even does not support the GUI (Graphical User Interface). The human-computer interaction display during the burning process cannot be as smooth, gorgeous, and reasonable as in the Linux application, and the development interface is also complex.

[0009] The present invention is to solve the above problems. Without increasing the additional cost of the flash and without the need to connect an external USB device to save the firmware, the firmware can be safely upgraded. At the same time, it can quickly enter the upgrade and flash burning interface, and the operation interface for flashing the flash can also be made more reasonable, gorgeous, and smooth, and support font library selection, etc.

[0010] The present invention is to solve the security problem of system upgrade in the application. A dedicated upgrade and flash burning application is developed and separated from the main application. The main application downloads the upgrade firmware into the memory without the need for an additional storage device. Then, through the application management module, the main application is stopped and jumped to the upgrade and flash burning application, and the firmware in the memory is burned to the flash in the upgrade and flash burning application to complete the upgrade.

[0011] Since the work of the upgrade and flash burning application is only to burn the flash and does not have complex functions, it does not require too many dynamic libraries and service supports. As long as the limited dynamic libraries used are copied and relocated to the memory, the flash burning process does not affect the memory, so the upgrade security is guaranteed. Using the upgrade and flash burning application in the Linux environment has the advantage of quickly entering the upgrade and flash burning stage, and the graphical interface of the Linux environment can be used, and the developed upgrade interface is more gorgeous and convenient. Summary of the Invention

[0012] The present invention provides a method and system for secure upgrade of a firmware of a compact embedded Linux system, which realizes secure upgrade of the system firmware in the Linux operating system without switching the operating system and without additional storage peripherals.

[0013] A method for secure upgrade of a firmware of a compact embedded Linux system includes the following steps:

[0014] The main application module obtains the upgrade firmware and completes verification, and sends an upgrade command to the application management module through process communication;

[0015] The application management module starts to listen for the message queue task. When receiving the upgrade command message, it stops the main application module and related system services, copies the dynamic library files required for the upgrade to the memory directory, relocates the dynamic library environment path of the Linux system to the memory directory, and starts the upgrade module;

[0016] The upgrade module calls the Linux graphics library to burn the obtained upgrade firmware into the flash, and completes the upgrade of the Linux system firmware.

[0017] Further, the application management module uses the kill command of Linux to stop the main application module, and redirects the path of the standard dynamic library to the specified path through the mount command; the related system services stopped include the network service, the hot plug service, and the monitoring script.

[0018] Further, when copying the dynamic library files required for the upgrade to the memory directory, the dynamic library files required for the upgrade include the dynamic library files required for the application management module and the upgrade module to complete the upgrade. When the application management module and the upgrade module load the dynamic library files required for the upgrade, they are loaded from the relocated memory directory instead of the dynamic library in the flash root file system.

[0019] Further, the main application module obtains the upgrade firmware through network download or USB peripheral download, and the upgrade firmware is stored in the Linux memory directory through the mmap memory mapping method; the firmware verification methods include: CRC verification of the integrity and legality of the firmware, device product number verification, and device version number verification.

[0020] Further, during the process of the upgrade module burning the flash, the dynamic file library in the flash is erased and rewritten. If the application management module and the upgrade module still need to access the dynamic library files, the dynamic library files relocated to the memory directory are used.

[0021] Further, the upgrade module calls the graphics library according to the display control parameters to display the upgrade-related information, and the upgrade-related information includes the burning progress and the burning prompt.

[0022] Further, before burning the upgraded firmware to the flash, the upgrade module checks whether the upgraded firmware exists. If it does not exist, an error is prompted and the upgrade is exited, and the system restarts. If it exists, the legality of the upgraded firmware is verified. If it is illegal, the upgrade is exited and the system restarts. After the upgrade verification is successful, the firmware is burned to the flash, and the upgrade-related information is displayed according to the display control parameters. After the upgrade is successful, the system restarts.

[0023] Further, the process communication is one of pipe communication, message queue communication, shared memory communication, and socket communication.

[0024] Technical effects of the present invention:

[0025] For the process of burning the flash, the present invention specifically develops an upgrade application module that only performs the work of burning the flash and displaying. During the upgrade, the main application in Linux downloads the upgraded firmware to the / tmp directory in the Linux root file system. This directory is the virtual memory file system in Linux, that is, the tmpfs memory file system, which can be read and written. The main application copies the relevant necessary dynamic library files to the / tmp directory through the application management module, and the environment variable points to the / tmp directory, and the main application is stopped. The application management module starts the upgrade application module, and the upgrade application burns the firmware in the / tmp directory to the flash.

[0026] The present invention is responsible for burning the upgraded firmware to the flash through an independent upgrade module with simple functions. The upgrade process is safe and efficient, and supports a richer operation interface. Necessary dynamic library files are copied before burning the firmware, and the dynamic library path is dynamically relocated to ensure the safe use of the relocated dynamic library by the upgrade module. No additional flash space is required to back up the firmware. When upgrading the firmware in the bootloader, the upgraded firmware downloaded through the network also does not require an additional USB peripheral to save. The upgrade of the present invention is the upgrade of the entire system firmware, not just the application upgrade. The entire upgrade process is carried out in the linux operating system without switching to other operating systems, which is the essential difference from the general linux upgrade. Description of the Drawings

[0027] Figure 1 It is a typical embedded linux system structure diagram applicable to the present invention;

[0028] Figure 2 It is a schematic diagram of the module relationship of the present invention;

[0029] Figure 3 It is a schematic diagram of the processing flow of the application management module of the present invention;

[0030] Figure 4It is a schematic diagram of the processing flow of the main application module of the present invention;

[0031] Figure 5 It is a schematic diagram of the processing flow of the upgrade module of the present invention; Detailed implementation manners

[0032] Figure 1 It is a structural diagram of a typical embedded Linux system applicable to the solution of the present invention. The Bootloader is responsible for hardware initialization, system boot, and starting the Linux image; the parameter storage partition stores the parameters required by the application, such as display mode, volume, WiFi password, etc.; the Linux image includes the Linux kernel, various application programs, etc., and is the core component of the entire system.

[0033] As Figure 2 As shown, the present invention includes three modules: the main application module, the application management module, and the upgrade module, all of which are set in the application program part and belong to the components in the Linux image. The three modules are all application programs that run independently in Linux. The main application module and the application management module perform process communication using a message queue. The application management module is responsible for monitoring the main application module, receiving instructions from the main application module, stopping the main application module, and starting the upgrade module to burn the flash; the main application module is responsible for downloading the firmware during the upgrade and notifying the application management module to start the upgrade module; the upgrade module is responsible for burning the flash. The application management module starts the upgrade module to burn the flash. The communication method between the modules is the message queue mechanism of Linux, avoiding the problem that it is difficult to clear the resources of the main application module when the main application module directly starts the upgrade module.

[0034] Dynamic libraries in Linux are named in contrast to static libraries. Dynamic libraries exist in the Linux system with the file extension.so and are loaded only when a Linux application runs. When compiling a static library, the code is completely copied into the executable file, so that it does not need to depend on other files during runtime. However, since each executable file will copy a library file, if many executable files use the same library, it will waste memory and is difficult to update. When compiling a dynamic library (.so file), only symbol references are recorded, and the executable file itself does not contain the code of the library file. The code is loaded into memory only when the executable file starts or runs. Multiple processes can share the same library code in physical memory, significantly saving memory and disk space. For a system with a root file system of the romfs type, these library files are stored in the / lib and / user / lib directories, both in flash. Many dynamic libraries are used in Linux to save memory and make updates more convenient. Although dynamic libraries are loaded into memory at startup, during the operation of the system, it is possible that the memory of a dynamic library has not been used for a long time and will be reclaimed; when a subsequent application needs to access the dynamic library, it will be reloaded from flash into memory again. If flash is being programmed at this time, the application access will go wrong, and the risk of programming errors is very high.

[0035] The present invention copies these necessary dynamic libraries from the root file system of flash to memory, and then relocates the system path of the dynamic library. When the application management module and the upgrade module need to load a dynamic library, they will default to loading from memory instead of from flash that may be damaged by programming, avoiding program execution errors and the risk of upgrade failure.

[0036] The schematic diagram of the processing flow of the application management module is as Figure 3 shown. The application management module is an independent application used to manage the main application module and the upgrade module; and establish a communication channel with the main application module.

[0037] The application management module uses a message queue for process communication. The main application module sends messages to the application management module in a certain format to perform corresponding operations. Since the application management module is a very small application, it can also execute shell commands on behalf of the main application module, thus avoiding the need to copy and inherit a lot of resources when the main application module, a large application, calls shell commands.

[0038] The application management module receives two types of message commands from the main application module:

[0039] system: Execute Linux shell commands.

[0040] upgrade: Execute the process of upgrading and programming flash.

[0041] The working process includes the following steps:

[0042] (1) The Linux kernel boots to the root file system and runs the application management module.

[0043] (2) The application management module starts the main application module and monitors the main application module.

[0044] (3) If the main application module crashes during operation, the application management module monitors and restarts the main application module, acting as an application watchdog.

[0045] (4) The application management module starts the message queue listening task to respond to the message commands of the main application module.

[0046] Create a message queue ID. Through the message queue ID, communication with other application modules is achieved. An example of the implementation method is as follows:

[0047] msgget((key_t)APP_QUEUE_KEY, 0666|IPC_CREAT).

[0048] (5) Upon receiving the upgrade command, stop (kill) the main application module and stop related unnecessary system services, such as network services, hot plug services, monitoring scripts, etc.

[0049] Use the linux command "kill -9 <pid>", kill the main application module; use the Linux command "ifconfig" to stop the network service; stop other unnecessary Linux system services. The main command examples are as follows:

[0050] echo\"\"> / proc / sys / kernel / hotplug

[0051] killall hostapd

[0052] killall wpa_supplicant

[0053] ifconfig wlan0 down

[0054] ifconfig p2p0 down

[0055] (6) Copy the dynamic library files required by the application management module and the upgrade module to the memory directory / tmp / upg_lib / lib. When burning the flash, the application management module and the upgrade module use the dynamic library files in this memory directory.

[0056] Using the Linux command "ldd", you can accurately know the dynamic library files used by the application management module and the upgrade module, and copy these dynamic library files to the memory temporary directory. In the embodiment of the present invention, through the ldd command, it can be known that the application management module and the upgrade module need to use the following dynamic library files:

[0057] / lib / libpthread.so.0

[0058] / lib / libc.so.6

[0059] / lib / ld.so.1

[0060] / lib / libm.so.6

[0061] / lib / libstdc++.so.6

[0062] / lib / libgcc_s.so.1

[0063] / lib / libresolv.so.2

[0064] / usr / lib / libhcfota.so

[0065] / usr / lib / liblvgl.so

[0066] Copy the previously identified dynamic library files from the system (flash) to the memory directory. The main commands are as follows:

[0067] cp / lib / libpthread.so.0 / tmp / upg_lib / lib-vf

[0068] cp / lib / libc.so.6 / tmp / upg_lib / lib-vf

[0069] cp / lib / ld.so.1 / tmp / upg_lib / lib-vf

[0070] cp / lib / libm.so.6 / tmp / upg_lib / lib-vf

[0071] cp / lib / libstdc++.so.6 / tmp / upg_lib / lib-vf

[0072] cp / lib / libgcc_s.so.1 / tmp / upg_lib / lib-vf

[0073] cp / lib / libresolv.so.2 / tmp / upg_lib / lib-vf

[0074] cp / usr / lib / libhcfota.so / tmp / upg_lib / usr / lib-vf

[0075] cp / usr / lib / liblvgl.so / tmp / upg_lib / usr / lib-vf

[0076] (7) Relocate the dynamic library environment path used in the Linux environment to the memory directory / tmp / upg_lib / lib. When the application management module and the upgrade module need to load dynamic libraries, they are loaded from the / tmp / upg_lib / lib directory instead of the dynamic libraries in the / lib and / user / lib of the flash root file system.

[0077] In the embodiment of the present invention, through the Linux command "mount", the paths of the standard dynamic libraries ( / user / lib, / user / lib32) are redirected to the specified path / tmp. In this way, the application management module and the upgrade module use the dynamic library files in / tmp instead of the dynamic library files in the flash. The main commands are as follows:

[0078] mount--bind / tmp / upg_lib / lib / lib

[0079] mount--bind / tmp / upg_lib / usr / lib / usr / lib

[0080] (8) The application management module starts the upgrade module, and the upgrade module completes the flash programming work.

[0081] In the above process, the control and management of dynamic libraries by the application management module is the key to safely upgrading the operating system (not just the application upgrade) in the Linux environment. Since the main application module has many threads, runs many functions, and depends on many dynamic libraries. The dynamic libraries are stored in the flash non-volatile memory. If the flash is programmed in the main application module, the dynamic libraries in the flash will be erased and updated. If some threads, functions, or other processes that the main application module depends on are accessing the dynamic libraries being erased in the flash, it is very likely to cause the upgrade to crash and damage the platform firmware. This is also the reason why the Linux system upgrade in the general implementation method must switch to another operating system for the upgrade. Switching to a simple small system is easy to control and does not require accessing such dynamic libraries.

[0082] In the present invention, innovatively, the necessary standard dynamic libraries are redirected from the flash to the memory. The upgrade programming only switches the program, rather than switching the operating system, and the programming operation still runs in the Linux environment. The application management module will copy the dynamic libraries on which the application management module and the upgrade module depend for the upgrade to the memory. Since the functions of the application management module and the upgrade module are simple and there are no complex operations, the required dynamic libraries are relatively few. Then, the dynamic library path is relocated. When the application management module and the upgrade module access the dynamic libraries, they actually access the memory. In this way, the access to the dynamic libraries will not be affected when the flash is programmed, and the security is also greatly improved. Moreover, the upgrade programming interface can be made richer with the GUI (Graphical User Interface) library, and there is no need to connect to a USB peripheral to save the upgrade firmware.

[0083] The main application module is a main application program in the Linux user space that implements dedicated functions, such as a multimedia player. This is the main application finally presented to the user after the system device is started.

[0084] The main application module is usually the most complex application, which calls many dynamic library files and services. The entire kernel function serves this main application. If the flash is programmed and upgraded in the main application module, many services of the main application cannot be completely stopped, and many dynamic libraries are also bound to the main application module. There is a risk in programming the flash. This is the reason why the flash needs to be programmed in an independent upgrade module. The upgrade module has a single function and requires few dynamic libraries and services, which can achieve a safe and reliable effect. Before programming the flash, the main application module is killed, and the related services and dynamic library files do not need to be accessed.

[0085] In the implementation mode of the present invention, the main application module mainly obtains the upgrade firmware and verifies the upgrade firmware during the upgrade. As Figure 4 shown, the working process of the main application module includes the following steps:

[0086] (1) Download the upgrade firmware. The download method is not limited to network download and USB peripheral download. The upgrade firmware is safely downloaded from the network or USB peripheral to the linux memory directory of the device. The file writing method uses the mmap memory mapping method, and the file path information is: / tmp / upgrade.bin.

[0087] (2) Verify the firmware, including firmware integrity, using the CRC method, analyzing the firmware feature header, comparing the firmware versions, etc., to ensure that the firmware is complete and can be safely upgraded. The firmware verification methods include, for example: using CRC to verify the integrity and legality of the firmware; comparing with the product number of this device, and only upgrading if they match; according to the upgrade strategy in the upgrade firmware, comparing with the version number of this device, and only upgrading if it meets the upgrade version strategy.

[0088] (3) Send an upgrade command to the application management module.

[0089] When sending a message to the application management module, it is also necessary to create a message queue that is the same as the message queue ID of the application management module. In the embodiment of the present invention, the implementation command is as follows:

[0090] msgget((key_t)APP_QUEUE_KEY,0666|IPC_CREAT).

[0091] Since the upgrade module needs to be started through the application management module, and the upgrade module needs to draw a graphic display, some display parameters need to be passed, and then the upgrade module is started. Through the message queue communication mechanism of the process, send a command in the following format to the application management module:

[0092] upgrade -k hcprojector -s. / upgradeapp -u / tmp / upgrade.bin -z 0,0,1280,720,1920,1080 -f 180,0,0

[0093] -k kill the main application module

[0094] -s start the upgrade module

[0095] -u upgrade the firmware

[0096] -z scaling parameters for different resolutions of the interface

[0097] -f rotation parameters of the interface

[0098] (4) The main application module is killed by the application management module, and the system enters the upgrade and flash writing process.

[0099] The upgrade module is responsible for writing the upgrade firmware at the specified path ( / tmp / upgrade.bin) to the flash, and displaying the writing progress, writing prompts, etc. through the graphics library. Since the upgrade module is a Linux application and can use the rich image libraries of Linux, the graphical interface can be made gorgeous and smooth.

[0100] When the application management module receives the upgrade message command, it will finally start the upgrade module. The upgrade module is a Linux application and can carry display control parameters when starting. The command to run the upgrade module in the present invention is as follows:

[0101] upgradeapp -u / tmp / upgrade.bin -z 0,0,1280,720,1920,1080 -f 180,0,0

[0102] -u Upgrade firmware

[0103] -z Scaling parameters for different resolutions of the interface

[0104] -f Rotation parameters of the interface

[0105] As Figure 5 shown, the working process of the upgrade module includes the following steps:

[0106] (1) Since the upgrade firmware file has been downloaded by the main application module to / tmp / upgrade.bin. After entering the upgrade module, check whether / tmp / upgrade.bin exists. If it does not exist, prompt an error and exit the upgrade, and the system restarts.

[0107] (2) Firmware verification, and then do another detection on the legality of the upgrade firmware. If it is illegal, exit the upgrade and the system restarts.

[0108] (3) After the upgrade verification is successful, write the firmware to the flash and display the upgrade progress bar.

[0109] (4) The upgrade is successful and the system restarts.

[0110] During the flash writing process, the dynamic library files in the flash will be erased and rewritten. If the application management module and the upgrade module still need to access the dynamic library files, they will use the dynamic library files relocated to the memory directory instead of loading the dynamic library files in the flash. Therefore, the upgrade process of the present invention is safe and reliable.

[0111] As can be known from the foregoing description, the beneficial effects of the present invention are that in a compact Linux embedded system, without the need to additionally increase the flash space and without the need to additionally add a USB external storage device, a secure system firmware upgrade can be completed. Furthermore, since the upgrade is performed in the Linux application space, a rich graphics library can be used to render the human-machine interaction interface, obtaining a good operation and interaction experience.

[0112] Alternative embodiments include: (1) The source method of the upgraded firmware is not limited to reading from a USB device or downloading from the network. As long as it is a method of obtaining the upgraded firmware from the outside, it falls within the protection scope of the present invention. (2) The method of burning the flash is to jump out of the main application module and burn it in other modules. This other module is not limited to the upgrade module and may also be other different functional modules. (3) The communication method between functional modules can include all Linux process communication methods, including but not limited to pipe communication, message queue communication, shared memory communication, socket communication, etc.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that the technical solutions of the present invention can be modified or equivalently replaced without departing from the spirit and scope of the technical solutions of the present invention.< / pid>

Claims

1. A method for secure firmware upgrade of a compact embedded Linux system, comprising the following steps: The main application module obtains the upgrade firmware and completes the verification, and sends an upgrade command to the application management module through process communication; The application management module starts a listening task. When receiving an upgrade command message, it stops the main application module and related system services, copies the dynamic library files required for the upgrade to the memory directory, relocates the Linux system dynamic library environment path to the memory directory, and starts the upgrade module; The upgrade module calls the Linux graphics library to burn the obtained upgrade firmware into the flash to complete the firmware upgrade of the Linux system.

2. The method for secure firmware upgrade of a compact embedded Linux system according to claim 1, wherein the application management module uses the kill command of Linux to stop the main application module, and redirects the path of the standard dynamic library to a specified path through the mount command; the related system services stopped include the network service, the hot plug service, and the monitoring script.

3. The method for secure firmware upgrade of a compact embedded Linux system according to claim 1, wherein the dynamic library files required for the upgrade are copied to the memory directory, and the dynamic library files required for the upgrade include the dynamic library files required for the application management module and the upgrade module to complete the upgrade. When the application management module and the upgrade module load the dynamic libraries required for the upgrade, they are loaded from the relocated memory directory instead of from the dynamic libraries in the flash root file system.

4. The method for securely upgrading the firmware of the compact embedded Linux system according to claim 1, wherein the main application module obtains the upgraded firmware through network download or USB peripheral download, and the upgraded firmware is stored in the Linux memory directory through the mmap memory mapping method; the firmware verification method includes: CRC checks the integrity and legality of the firmware, device product number check, device version number check.

5. The method for secure firmware upgrade of a compact embedded Linux system according to claim 1, wherein during the process of the upgrade module burning the flash, the dynamic file library in the flash is erased and rewritten. If the application management module and the upgrade module still need to access the dynamic library files, the dynamic library files relocated to the memory directory are used.

6. The method for secure firmware upgrade of a compact embedded Linux system according to claim 1, wherein the upgrade module calls the graphics library according to the display control parameters to display upgrade-related information, and the upgrade-related information includes the burning progress and burning prompts.

7. The method for secure firmware upgrade of a compact embedded Linux system according to claim 1, wherein before the upgrade module burns the upgrade firmware into the flash, it checks whether the upgrade firmware exists. If it does not exist, an error is prompted and the upgrade is exited, and the system is restarted; if it exists, the legality of the upgrade firmware is verified. If it is illegal, the upgrade is exited and the system is restarted. After the upgrade verification is successful, the firmware is burned into the flash, and the upgrade-related information is displayed according to the display control parameters. After the upgrade is successful, the system is restarted.

8. The method for secure firmware upgrade of a compact embedded Linux system according to claim 1, wherein the process communication is one of pipe communication, message queue communication, shared memory communication, and socket communication.

Images