Firmware version configuration loading method and device, storage medium and product

Abstract

The embodiment of the invention relates to a firmware version configuration loading method and device, a storage medium and a product. The method comprises the steps of obtaining a firmware version configuration template corresponding to a target firmware version, and filling immutable fields in the firmware version configuration template based on fixed parameters corresponding to the target firmware version; obtaining a firmware package associated with the target firmware version, wherein the firmware package carries variable field content of the target firmware; and filling a variable field in the firmware version configuration template based on a firmware package associated with the target firmware version to load firmware configuration of the target firmware version, and generating a firmware upgrade package.

Description

Technical Field

[0001] This disclosure relates to the field of OTA upgrade management technology, and in particular to a method, device, storage medium, and product for loading firmware version configuration. Background Technology

[0002] Traditional OTA upgrade management solutions may involve multiple firmware files with the same version number, lacking an effective historical tracking mechanism and making it difficult to clearly trace the firmware update process and compare firmware package content differences. In the upgrade package verification and generation stages, file integrity needs to be re-verified each time, and the verification rules are singular, making automated generation impossible and further increasing the complexity of upgrade package creation. Furthermore, the strong coupling between firmware files and version numbers in storage means that the original version and old upgrade packages must be deleted and rebuilt during firmware updates, failing to achieve automatic association between firmware and version. The same firmware has a high duplication rate across different version management systems, and regenerating upgrade packages is time-consuming, severely impacting the flexibility and efficiency of firmware version management. Summary of the Invention

[0003] To address the aforementioned issues, this disclosure provides a method, device, storage medium, and product for loading firmware version configuration.

[0004] According to a first aspect of the present disclosure, a method for loading firmware version configuration is provided, the method comprising: Obtain the firmware version configuration template corresponding to the target firmware version. The firmware version configuration template carries immutable fields corresponding to fixed parameters and variable fields corresponding to variable parameters. The immutable fields in the firmware version configuration template are filled with fixed parameters corresponding to the target firmware version. Obtain the firmware package associated with the target firmware version, wherein the firmware package carries the variable field content of the target firmware; Based on the firmware package associated with the target firmware version, the variable fields in the firmware version configuration template are filled to load the firmware configuration of the target firmware version and generate a firmware upgrade package.

[0005] In one implementation, before obtaining the firmware version configuration template corresponding to the target firmware version, the method further includes: The rules engine extracts historical firmware version metadata to generate immutable and variable fields in the firmware version configuration template. The immutable fields include at least the version number and device type, and the variable fields include at least the firmware fingerprint and upgrade policy.

[0006] In one implementation, before obtaining the firmware version configuration template corresponding to the target firmware version, the method further includes: adding a digital signature to the template to prevent tampering.

[0007] In one implementation, before obtaining the firmware package associated with the target firmware version, the method further includes: Use the firmware's SHA-256 hash value as the firmware fingerprint; A firmware storage path is constructed based on the hash value, and the target firmware is stored based on the firmware storage path. The version number of the target firmware is then associated with the firmware fingerprint. If firmware already exists in the firmware storage path, the storage operation is skipped, and the version number of the existing firmware is associated with the firmware fingerprint.

[0008] In one implementation, associating the version number of the target firmware with the firmware fingerprint includes: Maintain a version fingerprint mapping table, which records the list of firmware fingerprints associated with each firmware version and the fingerprint association timeline; Mark the latest state for each firmware fingerprint, wherein the latest state is automatically updated when the firmware fingerprint is uploaded; Add semantic tags or aliases to each firmware fingerprint.

[0009] In one implementation, the firmware package associated with the target firmware version fills variable fields in the firmware version configuration template to load the firmware configuration of the target firmware version and generate a firmware upgrade package, including: The template is reused to generate a configuration copy, and the variable fields of the configuration copy are updated based on the latest firmware fingerprint associated with the target firmware version in the firmware package; After verifying version consistency, the version configuration is submitted. Based on the firmware corresponding to the latest firmware fingerprint in the version configuration and the upgrade strategy in the variable field, the device compatibility is verified and a firmware upgrade package is generated.

[0010] In one implementation, updating the variable fields of the configuration copy based on the latest firmware fingerprint associated with the target firmware version in the firmware package includes: Locate the latest firmware fingerprint based on the latest marker field in the fingerprint association timeline; If multiple latest firmware fingerprints exist, select the firmware fingerprint with the earliest firmware upload timestamp as the latest firmware fingerprint; The variable fields of the configuration copy are updated based on the latest firmware fingerprint.

[0011] According to a second aspect of the present disclosure, a firmware version configuration loading device is provided, the device comprising: The first acquisition module is used to acquire the firmware version configuration template corresponding to the target firmware version. The firmware version configuration template carries immutable fields corresponding to fixed parameters and variable fields corresponding to variable parameters. The filling module is used to fill the immutable fields in the firmware version configuration template based on the fixed parameters corresponding to the target firmware version; The second acquisition module is used to acquire the firmware package associated with the target firmware version, wherein the firmware package carries the variable field content of the target firmware. The loading module is used to fill the variable fields in the firmware version configuration template based on the firmware package associated with the target firmware version to load the firmware configuration of the target firmware version and generate a firmware upgrade package.

[0012] According to a third aspect of the present disclosure, an electronic device is provided, comprising: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method of any one of the first aspects.

[0013] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0014] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0015] The embodiments disclosed herein achieve the following beneficial effects: Obtaining a firmware version configuration template corresponding to the target firmware version; filling the immutable fields in the firmware version configuration template with fixed parameters corresponding to the target firmware version; obtaining a firmware package associated with the target firmware version, the firmware package carrying variable fields of the target firmware; filling the variable fields in the firmware version configuration template with the firmware package associated with the target firmware version to load the firmware configuration of the target firmware version, and generating a firmware upgrade package. The embodiments disclosed herein can solve the technical problems existing in the current firmware version configuration loading process, such as cumbersome configuration, numerous repetitive operations, low efficiency, difficulty in version traceability, high risk of upgrade package generation, and inflexible association between firmware and version. They enable the reuse of firmware version configurations, dynamic firmware updates, and intelligent generation of upgrade packages, improving the efficiency and reliability of firmware version management.

[0016] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings: Figure 1 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0018] Figure 2 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0019] Figure 3 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0020] Figure 4 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0021] Figure 5 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0022] Figure 6 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0023] Figure 7 This is a flowchart of a firmware version configuration loading method provided in one embodiment of the present disclosure.

[0024] Figure 8 This is a block diagram of a firmware version configuration loading device provided in one embodiment of the present disclosure.

[0025] Figure 9 This is a block diagram of an electronic device provided in one embodiment of the present disclosure. Detailed Implementation

[0026] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0027] It should be understood that the term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description.

[0028] It should be noted that the concepts of "first," "second," etc., mentioned in this disclosure are used only to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies. The modifiers "a" and "a plurality of" mentioned in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless explicitly stated in the context, they should be understood as "one or more." In the description of this disclosure, unless otherwise stated, "a plurality of" means two or more, and other quantifiers are similar; "at least one," "one or more," or similar expressions refer to any combination of these items, including any combination of single or multiple items.

[0029] Although operations or steps are described in a specific order in the accompanying drawings in the embodiments of this disclosure, it should not be construed as requiring these operations or steps to be performed in the specific order or serial order shown, or requiring all of the shown operations or steps to be performed to obtain the desired result. In the embodiments of this disclosure, these operations or steps may be performed serially; they may be performed in parallel; or a portion of these operations or steps may be performed.

[0030] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of these messages or information. It is understood that before using the technical solutions disclosed in the embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0031] Figure 1 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 1 As shown in the figure, this disclosure provides a method for loading firmware version configuration, the method may include the following steps: In step S10, a firmware version configuration template corresponding to the target firmware version is obtained. The firmware version configuration template carries immutable fields corresponding to fixed parameters and variable fields corresponding to variable parameters.

[0032] Existing solutions typically use a method where version table fields are bound one-to-one with firmware files. Changes to firmware content require the creation of a new version ID, resulting in the coupling of version metadata with firmware content. This makes it difficult to achieve flexible management for multiple firmware scenarios with the same version, and also increases the complexity of version compatibility logic on the device side and redundant database storage.

[0033] To address this issue, the version table structure design in this embodiment decouples the template and firmware fingerprint, removes the firmware file path field, and associates the firmware fingerprint with the version ID, forming a many-to-many mapping data structure between fingerprint and version. A firmware version configuration template corresponding to the target firmware version is obtained. This template carries immutable fields corresponding to fixed parameters and variable fields corresponding to variable parameters. The immutable fields may include the version number and device type, while the variable fields may include the firmware fingerprint and upgrade strategy.

[0034] In step S20, the immutable fields in the firmware version configuration template are filled with fixed parameters corresponding to the target firmware version.

[0035] For example, fixed parameters corresponding to the target firmware version, such as version number and device type, can be filled into the immutable fields in the firmware version configuration template.

[0036] In step S30, the firmware package associated with the target firmware version is obtained, and the firmware package carries the variable field content of the target firmware.

[0037] For example, the firmware package associated with the target firmware version may include the firmware corresponding to the target firmware version, firmware fingerprint, and upgrade policy information, wherein the upgrade policy may include incremental upgrade or full upgrade, and the target firmware version and the associated firmware package are associated with the same device type.

[0038] In step S40, the variable fields in the firmware version configuration template are filled with the firmware package associated with the target firmware version to load the firmware configuration of the target firmware version and generate a firmware upgrade package.

[0039] For example, a configuration copy can be generated by reusing the template first, and the variable fields of the configuration copy can be updated based on the latest firmware fingerprint associated with the target firmware version in the firmware package. After verifying the version consistency, the version configuration can be submitted, and the firmware upgrade package can be generated after verifying device compatibility based on the firmware corresponding to the latest firmware fingerprint in the version configuration and the upgrade strategy in the variable fields.

[0040] This process can solve the technical problems existing in the current firmware version configuration loading process, such as cumbersome configuration, repetitive operations, low efficiency, difficulty in version tracing, high risk of upgrade package generation, and inflexible association between firmware and version. It enables the reuse of firmware version configuration, dynamic firmware updates, and intelligent generation of upgrade packages, thereby improving the efficiency and reliability of firmware version management.

[0041] Figure 2 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 2As shown, before obtaining the firmware version configuration template corresponding to the target firmware version, the method may further include the following steps: In step S01, historical firmware version metadata is extracted through the rule engine to generate immutable and variable fields in the firmware version configuration template. The immutable fields include at least the version number and device type, and the variable fields include at least the firmware fingerprint and upgrade policy.

[0042] For example, in traditional solutions, fixed parameters for firmware version configuration (such as device type, basic verification rules, etc.) need to be manually entered repeatedly. The lack of an automated extraction and solidification mechanism makes it impossible to guarantee parameter consistency (such as spelling errors in parameters in different versions), which can easily lead to configuration errors and time-consuming version configuration.

[0043] In this embodiment, when a firmware version is created for the first time, the system uses Drools rule engine technology to automatically extract key metadata of historical firmware versions based on custom preset association rules written according to actual needs, generating an immutable template in JSON format. The template specifies immutable fields (such as version number and device type) through specific key values ​​to ensure semantic consistency of the version. When a new version creation request is subsequently received and the template is reused, the variable fields are filled with the latest firmware fingerprint by default (such as associated firmware fingerprints and upgrade strategies, which are automatically retrieved and filled via API). Manual selection of historical fingerprints is also supported. This design reduces configuration error rates and improves parameter reuse efficiency. The main fields of the template configuration table are shown in Table 1.

[0044] Table 1:

[0045] The configuration template is solidified through a process that involves reusing version requests, retrieving version templates, loading solidified metadata, enabling editing of variable fields, verifying version consistency, and generating a configuration copy. For example, when developers or testers need to make new configurations, they can enter keywords such as device type and version function into the OTA upgrade platform user interface. The system will automatically search the version configuration information database to find matching version configuration information. If the search is successful, the operator can choose to reuse the configuration information, copy it to the current upgrade version configuration, and modify and adjust some configuration parameters in the platform's editing interface according to actual needs, such as changing the version number or adjusting the upgrade file list.

[0046] Figure 3 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 3 As shown, before obtaining the firmware version configuration template corresponding to the target firmware version, the method may further include the following steps: In step S02, a digital signature is added to the template to prevent tampering.

[0047] For example, before obtaining the firmware version configuration template corresponding to the target firmware version, a digital signature is added to the generated firmware version configuration template. The encryption protection provided by the digital signature effectively prevents the template from being illegally tampered with, ensuring the integrity and security of the fixed parameters and field divisions within the template. This provides a reliable template foundation for subsequent firmware version configuration loading, avoiding configuration errors and upgrade risks caused by template tampering.

[0048] Figure 4 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 4 As shown, before obtaining the firmware package associated with the target firmware version, the method may further include the following steps: In step S21, the SHA-256 hash value of the firmware is used as the firmware fingerprint.

[0049] For example, the firmware fingerprint mapping table uses the SHA-256 algorithm to generate a 64-bit firmware fingerprint to ensure file uniqueness verification; it also supports associating multiple firmware fingerprints with the same version ID, which are stored through a nested array structure in MongoDB. Each fingerprint corresponds to a unique firmware hash value and records the firmware upload time to form a version-firmware timeline.

[0050] In step S22, a firmware storage path is constructed based on the hash value, and the target firmware is stored based on the firmware storage path. The version number of the target firmware is then associated with the firmware fingerprint.

[0051] For example, when storing firmware content, a storage path is constructed based on the fingerprint hash value. For instance, the first two characters 's1' and the third to fourth characters 's2' of the hash string are extracted as the path, and the complete hash value is used as the filename: / file / s1 / s2 / {hash}.bin. This achieves content-addressable storage. The storage is determined based on the hash value and file size, ensuring that the same firmware is stored only once. File size is used as an auxiliary factor; filtering is done first by file size, and then hash comparison is performed. This design helps reduce the number of version numbers stored during version management and lowers the complexity of compatibility logic on the device side.

[0052] In step S23, if firmware already exists in the firmware storage path, the storage operation is skipped, and the version number of the existing firmware is associated with the firmware fingerprint.

[0053] This allows the same firmware to be stored only once, reducing redundant storage.

[0054] This approach decouples firmware from version numbers, ensuring that the same firmware is stored only once, reducing storage redundancy. At the same time, it uses hash values ​​to ensure accurate correspondence between version and firmware, improving storage and association efficiency.

[0055] Figure 5 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 5 As shown, associating the version number of the target firmware with the firmware fingerprint may include the following steps: In step S221, a version fingerprint mapping table is maintained, which records the firmware fingerprint list associated with each firmware version and the fingerprint association timeline.

[0056] In traditional solutions, firmware files are stored in a bound manner with their version numbers. When updating firmware, the version and old upgrade packages must be deleted and rebuilt, making it impossible to automatically associate firmware versions. This results in a high rate of duplication when managing different versions of the same firmware, making it prone to errors, and also taking longer to regenerate upgrade packages.

[0057] To address these issues, this embodiment of the disclosure implements dynamic firmware management by maintaining a version fingerprint mapping table. This is achieved through several steps: uploading new firmware, calculating the SHA-256 hash value, storing the hash value based on its existence, associating it with the target version, updating the latest fingerprint marker, and recording the version-fingerprint relationship. Asynchronous fingerprint calculation is implemented using a Kafka message queue. When uploading firmware, if the selected firmware is determined to be a duplicate of a historical version or a newer version is available, the system provides relevant prompts to facilitate user operation. When associating versions and fingerprints, a two-layer verification mechanism using hash value and file size is employed to handle hash collisions. Furthermore, each version is maintained as a fingerprint list sorted by time. Automatic association between versions and firmware fingerprints is achieved through steps such as checking for duplicate hash values, updating the latest fingerprint, and recording association history.

[0058] In step S222, the latest status is marked for each firmware fingerprint, wherein the latest status is automatically updated when the firmware fingerprint is uploaded.

[0059] For example, in order to confirm whether the firmware fingerprint is the latest when the template is reused, and to ensure the accuracy and logical consistency of the filled content, this embodiment of the disclosure determines the latest firmware based on the timeline of the firmware fingerprint. During the dynamic maintenance of the version fingerprint mapping table, the firmware fingerprint list associated with each version includes key fields such as firmware upload time and whether it is the latest fingerprint (marked as 1 if it is the latest, and 0 if it is a historical fingerprint). When a new firmware is uploaded, the system automatically marks the old latest fingerprint as a historical fingerprint and the new fingerprint as the latest fingerprint.

[0060] In step S223, a semantic tag or alias is added to each firmware fingerprint.

[0061] For example, semantic tags or aliases (such as "beta" or "security patch") can be added to firmware fingerprints.

[0062] The above process facilitates the tracing of firmware update history and enables quick location of the latest firmware. Semantic tags make firmware management more flexible and meet the firmware management needs of different scenarios.

[0063] Figure 6 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 6 As shown, the process of filling variable fields in the firmware version configuration template with the firmware package associated with the target firmware version to load the firmware configuration of the target firmware version and generate a firmware upgrade package may include the following steps: In step S401, the template is reused to generate a configuration copy, and the variable fields of the configuration copy are updated based on the latest firmware fingerprint associated with the target firmware version in the firmware package.

[0064] For example, a one-click firmware association method can be used, which supports fuzzy search (such as entering the version number or device model) on the version search interface. Clicking the version card will take you to the firmware update page. When uploading new firmware, the version metadata (version number, device type, etc.) will be automatically filled in, without the need to fill it in repeatedly.

[0065] The default value filling design is adopted. The "Reuse existing version configuration" option is selected by default on the firmware update page. Fields such as version number are automatically read from the historical template and displayed in a grayed-out, uneditable state. The firmware description field is automatically generated with default values, such as generated according to the "version number-firmware package type-timestamp" rule command. The firmware fingerprint of the variable field of the updated configuration copy is updated.

[0066] It supports historical operation rollback and batch operations, and provides a "historical operation" list to display the most recent N firmware update records. Clicking on the history record allows you to reuse the same version configuration with one click, which can be used only to modify firmware files. When multiple similar versions are selected, batch operations are supported, which can uniformly update the firmware fingerprint of variable fields.

[0067] In traditional implementations, users need to complete several steps in the version management interface, including clicking "Create New Version," entering the version number, selecting the device type, configuring the upgrade strategy, uploading the new firmware file, waiting for file verification to complete, filling in description information, and generating the upgrade package. If a failure occurs, the process must be restarted. In this process, version and firmware management are tightly coupled, a single relational database is used for storage, and firmware comparison requires manual selection of a baseline version. In this embodiment, version metadata can be automatically reused when uploading new firmware, and the latest fingerprint is used by default when generating the upgrade package. A decoupled design for version and firmware is adopted, and the data storage structure is optimized during implementation. Firmware comparison is performed by automatically selecting the latest fingerprint for association and calculation.

[0068] In step S402, after verifying version consistency, the version configuration is submitted, and based on the firmware corresponding to the latest firmware fingerprint in the version configuration and the upgrade strategy in the variable field, the device compatibility is verified and a firmware upgrade package is generated.

[0069] Traditional solutions primarily verify firmware integrity through file size or simple MD5 hash values. This verification mechanism is relatively simple and requires multiple verifications, which can easily lead to risks such as upgrade failures. In this embodiment, firmware fingerprinting is used to complete the consistency verification and upgrade package generation and update process. Device compatibility verification is added to compensate for the shortcomings of traditional solutions, verifying the compatibility between the firmware and the device model and system version. Specifically, a device fingerprint database can be built using the device IMEI. During verification, custom functions or rules from the rule engine are called for comparison to filter matching devices. When generating the upgrade package, the compatibility between the version template and the firmware is checked. For differential packages or full packages from fingerprint 1 to fingerprint 3, upgrade packages for different iteration stages can be generated based on the fingerprint list, automatically associating with device compatibility verification rules, without needing to repeatedly create version records. Furthermore, the upgrade package filename automatically includes firmware fingerprint information, making it easy to intuitively identify the content source. Additionally, if the user uses a mode where the upgrade strategy is configured when generating the upgrade package, this embodiment can also reduce redundant configuration by reusing upgrade strategies from previous versions (such as upgrade time configuration).

[0070] This process simplifies the upgrade package creation process, ensures accurate configuration and device compatibility through dual verification, reduces compatibility risks during firmware upgrades, and improves the reliability of firmware upgrades.

[0071] Figure 7 This is a flowchart illustrating a firmware version configuration loading method according to an embodiment of this disclosure. Figure 7 As shown, updating the variable fields of the configuration copy based on the latest firmware fingerprint associated with the target firmware version in the firmware package may include the following steps: In step S4011, the latest firmware fingerprint is located based on the latest marker field in the fingerprint association timeline.

[0072] In this step, for example, when performing a retrieval using the default fill function, the system can be designed to prioritize quickly locating the latest firmware fingerprint by using the latest firmware fingerprint flag field. In addition, all firmware fingerprints of the same version can be arranged in ascending order by firmware upload time, thereby forming a timeline and improving the traceability of historical firmware fingerprints.

[0073] In step S4012, if there are multiple newly marked firmware fingerprints, the firmware fingerprint with the earliest firmware upload timestamp is selected as the latest firmware fingerprint.

[0074] In this step, for example, if there is a special case where there are multiple latest markers, the firmware fingerprint closest to the current time can be selected as the latest firmware fingerprint based on the upload timestamp.

[0075] In step S4013, the variable fields of the configuration copy are updated based on the latest firmware fingerprint.

[0076] In this step, the variable fields of the latest firmware fingerprint update configuration copy determined based on the above method steps are used.

[0077] This method ensures that the variable fields are filled with the most valid firmware-related content, avoiding configuration logic confusion caused by incorrect firmware fingerprint selection, and guaranteeing the accuracy and consistency of firmware version configuration.

[0078] In practical use, when updating firmware upgrade packages, additional logical checks are typically added to firmware already used for upgrade package creation to ensure the accuracy of subsequent upgrades. This makes updating firmware upgrade packages more cumbersome than adding new firmware in existing solutions. For example, if a firmware package is determined to have already been used for upgrade package creation, the existing upgrade package must be deleted before an update can be performed. In this embodiment, if an upgrade package already exists, it can still reference the old fingerprint when the firmware is updated. Simultaneously, a new upgrade package references the new fingerprint. By adding a version record to the database, it is automatically associated with all generated upgrade packages, eliminating the need to delete existing upgrade packages. This optimizes the firmware version association process in this scenario, improving the standardization of firmware version management and configuration loading efficiency.

[0079] Figure 8 This is a block diagram of a firmware version configuration loading device provided in one embodiment of this disclosure. Figure 8 As shown, this embodiment of the disclosure provides a firmware version configuration loading device 800, which may include the following modules: The first acquisition module 810 is used to acquire the firmware version configuration template corresponding to the target firmware version. The firmware version configuration template carries immutable fields corresponding to fixed parameters and variable fields corresponding to variable parameters.

[0080] The filling module 820 is used to fill the immutable fields in the firmware version configuration template based on the fixed parameters corresponding to the target firmware version.

[0081] The second acquisition module 830 is used to acquire the firmware package associated with the target firmware version, wherein the firmware package carries the variable field content of the target firmware.

[0082] The loading module 840 is used to fill the variable fields in the firmware version configuration template based on the firmware package associated with the target firmware version to load the firmware configuration of the target firmware version and generate a firmware upgrade package.

[0083] In one possible implementation, the device 800 further includes an extraction module for: Before obtaining the firmware version configuration template corresponding to the target firmware version, historical firmware version metadata is extracted through the rule engine to generate immutable and variable fields in the firmware version configuration template. The immutable fields include at least the version number and device type, and the variable fields include at least the firmware fingerprint and upgrade policy.

[0084] In one possible implementation, the device 800 further includes a signature module for: Before obtaining the firmware version configuration template corresponding to the target firmware version, a digital signature is added to the template to prevent tampering.

[0085] In one possible implementation, the device 800 further includes an association module for: Before obtaining the firmware package associated with the target firmware version, the SHA-256 hash value of the firmware is used as the firmware fingerprint. A firmware storage path is constructed based on the hash value, and the target firmware is stored based on the firmware storage path. The version number of the target firmware is then associated with the firmware fingerprint. If firmware already exists in the firmware storage path, the storage operation is skipped, and the version number of the existing firmware is associated with the firmware fingerprint.

[0086] In one possible implementation, the association module is further configured to: Maintain a version fingerprint mapping table, which records the list of firmware fingerprints associated with each firmware version and the fingerprint association timeline; Mark the latest state for each firmware fingerprint, wherein the latest state is automatically updated when the firmware fingerprint is uploaded; Add semantic tags or aliases to each firmware fingerprint.

[0087] In one possible implementation, the loading module 840 is further configured to: The template is reused to generate a configuration copy, and the variable fields of the configuration copy are updated based on the latest firmware fingerprint associated with the target firmware version in the firmware package; After verifying version consistency, the version configuration is submitted. Based on the firmware corresponding to the latest firmware fingerprint in the version configuration and the upgrade strategy in the variable field, the device compatibility is verified and a firmware upgrade package is generated.

[0088] In one possible implementation, the loading module 840 is further configured to: Locate the latest firmware fingerprint based on the latest marker field in the fingerprint association timeline; If multiple latest firmware fingerprints exist, select the firmware fingerprint with the earliest firmware upload timestamp as the latest firmware fingerprint; The variable fields of the configuration copy are updated based on the latest firmware fingerprint.

[0089] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0090] In summary, the first acquisition module retrieves the configuration template corresponding to the target firmware version, which contains both immutable and variable fields. The filling module calls the fixed parameters of the target firmware version to fill in the immutable fields in the template. The second acquisition module retrieves the firmware package associated with the target firmware version and extracts the variable field content. The loading module fills these variable field contents into the template, completing the loading of the target firmware version configuration and generating the firmware upgrade package. These modules work collaboratively to automate the firmware version configuration loading process, reducing manual intervention and improving configuration loading efficiency and the standardization of upgrade package generation.

[0091] Figure 9 This is a block diagram of an electronic device provided in one embodiment of this disclosure. For example... Figure 9 As shown, the electronic device 900 may include a processor 901 and a memory 902. The electronic device 900 may also include one or more of a multimedia component 903, an input / output (I / O) interface 904, and a communication component 905.

[0092] The processor 901 controls the overall operation of the electronic device 900 to complete all or part of the steps in the firmware version configuration loading method described above. The memory 902 stores various types of data to support the operation of the electronic device 900. This data may include, for example, instructions for any application or method operating on the electronic device 900, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 902 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 903 may include a screen and audio components. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 902 or transmitted via communication component 905. The audio component also includes at least one speaker for outputting audio signals. I / O interface 904 provides an interface between processor 901 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 905 is used for wired or wireless communication between the electronic device 900 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 905 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0093] In an exemplary embodiment, the electronic device 900 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the firmware version configuration loading method described above.

[0094] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the firmware version configuration loading method described above. For example, the computer-readable storage medium may be the memory 902 including the program instructions described above, which may be executed by the processor 901 of the electronic device 900 to complete the firmware version configuration loading method described above.

[0095] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for executing the loading method of the firmware version configuration described above when executed by the programmable device.

[0096] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0097] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0098] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A method for loading firmware version configuration, characterized in that, The method includes: Obtain the firmware version configuration template corresponding to the target firmware version. The firmware version configuration template carries immutable fields corresponding to fixed parameters and variable fields corresponding to variable parameters. The immutable fields in the firmware version configuration template are filled with fixed parameters corresponding to the target firmware version. Obtain the firmware package associated with the target firmware version, wherein the firmware package carries the variable field content of the target firmware; Based on the firmware package associated with the target firmware version, the variable fields in the firmware version configuration template are filled to load the firmware configuration of the target firmware version and generate a firmware upgrade package.

2. The method according to claim 1, characterized in that, Before obtaining the firmware version configuration template corresponding to the target firmware version, the method further includes: The rules engine extracts historical firmware version metadata to generate immutable and variable fields in the firmware version configuration template. The immutable fields include at least the version number and device type, and the variable fields include at least the firmware fingerprint and upgrade policy.

3. The method according to claim 1, characterized in that, Before obtaining the firmware version configuration template corresponding to the target firmware version, the method further includes: adding a digital signature to the template to prevent tampering.

4. The method according to claim 1, characterized in that, Before obtaining the firmware package associated with the target firmware version, the method further includes: Use the firmware's SHA-256 hash value as the firmware fingerprint; A firmware storage path is constructed based on the hash value, and the target firmware is stored based on the firmware storage path. The version number of the target firmware is then associated with the firmware fingerprint. If firmware already exists in the firmware storage path, the storage operation is skipped, and the version number of the existing firmware is associated with the firmware fingerprint.

5. The method according to claim 4, characterized in that, Associating the version number of the target firmware with the firmware fingerprint includes: Maintain a version fingerprint mapping table, which records the list of firmware fingerprints associated with each firmware version and the fingerprint association timeline; Mark the latest state for each firmware fingerprint, wherein the latest state is automatically updated when the firmware fingerprint is uploaded; Add semantic tags or aliases to each firmware fingerprint.

6. The method according to claim 1, characterized in that, The firmware package associated with the target firmware version fills the variable fields in the firmware version configuration template to load the firmware configuration of the target firmware version, generating a firmware upgrade package, including: The template is reused to generate a configuration copy, and the variable fields of the configuration copy are updated based on the latest firmware fingerprint associated with the target firmware version in the firmware package; After verifying version consistency, the version configuration is submitted. Based on the firmware corresponding to the latest firmware fingerprint in the version configuration and the upgrade strategy in the variable field, the device compatibility is verified and a firmware upgrade package is generated.

7. The method according to claim 6, characterized in that, The variable fields of the configuration copy updated based on the latest firmware fingerprint associated with the target firmware version in the firmware package include: Locate the latest firmware fingerprint based on the latest marker field in the fingerprint association timeline; If multiple latest firmware fingerprints exist, select the firmware fingerprint with the earliest firmware upload timestamp as the latest firmware fingerprint; The variable fields of the configuration copy are updated based on the latest firmware fingerprint.

8. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1-7.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

Images