Method for updating firmware of embedded system and firmware updating system

Abstract

The application discloses a method for updating embedded system firmware and a firmware updating system. The method comprises the following steps: receiving a hot patch instruction issued by a host, and storing a patch file carried by the hot patch instruction into a preset patch storage area; the patch file is used for updating target firmware in the embedded system; checking the integrity of the patch file stored into the preset patch storage area to obtain a checking result; when the checking result indicates that the checking is successful, updating the target firmware according to the patch file and a corresponding structure array of the target firmware; the structure array is used for describing attribute information of the target firmware. According to the application, the patch file is stored into the preset patch storage area and checked, so that the loading and activation of the patch can be completed in the process of normal operation of the system, without restarting the system or interrupting main business functions, and the real-time updating of the embedded system firmware is realized.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a method and system for updating firmware in an embedded system. Background Technology

[0002] In the field of embedded systems, firmware serves as the underlying core carrier of system functions, and its stability and maintainability are crucial. With the iteration of product functions and the fixing of defects, firmware updates have become a regular requirement. Traditional firmware update methods mainly rely on erase and write operations on storage media, such as completely burning the new firmware version into Flash memory. However, this update method usually requires restarting the system, adding Flash chips, resulting in high hardware costs and poor flexibility. Summary of the Invention

[0003] The purpose of this application is to provide a method and system for updating embedded system firmware, so as to realize real-time updates of embedded system firmware.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0005] According to one aspect of the embodiments of this application, a method for updating firmware of an embedded system is provided, comprising:

[0006] The system receives a hot patch command from the host and stores the patch file carried by the hot patch command in a preset patch storage area; the patch file is used to update the target firmware in the embedded system. The integrity of the patch files stored in the preset patch storage area is verified to obtain the verification result; When the verification result indicates that the verification is successful, the target firmware is updated according to the patch file and the corresponding structure array of the target firmware; the structure array is used to describe the attribute information of the target firmware.

[0007] According to one aspect of the embodiments of this application, a firmware update system is provided, the system comprising: The memory includes a read-only memory area and a random access memory area; the read-only memory area is used to store the target firmware of the embedded system; the random access memory area includes a preset patch storage area, which is used to store patch files; the patch files are used to update the target firmware. A processor, configured to implement the embedded system firmware update method in any embodiment of this application according to the patch file.

[0008] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: Processor; and A memory for storing executable instructions of a processor; wherein the processor executes the executable instructions to cause an electronic device to perform an embedded system firmware update method according to any embodiment of this application.

[0009] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the embedded system firmware update method in any embodiment of this application.

[0010] In the technical solution provided in this application embodiment, a hot patch command issued by the host is first received, and the patch file carried by the hot patch command is stored in a preset patch storage area. The patch file is used to update the target firmware in the embedded system. Then, the integrity of the patch file stored in the preset patch storage area is verified to obtain a verification result. When the verification result indicates successful verification, the target firmware is updated according to the patch file and the corresponding structure array of the target firmware. The structure array is used to describe the attribute information of the target firmware. In this way, by storing the patch file in the preset patch storage area and verifying it, the loading and activation of the patch can be completed during normal system operation, thereby achieving real-time firmware updates without restarting the system or interrupting the main business functions.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0013] Figure 1 A schematic diagram of a firmware update system architecture provided in one embodiment of this application is shown.

[0014] Figure 2 A flowchart illustrating an embedded system firmware update method according to an embodiment of this application is shown.

[0015] Figure 3 A schematic diagram of a patch project layout provided in one embodiment of this application is shown.

[0016] Figure 4 A schematic diagram of the jump check code logic provided in one embodiment of this application is shown.

[0017] Figure 5A A flowchart illustrating the embedded system firmware update method proposed in an embodiment of this application is shown.

[0018] Figure 5B A flowchart illustrating a target firmware update method provided in one embodiment of this application is shown.

[0019] Figure 6 A schematic block diagram of the firmware update control device provided in an embodiment of this application is shown.

[0020] Figure 7 A schematic diagram of the computer system architecture used to implement the technical solution of this application is shown. Detailed Implementation

[0021] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0022] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0023] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0024] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0025] When firmware is stored in Read-Only Memory (ROM), its rigid read-only nature prevents the content from being erased, rewritten, or reprogrammed after the device leaves the factory. Traditional update mechanisms based on Flash erasure / rewriting and bootloader-based firmware upgrades become completely ineffective in this scenario, making it impossible to fix firmware logic defects or optimize functionality. Existing solutions for embedded firmware updates are limited to hardware compromises and modifications: either redesigning the chip, replacing the ROM with erasable Flash or adding new erasable storage units; or adding external storage devices to the hardware circuitry to expand the hardware carrier for firmware updates. Both solutions require significant hardware design changes, extend development cycles, and substantially increase hardware costs. For embedded products already in mass production and with finalized hardware specifications, these solutions are not feasible and fail to fundamentally solve the dynamic update problem of ROM-based firmware from a software perspective.

[0026] This application addresses this problem by proposing a real-time patching method that "does not modify any bytes of ROM, but only redirects the function execution path." The method's concept is to abandon all traditional update logic that relies on hardware erasure and instead utilizes physical memory preservation technology to statically allocate a dedicated patch storage area in the system RAM that has no physical address overlap with the original firmware code and data segments. This achieves hard isolation between the patch code and the main program's runtime environment at the physical space level, eliminating security risks such as memory conflicts and unauthorized access at the source. Simultaneously, a global structure array is constructed in RAM to independently maintain the patch entry address and activation flag for each original function to be updated, achieving fine-grained and independent control of the patch status at the single-function level. During patch updates, only the patch file that has passed integrity verification needs to be stored in the reserved storage area. By modifying the entry address and activation flag of the corresponding element in the structure array in RAM, the execution path of the original function is redirected, causing all subsequent calls to that function to automatically jump to the patch function for execution. The entire update process requires no system reboot, no interruption of core business operations, and no modification to any instructions or data in the ROM. The entire process achieves dynamic firmware logic updates solely through software-level path scheduling and memory management. This concept of "trading space for possibility and replacing code modification with path redirection" is groundbreaking in the field of embedded systems with non-erasable firmware.

[0027] Figure 1 A schematic diagram of a firmware update system architecture provided in one embodiment of this application is shown.

[0028] like Figure 1 As shown, the firmware update system in this embodiment includes a processor CPU and an embedded system, wherein the embedded system includes a read-only memory (ROM) and a random access memory (RAM).

[0029] Read-only memory (ROM), as a non-volatile read-only storage medium, is used to embed the original factory firmware that has been burned into the memory chip at the factory and cannot be erased or rewritten. This firmware includes system boot code, hardware initialization programs, core function functions, and basic operating logic, adapting to hardware application scenarios where the firmware cannot be erased or upgraded after the chip is fabricated. Random access memory (RAM), as a high-speed data storage area during system operation, is mainly used to quickly read and write runtime information such as program execution stack, temporary variables, and dynamic data.

[0030] In one embodiment, a contiguous physical memory region can be explicitly declared and allocated as a pre-defined patch storage region in the system linker script. This ensures that the physical address of this region completely avoids overlap with the address spaces of the main firmware's code segment, read-only data segment, data segment, and uninitialized data segment. Simultaneously, it strictly prohibits all code and data segments of the main firmware from linking to this region, thereby achieving hard physical isolation between the patch file storage region and the firmware runtime space, fundamentally preventing security risks such as memory conflicts and unauthorized access. The pre-defined patch storage region stores patch files, which encapsulate the function execution logic in the ROM firmware that needs to be corrected, replaced, or reimplemented. These patch files are the core data carrier for enabling real-time firmware updates.

[0031] In one embodiment, the firmware of the embedded system maintains a global structure array. The number of elements in this array corresponds to the number of functions that can be patched within the firmware. Each array element uniquely corresponds to a patchable function and stores a function identifier, a patch function entry address pointing to the physical location of the patch function, and an activation flag indicating whether the patch function is active. Furthermore, uniform jump check code can be pre-embedded at the entry point of each patchable function. During actual system runtime, this code determines whether to jump to the patch function within a preset patch storage area based on the activation flag status of the corresponding element in the structure array and the patch function entry address.

[0032] The firmware update system in this embodiment, through the isolation design of the hardware memory layout and the mutual coordination between the firmware software-level patch management and jump execution logic, can stably achieve real-time function-level updates and rapid unloading and rollback of the firmware in the ROM without the need to add an additional non-volatile memory Flash chip, restart the device, or interrupt the operation of core services.

[0033] The method for updating embedded system firmware provided in this application will be described in detail below with reference to specific embodiments.

[0034] Figure 2A flowchart illustrating an embodiment of an embedded system firmware update method provided in this application is shown. The implementation process of the technical solution of this application will be described below using a terminal device as the execution subject. Figure 2 As shown, the embedded system firmware update method provided in this embodiment includes steps 210 to 230, as detailed below: Step 210: Receive the hot patch command issued by the host and store the patch file carried by the hot patch command in the preset patch storage area; the patch file is used to update the target firmware in the embedded system.

[0035] Specifically, the host computer or debug controller is connected to the embedded system via a wired or wireless communication interface. This communication interface can be a universal asynchronous transceiver, a serial peripheral interface, an integrated circuit bus, etc. A master-slave communication relationship is established between the host and the embedded system: the host, as the active party, sends commands and data, while the embedded system, as the passive party, receives and executes the corresponding operations. The host can send hot-patch instructions to the embedded system firmware. These instructions control the embedded system to update functions in the target firmware without restarting the system or program. The protocol typically includes fields such as instruction type identifier, the starting address of the preset patch storage area, data packet length, packet sequence number, and checksum.

[0036] The target firmware is the original program that is currently running and needs to be updated, stored in the embedded system's read-only memory. This firmware typically includes multiple functions, such as system boot functions, hardware initialization functions, and core business function functions. Because the target firmware is stored in ROM, its code and data cannot be erased or modified during normal operation, therefore, it cannot be upgraded using traditional Flash rewriting methods.

[0037] A patch file is a file specifically generated for embedded systems, containing new code and related data for replacing or modifying one or more original functions in the target firmware. Patch files typically contain sections such as code segments, read-only data segments, data segments, and block start symbol segments, with the link start addresses of all these segments forcibly specified to a pre-reserved, physically reserved patch storage area. Optionally, this file can be generated by developers writing the function logic to be updated in the patch project, using a cross-compilation toolchain and a dedicated linker script; its file format can be binary. It's important to note that, unlike a complete firmware image, a patch file usually only contains the changed or added function logic, not the entire firmware, thus resulting in a smaller size, faster transmission, and more flexible loading. In actual firmware updates, the new function logic in the patch file needs to be verified and activated before it takes effect.

[0038] A pre-defined patch storage area is a logically or physically independent memory space in an embedded system specifically used to store patch files. This area is isolated in address space from the main firmware code and data segments required for normal system operation, ensuring that patch code will not cause memory conflicts or illegal accesses to the original firmware during execution. For example, the pre-defined patch storage area can be partitioned using various techniques, including but not limited to: physical memory reservation based on linker scripts, memory page partitioning and permission configuration based on the operating system, and virtual memory address mapping and access control. It should be noted that regardless of the method used to partition the pre-defined patch storage area, its core purpose is to provide a secure, isolated, and executable storage environment for patch files during system startup or operation.

[0039] Step 220: Verify the integrity of the patch files stored in the preset patch storage area to obtain the verification results.

[0040] Specifically, because the communication interface of terminal devices may be affected by electromagnetic interference, clock skew, buffer overflows, etc., a single bit flip may occur in an instruction or constant in the patch file. If it is directly activated and executed without verification, the processor may jump to the error code and trigger an illegal instruction exception, memory access violation, or infinite loop, which may lead to system crash or even hardware damage in severe cases. Therefore, the patch file needs to be verified before loading the patch to ensure that no bit errors, byte loss, or data tampering occur during the entire process of the patch data being transferred from the host to the embedded system and written to the preset patch storage area. Optionally, the verification of the patch file can be implemented using a cyclic redundancy check algorithm or a hash algorithm.

[0041] Step 230: When the verification result indicates that the verification was successful, update the target firmware according to the patch file and the corresponding structure array of the target firmware.

[0042] Specifically, a successful verification result indicates that the integrity of the patch file has not been compromised and it is ready to be activated and executed.

[0043] The structure array is used to describe the attribute information of the target firmware. Each element in the array corresponds to a function in the target firmware that supports patching. Optionally, the function in the target firmware can be a primitive function such as a hardware initialization function or a core business function. It includes the specific code of all program behaviors, such as a series of operation steps, algorithm processing flow, data reading and writing and operation processing, input parameter parsing and return value calculation, which are fully implemented when the system calls and executes it.

[0044] For example, the original functions of the target firmware can be verification and calculation functions to ensure data integrity, peripheral driver reading interfaces for hardware interaction, or communication processing functions responsible for data transmission and protocol parsing, covering various basic functions and core business processing units in embedded systems. The new execution logic (patch functions) encapsulated in the patch file is typically redesigned and implemented to address defects, functional deficiencies, or new business requirements in the original functions, and differs clearly from the original execution logic. For instance, if the original function directly reads the value of the target hardware register without prior state configuration and verification, the patch function can be optimized to perform specified bit setting, state calibration, or legality verification operations on the hardware register before performing the read operation, thereby effectively correcting vulnerabilities in the original logic, improving hardware interaction reliability, or adding new functional features. In this way, by precisely replacing the execution logic of a single function, various update requirements such as firmware function-level defect repair, functional expansion and enhancement, operational parameter optimization and adjustment, and hardware compatibility improvement can be flexibly achieved without interrupting system operation or re-erasing, re-burning, or upgrading the entire firmware embedded in the ROM.

[0045] In one embodiment of this application, the method of updating the target firmware according to the patch file and the corresponding structure array of the target firmware can be as follows: The system first maintains a global structure array element for each original function that supports patching. This element contains a patch function entry address field and an activation flag field. At the same time, it inserts jump check code at the entry point of each original function. When the verification is successful and the patch needs to be activated, the system writes the patch function entry address parsed from the patch file into the entry address field of the corresponding element and sets the activation flag to a valid value. After that, when the original function is called, the jump check code will automatically jump to the patch function for execution according to the activation flag.

[0046] In another embodiment of this application, the method of updating the target firmware according to the patch file and the target firmware corresponding structure array can also be as follows: during the design phase of the embedded system firmware, all functions that may be patched are indirectly called through a function pointer table (similar to a system call table or virtual function table). Each original function is no longer called directly, but is called through the corresponding function pointer in the table. When the patch is updated, the system only needs to replace the pointers to the original functions in the table with pointers to the patch functions in the patch storage area. Subsequently, all places that are called through the table will automatically execute the new logic.

[0047] In another embodiment of this application, the method of updating the target firmware based on the patch file and the corresponding structure array of the target firmware can also be as follows: The system uses the hardware breakpoint register or debug monitor mechanism built into the embedded processor to set a hardware execution breakpoint for the original function that needs to be updated; when the program executes to the original function, the processor triggers a breakpoint exception, and in the exception handler, it determines whether the current function needs to be patched. If so, the value of the program counter is modified to jump to the patch file in the patch storage area to continue execution. This method relies on the processor's support for hardware breakpoints and the number of breakpoints is limited (usually 2 to 4), making it suitable for the debugging stage or scenarios with a small number of patches.

[0048] In the technical solution provided in this application embodiment, a hot patch command issued by the host is first received, and the patch file carried by the hot patch command is stored in a preset patch storage area. The patch file is used to update the target firmware in the embedded system. Then, the integrity of the patch file stored in the preset patch storage area is verified to obtain a verification result. When the verification result indicates successful verification, the target firmware is updated according to the patch file and the corresponding structure array of the target firmware. The structure array is used to describe the attribute information of the target firmware. In this way, by storing the patch file in the preset patch storage area and verifying it, the loading and activation of the patch can be completed during normal system operation, thereby achieving real-time firmware updates without restarting the system or interrupting the main business functions.

[0049] In one embodiment of this application, before receiving a hot patch instruction from the host, a preset patch storage area can be first divided, specifically including: obtaining the physical address range occupied by the code segment and data segment of the target firmware in the physical memory of the embedded system; selecting a continuous physical memory area that does not overlap with the physical address range as the preset patch storage area; wherein, the code segment and data segment of the target firmware are prohibited from being linked to the preset patch storage area.

[0050] Specifically, the code segment, often called the .text segment, is a memory area in embedded system firmware used to store executable instructions (i.e., raw function code). During compilation and linking, the compiler collects all machine instructions generated from functions in the source file and places them into the code segment. The code segment is read-only because the instructions themselves should not be modified during program execution. The data segment is a memory area in firmware used to store initialized global and static variables. Unlike the code segment, the contents of the data segment are readable and writable during program execution, and therefore are usually mapped to random access memory in the memory layout. The data segment can be further divided into read-only data segments and read-write data segments.

[0051] The physical address range refers to the continuous interval in physical memory defined by the start address and end address (or the start address plus the length) of a memory region (such as the code segment or data segment) in an embedded system. Obtaining the physical address range of the code segment and data segment of the target firmware is to clarify the address space already occupied by the target firmware, thereby facilitating the subsequent search for a completely non-overlapping blank physical memory region as the preset patch storage area.

[0052] Preventing the code and data segments of the target firmware from being linked to the preset patch storage area means that during the compilation and linking of the main firmware, constraint directives in the linker script explicitly require the linker not to allocate any sections (including code segments, read-only data segments, and data segments) from any object file to the preset patch storage area. By prohibiting linking in this way, it is ensured that the firmware's binary image will not contain any addresses from the preset patch storage area, thus achieving hard reservation of physical addresses at the binary level. Even if pointer errors occur in subsequent programs, the preset patch storage area will not be actively accessed due to the firmware's own linking, further enhancing the security of the isolation.

[0053] For example, the process of dividing a pre-defined patch storage area can be achieved by developers explicitly specifying a contiguous memory region in the system linker script that does not physically overlap with the original firmware code segment, read-only data segment, or data segment by declaring a memory region. Simultaneously, during firmware linking, all segments are restricted from linking to this region. For instance, if the system's physical RAM address range is 0x140000 to 0x170000, and the original firmware occupies 0x140000 to 0x15FFFF, then a region starting at 0x160000 with a length of 0x10000 can be declared in the linker script and identified as a dedicated patch storage area. In this way, the system achieves hard isolation between the patch code and the original firmware's runtime space at the binary level, without relying on an operating system or memory management unit, making it suitable for small, lightweight, or memory-management-free embedded systems.

[0054] In another embodiment of this application, the method of presetting the patch storage area can also be: configuring the access permissions of a specified physical memory page in the corresponding physical memory of the embedded system to read-only or non-executable, and determining the specified physical memory page with the configured permissions as the preset patch storage area.

[0055] Specifically, a designated physical memory page is one or more specific and contiguous memory pages selected by the embedded system from physical memory via software, used to store patch files. A memory page is the basic unit for address mapping and access control by the memory management unit or memory protection unit, and its size is typically a fixed value such as 4KB, 8KB, or 16KB, determined by the processor architecture and operating system configuration.

[0056] Access permissions are access control attributes set by the memory management unit or memory protection unit for a specific memory region (such as one or a group of memory pages). They define the legal scope of read, write, and execute operations that the processor can perform on that region. Common access permissions include: readable, writable, executable, and combinations thereof or prohibited accesses. By setting appropriate access permissions for specified physical memory pages, it is possible to effectively prevent patch files from being accidentally modified during storage or execution, or to prevent malicious code injection.

[0057] For example, the implementation process of this embodiment can be as follows: the system first allocates one or more contiguous memory pages from physical memory through the operating system's memory management module and marks these pages as dedicated pages for patch storage. Subsequently, by configuring the access permissions of the memory protection unit or page table, the access attributes of these pages are set to "read-only" and "non-executable," while restricting write access to this area by other system tasks or kernel modules. This process can be completed before system startup or patch loading, without the need for statically reserving memory during compilation and linking, thus offering greater flexibility. Furthermore, since the permission configuration is enforced by hardware or the operating system, even if an illegal pointer or malicious code attempts to write to the patch storage area, an access exception will be triggered and captured by the system, thereby further enhancing the security of the patch code. Therefore, this approach is applicable to embedded systems that support memory protection units or memory management units.

[0058] In another embodiment of this application, the method of setting the preset patch storage area can also be: configuring the access permissions of the preset virtual address space in the embedded system to read-only or non-executable, and determining the preset virtual address space with the permission configured as the preset patch storage area.

[0059] Specifically, a pre-defined virtual address space refers to a fixed range of virtual addresses reserved in advance during the system's design or initialization phase. This region is specifically used for mapping patch files. Mapping refers to the process of establishing a correspondence between virtual addresses and physical addresses in an embedded system with a memory management unit. That is, the system uses page tables or block descriptors to point a contiguous range of virtual addresses to a range of physical addresses. This range can be contiguous or non-contiguous, allowing the memory management unit to automatically translate the virtual address into an actual physical address when the processor accesses it, thus enabling reading and writing of the corresponding physical memory or peripheral registers. It can be understood that using a pre-defined virtual address space allows the entry address of the patch function to be fixed during the compilation and linking of the patch project (because the virtual address is known), simplifying the address setting during patch generation. Furthermore, since the virtual address space is fixed, even if the system restarts or different versions of patches are loaded multiple times, only the mapping needs to be re-established; there is no need to modify the absolute address references in the patch file.

[0060] For example, the implementation process of this embodiment can be as follows: During runtime, the system uses a virtual memory management mechanism to reserve a contiguous range of virtual addresses in the virtual address space as a preset patch storage area, and maps it to several physical memory pages. Simultaneously, by setting permission bits (e.g., read / write / execute permissions) in the page table entries, the access permissions of this virtual area are configured to allow only reading and execution, prohibiting writing, or temporarily granting write permissions during patch loading and immediately closing them after loading is complete. Since different processes or kernel modules have their own virtual address spaces, the patch storage area can be visible only to specific execution contexts (e.g., the patch management process or kernel module), while remaining hidden from other contexts. This approach utilizes the address isolation and permission protection mechanisms provided by the memory management unit, allowing functions in the patch file to be called through virtual addresses like ordinary functions. This is particularly suitable for complex embedded systems that require dynamic loading of multiple patches or have varying patch sizes.

[0061] In one embodiment of this application, before receiving the hot patch instruction issued by the host, it is also necessary to generate a patch file. That is, firstly, a patch function is generated according to the function execution logic that the target firmware needs to implement, and the link start address of the patch function is specified in a preset patch storage area. The patch function accesses global variables in the target firmware by referencing the absolute address of global variables. Global variables are variables defined in the target firmware that can be called by multiple functions. The patch file is generated according to the patch function.

[0062] Specifically, a patch function is a function rewritten in the patch project, whose purpose is to replace the corresponding original function in the target firmware. The function prototype of the patch function (including return value type, parameter type and number) must be completely consistent with the original function to ensure that the stack frame and register state are correct at the time of the call. The function body of the patch function can be a complete rewrite of the original function, or it can reuse the original logic by calling the original function internally through function pointers, and then add new processing steps on top of it, such as pre-verification and post-correction.

[0063] The link start address refers to the memory location of the first instruction or the first piece of data for the patch function and its respective segments (e.g., code segment, read-only data segment, data segment, etc.) during the compilation and linking of the patch project. This address is explicitly specified through relevant statements in the linker script (such as AT or >region) and must fall within the address range of the predefined patch storage region. Figure 3As shown, in the memory layout of the patch project, the 48KB space from 0x160000 to 0x16C000 can be used to store the code segment and read-only data segment, while the 16KB space from 0x16C000 to 0x170000 is used to store the data segment and BSS segment. Based on this layout, if the default starting address of the patch storage area is 0x160000, then the link start address of the patch function's code segment can be set to 0x160000. Once the link start address is fixed, all absolute address references in the patch function (including function calls, jump instructions, and accesses to global variables) will be generated based on this address, thereby ensuring that the patch can execute correctly after being loaded into the correct location.

[0064] An absolute address is a fixed physical address of a memory location or function, or a fixed virtual address in a virtual memory environment. This address is determined during compilation and linking and will not be offset during program runtime. In embedded systems, every global variable and every function has its corresponding absolute address. When a patch function needs to access a global variable defined in the target firmware, since the patch project and the main firmware are compiled and linked separately, the patch project cannot directly reference variables in the main firmware by variable name; otherwise, it would result in duplicate definitions or undefined symbols. Therefore, in this application, the patch function needs to directly access global variables using absolute addresses. This prevents the redefinition of variables with the same name within the patch project, thus ensuring safe and accurate manipulation of data in the original firmware without introducing additional copies or address conflicts.

[0065] In one embodiment of this application, before performing the target firmware update, a corresponding structure array needs to be constructed for the firmware. The specific process includes: counting the number of functions in the target firmware that support patching; creating a structure array with the same number of elements as the number of functions based on a preset format, such that one element in the structure array corresponds to one function that supports patching; the preset format includes a function identifier field, an entry address field, and an activation flag field; the entry address field indicates the storage address of the function; the activation flag field indicates whether the patch function in the patch file is activated. After construction, the structure array can be traversed, and the activation flag field corresponding to all elements can be initialized to inactive, and the entry address field corresponding to all elements can be initialized to an invalid address or the storage address of the original function.

[0066] Specifically, a structure array is a composite data structure in the C language. It stores multiple structures of the same type contiguously in a memory region, and each array element is an independent structure variable, corresponding to a primitive function in the firmware that supports patching. Structure arrays are typically placed in random access memory so that their field contents (such as activation flags and entry addresses) can be dynamically modified at runtime without modifying the firmware code in read-only memory.

[0067] The preset format refers to a predefined array of structures that specifies the data fields required to manage a single patch interface, along with their order, type, and bit width. In this application, the preset format includes at least three fields: a function identifier field to uniquely distinguish different original functions, an entry address field to store the entry address of the patch function in the patch file, and an activation flag field to indicate whether the patch file is effective or activated. The activation flag field is used to fill in an activation flag, which can include an inactive state and an activated state, represented by 0 and 1 respectively. In the inactive state, even if the patch file has been loaded and stored in the preset patch storage area, the corresponding original function will not execute the patch logic but will continue to execute the original function body; only in the activated state will the original function in the firmware execute the patch function logic corresponding to the patch file.

[0068] Optionally, the preset format can be fixed in the firmware header file in the form of a C language structure type definition, so that patch management operations such as initialization, query, update, and uninstallation all follow this format, thereby ensuring code consistency and maintainability.

[0069] An invalid address is a specific value filled in when no valid patch function entry is stored. This value should not fall within any actual executable memory range and is typically NULL (0x00000000) or a specific error address (such as 0xFFFFFFFF). During the system startup initialization phase, all entry address fields are set to invalid addresses.

[0070] For example, the construction process of a structure array can be as follows: First, at the firmware source code level, a specific macro tag is added to each original function that needs to support patching. This macro tag is expanded into an inline assembly or compiler-built-in function during the preprocessing stage to declare that the function has patchable attributes and reserve the insertion position for jump check code. At the same time, the compiler automatically collects information about all functions with macro tags (such as function names and identifiers) during the compilation process and generates a mapping table containing function identifiers and expected indices for use when constructing the structure array later. Based on this, during the linking stage, the linker script allocates a fixed and contiguous address space for the global structure array in random access memory according to the number of patchable functions collected and the preset format, ensuring that the array size is strictly consistent with the number of functions, and reserves a function identifier field, entry address field, and activation flag field for each element to complete the construction of the structure array. Finally, during the early initialization phase of system startup, the entire structure array is traversed, and the entry address field of all elements is initialized to an invalid address, and all activation flag fields are initialized to an inactive state, thereby ensuring that all original functions are executed according to their original logic before any patches are loaded.

[0071] In this embodiment, the structure array serves as the core management data structure, enabling each patchable original function to independently maintain its patch entry address and activation status, thus achieving selective updates of multiple interfaces without interference. Simultaneously, separating the storage of the patch function's entry address from the activation flag allows the patch file to be pre-loaded and temporarily stored in reserved memory after verification, awaiting an appropriate time to set the activation flag to valid, thereby achieving "pre-loading". The system employs a flexible update strategy of "delayed activation." Furthermore, since the structure array is stored in RAM, while the jump check code is embedded in ROM, the system only needs to read the state in RAM to determine the execution path during runtime, without modifying any instructions in the read-only memory. This allows for dynamic replacement of function logic without relying on the Flash chip or restarting the system.

[0072] In one embodiment of this application, after creating a structure array with the same number of elements as the number of functions based on a preset format, the method further includes: pre-inserting jump check code at the entry point of each function that supports patching in the target firmware; the jump check code is used to determine whether the function jumps to the patch function in the patch file for execution based on the activation flag and entry address in the structure array.

[0073] Specifically, the jump-checking code is a sequence of instructions pre-embedded at the entry point of each original function that supports patching, responsible for dynamically determining the execution path at runtime. This code typically consists of several assembly or C inline instructions, such as... Figure 4As shown, the core logic of the jump-checking code includes: when the original function is called, it queries the activation flag field and entry address field of the element corresponding to the original function in the structure array. If the activation flag field is active and the entry address field is not empty, it uses a function pointer to jump to the patch function indicated by the entry address field to start execution; if the activation flag field is inactive or the entry address field is empty, it continues to execute the function body of the original function. It should be noted that the jump-checking code is fixed in read-only memory and is not modified itself, but the contents of the structure array it reads can change dynamically, thus enabling flexible switching of function logic execution. Furthermore, the overhead of the jump-checking code is usually very small (a few instructions), and its performance impact on the original function is negligible.

[0074] For example, the actual insertion of jump-checking code can be done in one or a combination of two ways: First, by using compiler attributes or custom segments, the marked original functions are placed in a dedicated code segment, and then a specific padding template is configured for that segment in the linker script, causing the linker to automatically fill in the jump-checking instruction sequence at the start offset of each function within that segment. Second, static code instrumentation tools are used. After compiling and generating the object file or executable file, the symbol table in the file is parsed to find the entry offset of each patchable function. The jump-checking code sequence is then directly overwritten before the original instructions, and the overwritten original instructions are moved after the jump logic to ensure that the original functionality is not lost.

[0075] Through the instrumentation process described above, the insertion of jump check code is organically integrated into the compilation, linking, and startup processes. This ensures a one-to-one correspondence between the patch management data structure and patchable functions, and also enables the ability to dynamically control the function execution path through the state in RAM, provided that the ROM-fixed code is unmodifiable.

[0076] It's important to note that if function pointers are used to indirectly access and trigger jump checking code—for example, by pointing a function pointer to the original function entry point to initiate its internal jump checking logic—then the defined function pointer type must strictly match the function prototypes of the original function and the patch function. This means all three must have identical return types, parameter lists, and the number of parameters. Only by ensuring complete consistency in function prototypes can the processor correctly complete parameter passing, return value reception, and maintain the integrity of the program's stack frame. If the function prototypes do not match, it will directly cause parameter passing errors, stack frame corruption, and other problems, ultimately leading to program crashes or corrupted business data.

[0077] In one embodiment of this application, after completing the above-mentioned pre-process, a hot patch command issued by the host can be received, and the patch file carried by the hot patch command can be stored in a preset patch storage area. Then, the patch file stored in the preset patch storage area is verified to obtain a verification result. The verification process may include: receiving a verification command issued by the host, and obtaining the starting address and data length of the patch file in the preset patch storage area from the verification command; calculating a first verification value of the patch file based on the starting address and data length of the patch file in the preset patch storage area; sending the first verification value to the host so that the host can match the first verification value and the second verification value; the second verification value is the verification value calculated by the host based on the starting address and data length of the patch file in the host; if the first verification value and the second verification value match, a verification result of successful verification is generated; if the first verification value and the second verification value do not match, a verification result of failed verification is generated.

[0078] Specifically, the verification command is sent by the host to the embedded system to trigger the embedded system to perform integrity verification on the patch files stored in the preset patch storage area. This command typically includes an opcode (e.g., 0xCC indicates verification to be started), the starting address field of the patch file in the reserved memory, the data length field, and an optional verification algorithm identifier field.

[0079] The first checksum is a fixed-length value calculated by the embedded system based on the starting address and data length carried in the checksum command sent by the host. It reads the stored patch file data from the preset patch storage area and calculates it using a preset checksum algorithm (such as CRC-32, CRC-16, or cumulative checksum). This value is a mathematical summary of the patch data actually stored on the embedded system side, uniquely representing the integrity status of that data segment. After calculation, the embedded system returns the first checksum to the host via the communication interface as the basis for subsequent comparisons.

[0080] The second checksum is a verification result calculated locally by the host based on the original patch file it stores. Optionally, the host can read the patch file from its local disk or memory before or after issuing the hot patch instruction and calculate the second checksum using the exact same verification algorithm, starting address, and data length as the embedded system. Since the patch file stored in the host is the original version that has not been transmitted or written, the second checksum represents the "standard" or "expected" integrity characteristics of the patch file.

[0081] During the verification process, the host compares the second verification value with the first verification value returned by the embedded system to determine whether the patch file on the embedded system side is completely consistent with the original patch file on the host side. If the first verification value matches the second verification value, it means that the patch file stored in the preset patch storage area on the embedded system is completely consistent with the original patch file stored on the host side at the binary level. That is, no data errors, omissions, or tampering occurred during the entire process of the patch file being transferred from the host to the embedded system and written to memory. If the first verification value does not match the second verification value, it means that there is a difference between the patch data stored on the embedded system side and the original patch file on the host side. Possible reasons include, but are not limited to: interference in the communication link between the host and the embedded system causing data transmission errors, memory access errors occurring when the embedded system writes the patch file, incorrect parsing of the starting address or data length of the patch file during instruction transmission, or hardware failure in the preset patch storage area. When a mismatch occurs, the system will not activate the patch but will trigger an error handling mechanism, such as the host reporting "verification failed" to the user, automatically retransmitting the patch file, or recording an error log for subsequent analysis.

[0082] This embodiment introduces a two-way verification mechanism, which allows the host and embedded system to calculate and compare verification values ​​separately. Only when they match are the patch activated. This effectively shields corrupted patch data and ensures that only complete and correct patches can enter the firmware function update execution path, thus significantly improving the reliability, security, and robustness of the real-time patching solution.

[0083] In one embodiment of this application, after completing the verification and obtaining the verification result indicating successful verification, the target firmware update operation can be performed according to the patch file and the corresponding structure array of the target firmware. The specific process may include: obtaining the entry address of the patch function in the patch file; the patch function includes function code used to replace at least one function in the target firmware; obtaining the function identifier of at least one function in the target firmware, and writing the entry address of the patch function into the structure array, with the entry address field corresponding to the function identifier; setting the activation flag field corresponding to the function identifier in the structure array to active.

[0084] Specifically, the entry address of a patch function refers to the memory address of the first instruction of the patch function within the preset patch storage area, i.e., the starting position when the processor begins executing the patch function. This address is determined by the linker script during the compilation and linking of the patch project, based on the layout of the preset patch storage area and the offset of the patch function within the code segment. During patch activation, the system needs to parse this entry address from the patch file and write it into the entry address field of the corresponding original function in a structure array, so that the jump check code can accurately jump to this address to execute the patch logic when the conditions are met.

[0085] For example, suppose the target firmware contains a raw function named `calculate_crc` that calculates the CRC16 checksum of the data. This function is marked as patchable, and its entry point already contains pre-inserted jump check code. During system operation, developers discover that the original CRC16 algorithm has a high collision rate and needs to be replaced with the more robust CRC32 algorithm. To this end, developers rewrite a patch function named `calculate_crc_patch` in the patch project. This function implements the CRC32 algorithm and is compiled and linked into a pre-defined patch storage area (e.g., entry address 0x160200).

[0086] Subsequently, the host computer downloads the patch file to the embedded system's preset patch storage area via the communication interface and verifies the data integrity through CRC check. Next, the system first parses the entry address (0x160200) of the patch function `calculate_crc_patch` from the stored patch file; then, based on the function identifier (e.g., ID=5) corresponding to the original target function `calculate_crc`, it locates the 5th element in the structure array; next, it writes the entry address 0x160200 into the "entry address field" of this element; finally, it sets the "activation flag field" of this element to a valid value of 1. After completing the above operations, when the application calls `calculate_crc` again, its jump check code at the entry point queries the corresponding element in the structure array, finds that the activation flag is valid and the entry address is not empty, and automatically jumps to 0x160200 to execute the `calculate_crc_patch` function, thus using the new CRC32 algorithm instead of the original CRC16 algorithm.

[0087] It should be noted that the entire process of this embodiment does not require restarting the system or modifying the original code in the ROM, and only updates the specified original functions in the target firmware, without affecting other function logic.

[0088] In one embodiment of this application, during normal system operation, the patch function in the patch file is triggered only when the upper-layer application (including control commands issued by the host through the peripheral communication interface, patch management tasks within the firmware, etc.) completes a full and orderly update operation on a specified element in the structure array. That is, the upper-layer application must first write a valid patch function entry address into the entry address field of the corresponding element, and then set the activation flag of that element to a valid state. At this time, the jump check code of the original function entry will automatically jump to the patch function in the preset patch storage area for execution based on the updated array information, thus switching the original function to patch execution logic. Conversely, if the upper-layer application does not update the structure array elements, or only updates some fields and does not complete the configuration of the activation flag, the jump check code will maintain the default execution flow and continue running the original function body; the original business logic of the interface will not change.

[0089] Thus, this embodiment allows for the independent activation or deactivation of patch jump behaviors for single or multiple original functions based on actual needs, ensuring that update operations for different functions are independent and do not interfere with each other. Furthermore, patch activation and deactivation only require modifying the field data of the structure array, eliminating the need for firmware re-flashing or restarting the embedded system. This ultimately achieves uninterrupted, real-time, and selective function-level dynamic firmware updates.

[0090] In one embodiment of this application, after updating the execution logic of at least one original function in the target firmware according to the patch file, a patch uninstallation process can also be executed, that is, receiving a patch uninstallation instruction issued by the host, and obtaining the function identifier of at least one function in the target firmware according to the patch uninstallation instruction; setting the activation flag field corresponding to the function identifier in the structure array to inactive, and retaining the patch file corresponding to the function stored in the preset patch storage area.

[0091] Specifically, the patch uninstallation instruction is sent from the host to the embedded system to instruct the system to restore a certain activated patch interface to an inactive state. This instruction typically includes an opcode (e.g., 0xDD indicates patch uninstallation) and the function identifier or corresponding structure array index of the original function to be uninstalled.

[0092] In this application's solution, during the patch uninstallation process, the system only needs to set the activation flag field, which was originally active, to inactive to uninstall the patch function, without modifying the contents of the entry address field (the original patch entry address is retained). Thus, if the same patch function needs to be reactivated subsequently, the activation flag only needs to be reset to active, without rewriting the entry address, simplifying the reactivation process.

[0093] Figure 5AA flowchart illustrating the embedded system firmware update method proposed in an embodiment of this application is shown. Figure 5A As shown, the embedded system firmware update method of this application embodiment includes steps 501-509, as detailed below: Step 501: Allocate a pre-defined patch storage area from the physical memory of the embedded system. During system design or initial startup, modify the linker script to declare a contiguous memory region that does not overlap with the physical addresses of the code and data segments as a pre-defined patch storage area when compiling and linking the main firmware. Also, restrict all segments of the main firmware from linking to this region.

[0094] Step 502: Construct a structure array for the target firmware in the embedded system and insert jump check code for the original functions that need patching. First, count the number of all original functions in the target firmware that support patching. Then, create a structure array with the same number of elements as the preset format (including function identifier field, entry address field, and activation flag field), ensuring that each element in the array uniquely corresponds to one original function. At system startup, iterate through the array, initializing the activation flag field of all elements to an inactive state and initializing all entry address fields to invalid addresses. Simultaneously, at the entry point of each original function that supports patching, insert jump check code using instrumentation. This code is configured to: if the activation flag is valid and the entry address is not empty, jump to the entry address to execute the patch function; otherwise, continue executing the original function body.

[0095] Step 503: Generate patch file. First, based on the new execution logic expected by the original function that needs to be updated in the target firmware, write the patch function. The function prototype (return value type, parameter type, and number) of the patch function must be strictly consistent with the original function. Then, use a cross-compilation toolchain to compile and link the patch project. During the linking stage, the linker script explicitly specifies the starting address of the link for the patch function and its various segments (code segment, read-only data segment, data segment, BSS segment) within the range of the preset patch storage area. After linking is complete, a binary patch file is generated.

[0096] Step 504: Receive hot patch command from the host. During normal operation of the embedded system, when a patch needs to be loaded, the host will send a hot patch command to the embedded system through the communication interface.

[0097] Step 505: Store the patch file carried by the hot patch instruction to the preset patch storage area. After receiving and confirming the hot patch instruction, the embedded system begins to receive patch file data subsequently sent by the host, and writes the received patch data byte by byte into the corresponding address space in the preset patch storage area according to the starting address specified in the hot patch instruction.

[0098] Step 506: Verify the patch files stored in the preset patch storage area to obtain a verification result. After receiving the verification command from the host, the embedded system reads the patch data from the reserved memory according to the starting address and length, calculates a first verification value using a predetermined verification algorithm, and then returns this value to the host. Simultaneously, the host calculates a second verification value for its local original patch file using the same verification algorithm, and then compares the two verification values. If they match, a successful verification result is returned to the embedded system; if they do not match, a failed verification result is returned.

[0099] Step 507: When the verification result indicates successful verification, obtain the entry address of the patch function in the patch file, and write the entry address of the patch function into the entry address field of the structure array corresponding to the target firmware, based on the function identifier of the target firmware. After successful verification, the embedded system first parses the entry address of the patch function from the stored patch file; then, based on the function identifier corresponding to the original function that needs to be updated in the target firmware, it locates the element corresponding to that function in the structure array; next, it writes the parsed patch function entry address into the entry address field of that element. At this point, the entry address field contains a valid patch function address, but the patch has not yet taken effect because the activation flag is still in an inactive state.

[0100] Step 508: Set the activation flag corresponding to the function identifier in the structure array to active.

[0101] Step 509: Receive the patch uninstallation command from the host and set the activation flag corresponding to the target firmware in the structure array to inactive according to the patch uninstallation command. After receiving the patch uninstallation command from the host, the embedded system parses it to obtain the original function identifier and finds the corresponding element in the structure array. Then, it sets the activation flag field of the element to inactive while keeping the content of the entry address field unchanged, still pointing to the patch function address. After completing this operation, the patch interface enters an inactive state. Subsequently, when the program calls the original function, the jump check code detects that the activation flag is invalid, ignores the entry address field, and continues to execute the original function body, thereby restoring the original function execution logic.

[0102] This application's technical solution achieves secure isolation and independent storage of patch files by allocating a pre-defined patch storage area in physical memory that is completely isolated from the original firmware address. This allows for dynamic switching of jump check code to the patch function execution without restarting the system or modifying the ROM's firmware, enabling real-time logic updates to one or more original functions. When restoring the original logic is required, simply receiving an uninstallation command from the host and setting the corresponding activation flag to an invalid value allows for instant rollback, while retaining the patch file for subsequent reactivation. The entire solution solves the problem of ROM firmware update inability without relying on a Flash chip, significantly saving hardware costs. Furthermore, the structure array independently manages the patch status of each interface, supporting selective, multi-interface independent updates, greatly improving the flexibility and reliability of embedded system firmware maintenance.

[0103] The following is a specific embodiment illustrating the content of this application, such as... Figure 5B As shown, the system first receives an update command from the host, loads the patch file, and stores it in a pre-defined, isolated patch storage area, completing the patch data storage. Then, the host sends a verification command, triggering the embedded system to perform a CRC (Cyclic Redundancy Check) integrity calculation on the complete patch file already stored in memory. The system then sends the calculated CRC value back to the host. The host compares the result with the pre-stored standard CRC value to determine if the CRC verification result of the current patch file meets the expected standard. If the verification result does not match, the system terminates the patch update process and jumps to the return step. If the verification result matches the expected result and confirms that the patch file transmission and storage are complete and error-free, the system follows an ordered writing rule of address first, then status. First, it writes the entry address of the patch function matching the interface to be updated into the corresponding entry in the firmware global structure array. Then, it assigns a value to the patch status flag of the entry to complete the patch activation configuration. After all the addresses and activation flags are configured, the patch update process ends and returns.

[0104] In one embodiment of this application, when the embedded system is executing its business process normally, the application calls a patchable original function in the target firmware via a function call. The processor first quickly locates the corresponding element in the global structure array based on the identifier of the current original function, and reads the activation flag field and entry address field in that element. Then, it determines whether the activation flag is in a preset activation state and whether the entry address is a non-invalid address. If both conditions are met, the processor immediately jumps to the patch function address indicated by the entry address field, starts executing the new logic in the patch function, and returns directly to the call point of the original function through the return instruction in the patch function after execution. If either condition is not met, i.e., the activation flag is invalid or the entry address is invalid, the processor sequentially executes the original instruction sequence (the code in the original function body) in the original function.

[0105] Thus, through this judgment and branching mechanism, the proposed solution can achieve real-time, lossless control of the original function execution path by relying solely on the dynamically changeable structure array state in RAM, without modifying the original instructions in ROM, interrupting the business execution process, or restarting the system. This constitutes the core dynamic switching capability of the entire real-time patching solution.

[0106] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0107] The following describes an apparatus embodiment of this application, which can be used to execute the system embedded system firmware update method described in the above embodiments of this application. Figure 6 A schematic block diagram of the firmware update control device provided in an embodiment of this application is shown. Figure 6 As shown, the firmware update control device provided in this application embodiment includes: The patch storage module 610 is used to receive a hot patch command issued by the host and store the patch file carried by the hot patch command in a preset patch storage area; the patch file is used to update at least one function corresponding to the target firmware in the embedded system; The patch verification module 620 is used to verify the patch files stored in the preset patch storage area to obtain a verification result; the verification is used to verify the integrity of the patch files. Firmware update module 630 is used to update at least one function in the target firmware according to the patch file when the verification result indicates that the verification is successful.

[0108] In one embodiment of this application, the patch verification module 620 is specifically used for: Receive a verification command sent by the host, and obtain the starting address and data length of the patch file in the preset patch storage area from the verification command; The first checksum of the patch file is calculated based on the starting address and data length of the patch file within the preset patch storage area; The first checksum is sent to the host so that the host can match the first checksum with the second checksum; the second checksum is a checksum calculated by the host based on the starting address and data length of the patch file in the host. If the first check value and the second check value match, a successful check result is generated; if the first check value and the second check value do not match, a failed check result is generated.

[0109] In one embodiment of this application, the firmware update module 630 is specifically used for: Obtain the entry address of the patch function in the patch file; the patch function includes function code for replacing at least one function in the target firmware; Obtain the function identifier of at least one function in the target firmware, and write the entry address of the patch function into the structure array, including the entry address field corresponding to the function identifier; Set the activation flag field in the structure array corresponding to the function identifier to active.

[0110] In one embodiment of this application, the firmware update control device further includes a firmware configuration module, which is specifically used for: Obtain the physical address range occupied by the code segment and data segment of the target firmware in the physical memory of the embedded system; A contiguous physical memory region that does not overlap with the physical address range is selected from the physical memory and used as a preset patch storage region; wherein, the code segment and data segment of the target firmware are prohibited from being linked to the preset patch storage region.

[0111] In one embodiment of this application, the firmware configuration module is specifically used for: Count the number of functions in the target firmware that support patching; A structure array with the same number of elements as the number of functions is created based on a preset format, such that one element in the structure array corresponds to one function that supports patching; the preset format includes a function identifier field, an entry address field, and an activation flag field; the activation flag field is used to indicate whether the patch function in the patch file is activated; Iterate through the array of structures, initialize the activation flag field of all elements to inactive, and initialize the entry address field of all elements to invalid address.

[0112] In one embodiment of this application, the firmware configuration module is specifically used for: At the entry point of each function that supports patching in the target firmware, jump check code is pre-inserted; the jump check code is used to determine whether the function should jump to the patch function in the patch file for execution based on the activation flag and entry address in the structure array.

[0113] In one embodiment of this application, the firmware configuration module is specifically used for: A patch function is generated based on the function execution logic required by the target firmware, and the link start address of the patch function is set in the preset patch storage area; wherein, the patch function accesses global variables in the target firmware by referencing the absolute address of global variables; the global variables are variables defined in the target firmware that can be called by multiple functions; The patch file is generated based on the patch function.

[0114] In one embodiment of this application, the firmware configuration module is specifically used for: Configure the access permissions of a specified physical memory page in the corresponding physical memory of the embedded system to read-only or non-executable, and determine the specified physical memory page with the configured permissions as the preset patch storage area; or Configure the access permissions of the preset virtual address space in the embedded system to read-only or non-executable, and determine the preset virtual address space with the configured permissions as the preset patch storage area.

[0115] In one embodiment of this application, the firmware update control device further includes a patch uninstallation module, which is specifically used for: Receive a patch uninstallation command issued by the host, and obtain the function identifier of at least one function in the target firmware according to the patch uninstallation command; Set the activation flag field corresponding to the function identifier in the structure array to inactive, and retain the patch file corresponding to the function stored in the preset patch storage area.

[0116] The specific details of the firmware update control device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0117] Figure 7 A schematic diagram of the computer system architecture used to implement the technical solution of this application is shown.

[0118] It should be noted that, Figure 7 The computer system 700 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0119] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 707 into random access memory (RAM). The RAM 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output interface 705 (I / O interface) is also connected to the bus 704.

[0120] The following components are connected to the input / output interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a local area network card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0121] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0122] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0123] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0124] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0125] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0126] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for updating firmware in an embedded system, characterized in that, include: Receive hot patch instructions from the host and store the patch file carried by the hot patch instructions in a preset patch storage area; The patch file is used to update the target firmware in the embedded system; The integrity of the patch files stored in the preset patch storage area is verified to obtain the verification result; When the verification result indicates that the verification is successful, the target firmware is updated according to the patch file and the corresponding structure array of the target firmware; the structure array is used to describe the attribute information of the target firmware.

2. The embedded system firmware update method according to claim 1, characterized in that, Before receiving a hot patch command from the host and storing the patch file carried by the hot patch command in a preset patch storage area, the method includes: Obtain the physical address range occupied by the code segment and data segment of the target firmware in the physical memory of the embedded system; A contiguous physical memory region that does not overlap with the physical address range is selected from the physical memory and used as a preset patch storage region; wherein, the code segment and data segment of the target firmware are prohibited from being linked to the preset patch storage region.

3. The embedded system firmware update method according to claim 1, characterized in that, The target firmware includes multiple functions that support patching; Before updating the target firmware based on the patch file and the structure array corresponding to the target firmware, the method further includes: Count the number of functions in the target firmware that support patching; A structure array with the same number of elements as the number of functions is created based on a preset format. Each element in the structure array corresponds to a function that supports patching. The preset format includes a function identifier field, an entry address field, and an activation flag field. The entry address field is used to indicate the storage address of the function. The activation flag field is used to indicate whether the patch function in the patch file is activated.

4. The embedded system firmware update method according to claim 3, characterized in that, The step of updating the target firmware based on the patch file and the structure array corresponding to the target firmware includes: Obtain the entry address of the patch function in the patch file; the patch function includes function code for replacing at least one function in the target firmware; Obtain the function identifier of at least one function in the target firmware, and write the entry address of the patch function into the entry address field corresponding to the function identifier in the structure array; Set the activation flag field in the structure array corresponding to the function identifier to active.

5. The embedded system firmware update method according to claim 3, characterized in that, After updating the target firmware according to the patch file and the structure array corresponding to the target firmware, the method further includes: Receive a patch uninstallation command issued by the host, and obtain the function identifier of at least one function in the target firmware according to the patch uninstallation command; Set the activation flag field corresponding to the function identifier in the structure array to inactive, and retain the patch file corresponding to the function stored in the preset patch storage area.

6. The embedded system firmware update method according to claim 3, characterized in that, After creating a structure array with the same number of elements as the number of functions based on a preset format, the method further includes: At the entry point of each function that supports patching in the target firmware, jump check code is inserted; the jump check code is used to determine whether the function should jump to the patch function in the patch file for execution based on the activation flag and entry address in the structure array.

7. The method for updating embedded system firmware according to claim 1, characterized in that, Before receiving a hot patch command from the host and storing the patch file carried by the hot patch command in a preset patch storage area, the method further includes: A patch function is generated based on the function logic required to be implemented by the target firmware, and the link start address of the patch function is set in the preset patch storage area; wherein, the patch function accesses global variables in the target firmware by referencing the absolute address of global variables; the global variables are variables defined in the target firmware that can be called by multiple functions; The patch file is generated based on the patch function.

8. The method for updating embedded system firmware according to claim 1, characterized in that, The step of verifying the patch files stored in the preset patch storage area to obtain the verification result includes: Receive a verification command sent by the host, and obtain the starting address and data length of the patch file in the preset patch storage area from the verification command; The first checksum of the patch file is calculated based on the starting address and data length of the patch file within the preset patch storage area; The first checksum is sent to the host so that the host can match the first checksum with the second checksum; the second checksum is a checksum calculated by the host based on the starting address and data length of the patch file in the host. If the first check value and the second check value match, a successful check result is generated; if the first check value and the second check value do not match, a failed check result is generated.

9. The method for updating embedded system firmware according to claim 1, characterized in that, Before receiving a hot patch command from the host and storing the patch file carried by the hot patch command in a preset patch storage area, the method further includes: Configure the access permissions of a specified physical memory page in the corresponding physical memory of the embedded system to read-only or non-executable, and determine the specified physical memory page with the configured permissions as the preset patch storage area; or Configure the access permissions of the preset virtual address space in the embedded system to read-only or non-executable, and determine the preset virtual address space with the configured permissions as the preset patch storage area.

10. A firmware update system, characterized in that, include: The memory includes a read-only memory area and a random access memory area; the read-only memory area is used to store the target firmware of the embedded system. The random access storage area includes a preset patch storage area, which is used to store patch files; the patch files are used to update the target firmware. A processor configured to implement, according to the patch file, the method for updating the embedded system firmware as described in any one of claims 1 to 9.

Images