Mirror image firmware version compatibility detection method

Abstract

The application relates to the technical field of embedded system firmware management, and discloses a mirror firmware version compatibility detection method, which comprises the following steps: determining a first version of a first firmware mirror as an interface invoker and a second version of a second firmware mirror as an interface provider; obtaining a public interface warehouse submission identifier referenced by the interface invoker and the interface provider, and marking the identifiers as a first submission identifier and a second submission identifier respectively; obtaining an interface name set called by the interface invoker; in an interface evolution database, defining a submission time sequence interval by the first submission identifier and the second submission identifier, and querying change records of each interface in the interface name set within the time sequence interval; if there is a non-compatibility change mark, it is determined that the versions are incompatible, otherwise, it is determined that the versions are compatible. The application realizes automatic detection of cross-mirror compatibility based on actual change states of interfaces, and eliminates unreliability caused by manual maintenance of version dependency information.

Description

Technical Field

[0001] This application relates to the field of embedded system firmware management technology, and in particular to a method for detecting image firmware version compatibility. Background Technology

[0002] In a multi-image boot system of a system-on-a-chip (SoC), there are typically multiple firmware images, such as a primary bootloader (BL1), a secondary bootloader (BL2), a secure runtime firmware (BL31), a trusted execution environment (TEA) operating system (BL32), a generic bootloader (BL33), and a kernel image. These firmware images interact with each other through common interfaces; for example, one firmware image may call functions or data structures provided by another firmware image. To ensure that the system can function correctly after booting, the versions of the common interfaces referenced by different firmware images must be compatible with each other.

[0003] In existing technologies, interface compatibility testing between firmware images is usually implemented in the following way: the developer manually declares the version number or interface version range of other firmware images that it depends on in the configuration file or code of the firmware image. When the system is built or deployed, it compares the version number of each firmware image in the current system with the above manually declared dependency information. If the version number meets the dependency constraints, it is determined to be compatible; otherwise, it is determined to be incompatible.

[0004] The aforementioned prior art has the following technical problems:

[0005] First, the accuracy and completeness of dependency information rely on the developer's subjective judgment and manual maintenance. In scenarios involving multiple mirrors and multiple teams developing in parallel, developers may overlook updating dependency declarations or incorrectly enter version numbers, leading to inconsistencies between the declared dependencies and the actual interface definitions referenced in the code. When public interfaces change, the updates to dependency declarations lag behind the actual code modifications, rendering version comparison results unreliable.

[0006] Second, existing compatibility assessments are based on exact matching or range comparison of version number strings. The underlying logic is that "if the version numbers are the same or meet the range constraints, they are compatible; if the version numbers are different, they are incompatible." However, different version numbers of common interfaces referenced by two firmware images do not necessarily mean incompatibility. Different version numbers may be due to one version lagging behind the other, but as long as the interface definition between the lagging and leading versions has not undergone substantial changes (e.g., function signatures remain unchanged, data structures are not adjusted), the calling image can still call the provider image's interface normally without modifying its code. Existing version number comparison methods directly equate "different version numbers" with "incompatible interfaces," failing to distinguish between "different versions but semantically compatible interfaces" and "different versions and semantically incompatible interfaces." This leads to many firmware image combinations that could work together normally being incorrectly judged as incompatible.

[0007] In summary, existing technologies rely on manually maintained version dependency information and compare version number strings to determine compatibility. They cannot automatically detect cross-image interface semantic compatibility based on the actual evolution state of the interface, and the dependency declarations are disconnected from the actual code state, resulting in unreliable compatibility judgment results. Summary of the Invention

[0008] To address the aforementioned technical problems, the technical solution adopted in this application is as follows:

[0009] In a first aspect, one embodiment of this application provides a method for detecting image firmware version compatibility, including:

[0010] Step S201: Determine the first version of the first firmware image as the interface caller, and determine the second version of the second firmware image as the interface provider;

[0011] Step S202: Obtain the commit identifier corresponding to the public interface repository referenced by the interface caller, denoted as the first commit identifier; obtain the commit identifier corresponding to the public interface repository referenced by the interface provider, denoted as the second commit identifier; wherein, the public interface repository includes interface definitions used for interaction between all firmware images, the public interface repository generates a commit identifier each time the code is changed, and there is a temporal relationship between the commit identifiers based on the order of code changes;

[0012] Step S203: Obtain the set of interface names of all interfaces belonging to the public interface repository that are called by the interface caller;

[0013] Step S204: In the interface evolution database, the first submission identifier and the second submission identifier define the submission time interval, and query all change records corresponding to each interface in the interface name set within the submission time interval; wherein, the interface evolution database is used to record the historical change records of each interface in the public interface repository, and each change record includes the interface name, the submission identifier when the change record was generated, and a flag field used to indicate whether it is an incompatible change;

[0014] Step S205: If there is a target change record in the queried change record that is indicated by the tag field as an incompatible change, then the interface corresponding to the target change record is determined as the target interface where the incompatible change has occurred, and the interface caller is determined to be incompatible with the interface provider; otherwise, the interface caller is determined to be compatible with the interface provider.

[0015] Secondly, one embodiment of this application provides a method for detecting image firmware version compatibility, including:

[0016] Step S301: Obtain the target firmware set, which includes all firmware images to be run during the device startup phase, or a combination of whole-device firmware images formed after simulating OTA upgrade.

[0017] Step S302: Pair the versions of each firmware image in the target firmware set to obtain at least one pairing combination;

[0018] Step S303: For any pairing combination, using the version of the first firmware image in the pairing combination as the interface caller and the version of the second firmware image in the pairing combination as the interface provider, execute the method described in the first aspect to obtain a first compatibility detection result; using the version of the second firmware image as the interface caller and the version of the first firmware image as the interface provider, execute the method described in the first aspect to obtain a second compatibility detection result; if both the first compatibility detection result and the second compatibility detection result are compatible, then the pairing combination is determined to be compatible; otherwise, the pairing combination is determined to be incompatible.

[0019] Step S304: If all paired combinations are compatible, then the target firmware set is determined to be compatible; otherwise, the target firmware set is determined to be incompatible.

[0020] Thirdly, one embodiment of this application provides a firmware image version number verification method, including:

[0021] Obtain a first version and a second version of the target firmware image, wherein the second version is a version of the target firmware image prior to the first version;

[0022] Obtain the commit identifier corresponding to the public interface repository referenced by the first version, and denote it as the first commit identifier; obtain the commit identifier corresponding to the public interface repository referenced by the second version, and denote it as the second commit identifier; wherein, the public interface repository includes the interface definitions used for interaction between all firmware images, the public interface repository generates a commit identifier each time the code is changed, and there is a temporal relationship between the commit identifiers based on the order of code changes;

[0023] In the interface evolution database, the first submission identifier and the second submission identifier define the submission time interval, and query all change records of the interface of the target firmware image within the submission time interval; wherein, the interface evolution database is used to record the historical change records of each interface in the public interface repository; each change record includes the interface name, the submission identifier when the change record was generated, a flag field indicating whether it is an incompatible change, and the change operation type;

[0024] Based on the flag fields and change operation types in the retrieved change records, determine the version number upgrade requirements;

[0025] Obtain the version number corresponding to the first version and the version number corresponding to the second version;

[0026] If the version number of the first version is not upgraded according to the version number upgrade requirements relative to the version number of the second version, then the version number declaration of the first version of the target firmware image is determined to be incorrect.

[0027] Fourthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0028] The technical solution provided in this application has at least the following beneficial effects:

[0029] First, implement automatic compatibility detection based on the actual change status of the interface.

[0030] Existing technologies determine compatibility by comparing version numbers, but cannot distinguish between "different versions but compatible interfaces" and "different versions and incompatible interfaces." This application clarifies the direction of compatibility judgment by identifying the first version of the first firmware image as the interface caller and the second version of the second firmware image as the interface provider; it defines the dependency boundaries for compatibility judgment by obtaining the set of interface names called by the interface caller; and it defines the submission time interval by defining the submission identifiers referenced by the interface caller and the interface provider respectively. In the interface evolution database, it only queries the change records of each interface within the set of interface names within the time interval, and determines whether the interface caller and the interface provider are compatible based on the flag fields in the change records that indicate whether the change is incompatible. Therefore, when the public interface repository versions referenced by the two firmware image versions are different, it can accurately determine whether the interface depended on by the interface caller has undergone substantial incompatible changes between the two versions. If the interface depended on by the interface caller has not undergone incompatible changes between the two versions (even if the version numbers of the two versions are different), it is still considered compatible. The input for compatibility judgment has been changed from "manual declaration" to "objective fact deduction," and the granularity of compatibility judgment has been changed from "version number" to "whether there are incompatible changes to the interface." This avoids the misjudgment of existing technologies that directly equate "different version numbers" with "incompatible interfaces," enabling a large number of firmware image combinations with different version numbers but semantically compatible interfaces to be correctly identified as compatible, thereby improving the system's upgrade flexibility and firmware reuse efficiency.

[0031] Second, the granularity of compatibility judgment is accurate to the specific changes made to the interface within a particular version evolution range, avoiding misjudging changes to irrelevant interfaces as incompatibility.

[0032] This application defines the submission time interval using a first submission identifier and a second submission identifier, and queries the interface evolution database to find the specific change records of each interface in the interface name set within that interval. Since the determination is based on the specific change records in the interface evolution database that include the interface name and submission identifier, the granularity of the determination is accurate to the change facts of the interface within a specific version evolution interval, avoiding the misjudgment of changes to irrelevant interfaces as incompatibility.

[0033] Third, it supports gradual upgrades and does not force all firmware images to be upgraded to the same version simultaneously.

[0034] This application uses two commit identifiers to define the query range and does not require two firmware image versions to reference the same public interface repository commit identifier. As long as the interfaces that the caller depends on have not undergone incompatible changes within this time frame, even if the two versions reference different versions of the public interface repository, they are still considered compatible. Therefore, each firmware image can evolve independently according to its own development pace without being forced to synchronize and upgrade to the same version. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 A schematic diagram of the architecture of a mirror firmware version compatibility detection system provided in an embodiment of this application;

[0037] Figure 2 A flowchart illustrating a method for detecting image firmware version compatibility according to an embodiment of this application;

[0038] Figure 3 A flowchart illustrating an embodiment of this application provides a method for detecting image firmware version compatibility with an added fast pre-inspection process;

[0039] Figure 4 A flowchart illustrating a system compatibility verification method provided in an embodiment of this application;

[0040] Figure 5 A flowchart illustrating a whole-machine compatibility verification method with an added rapid pre-inspection process provided in an embodiment of this application;

[0041] Figure 6 This is a flowchart illustrating a firmware image version number verification method provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive effort. For steps that do not logically have a necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other.

[0043] like Figure 1 As shown, the image firmware version compatibility detection system provided in this embodiment includes the following modules:

[0044] (a) Data Preparation Layer

[0045] The public interface repository 101 is an independent version control repository (such as a Git repository) that centrally stores the interface definitions used for interaction between all firmware images, serving as the sole source of interface definitions for each firmware image.

[0046] Firmware image implementation repository 102: This is the source code repository for each firmware image, and each firmware image has its own independent implementation repository. Each firmware image implementation repository references a specific commit version of the public interface repository 101 through a version locking mechanism (such as Git submodule, subtree, or configuration file version pin). This locking record is stored in the version control history of the firmware image implementation repository and can be parsed and extracted.

[0047] Interface Evolution Database Construction Module 103: Connects to the public interface repository 101, traverses the commit history of the public interface repository 101, performs semantic difference analysis on the interface definitions before and after each commit, identifies the addition, deletion and modification of interfaces, and generates the interface evolution database 107. The pre-built interface evolution database 107 records the interface name of each interface, the commit identifier when the interface was changed, and a flag field used to indicate whether it is a non-compliance change.

[0048] Interface Role Database Construction Module 104: Connects to the implementation repository 102 of each firmware image, uses an abstract syntax tree parsing tool to perform semantic analysis on the source code of each version of each firmware image, extracts the set of interface names called by each version that belong to the public interface repository 101, and generates the interface role database 108.

[0049] Version lock mapping module 105: Connects to each firmware image implementation repository 102, parses the version control history of each firmware image implementation repository 102, extracts the public interface repository commit identifiers referenced by each version of each firmware image, and generates version lock mapping table 109.

[0050] Baseline whitelist building module 106: Connects to the public interface repository 101, extracts version snapshots corresponding to each historical commit from the commit history of the version definition file, and records a set of version number combinations of each firmware image to generate the baseline whitelist building module 110.

[0051] It should be noted that the historical version snapshots in the baseline whitelist 110 are not a simple set formed by comparing version number strings, but rather a combination that has been verified through interface semantic compatibility testing or has been verified in actual operation as a synchronous release baseline in the past.

[0052] (II) Core Detection Layer

[0053] Compatibility detection module 120: Connected to interface evolution database 107, interface role database 108 and version lock mapping table 109, it is used to execute image firmware version compatibility detection method to detect whether the interfaces between different firmware image versions are compatible.

[0054] In addition, before detection, the compatibility detection module 120 can also perform a quick pre-detection of the combination of version numbers of the interface caller and the interface provider by building a baseline whitelist 110.

[0055] (III) Application Extension Layer

[0056] Whole machine verification module 130: connected to compatibility detection module 120, used to obtain target firmware set, pair the versions of each firmware image in the target firmware set, and realize bidirectional compatibility detection for each pairing by calling compatibility detection module 120, and determine whether the interface of the target firmware set is compatible based on the detection results of all pairings.

[0057] Version number declaration verification module 140: Connects to the interface evolution database 107, used to obtain different versions of the target firmware image, and verify whether the version number declaration of the target firmware image is correct through the interface evolution database.

[0058] In this embodiment, a centralized public interface repository 101 is first established.

[0059] The public interface repository 101 contains only header files (.h files) and no implementation code (.c or .cpp files) to ensure that interface definitions are separated from implementations and to avoid introducing implementation dependencies into interface definitions.

[0060] Public interface repository 101 stores the following three types of content:

[0061] (1) Version definition file: This file centrally defines the version number macros for all firmware images within the system. It is updated uniformly with each release to ensure global consistency of version numbers. Each firmware image reads the corresponding version number macro from this file and writes it into the image header during the build process. The version number format is "V<major version number>.<minor version number>.<patch version number>.<build version number>", where the major version number is used to identify versions that include non-compatible interface changes, the minor version number is used to identify versions that include backward compatible interface additions, and the patch version number is used to identify versions that include bug fixes but do not involve interface changes.

[0062] (2) Common Interface Header Files: These define the application programming interfaces (APIs) for interaction between different firmware images, including function declarations, data structure definitions, macro definitions, etc. These header files are commonly referenced by the source code of each firmware image, forming a contract for cross-image interaction. Taking the OTA upgrade hardware abstraction layer interface as an example, its header file declares interfaces such as initialization functions, image burning functions, partition switching functions, and image verification functions, which are called by each firmware image. When any of the above interfaces changes (such as modification of function parameter types, change of return value types, deletion of interfaces, etc.), other firmware images that call the interface may need to adapt accordingly. Such changes constitute incompatibility changes.

[0063] (3) Chip register definition: Register address mapping and register bit field definition managed by chip version. Each firmware image accesses hardware resources through a unified register definition header file to ensure that different firmware images have consistent access definitions for the same hardware resources.

[0064] Version control features of public interface repository 101: Each code commit in public interface repository 101 generates a unique commit ID. A code commit refers to the operation of writing a change to the version control repository of public interface repository 101, and each code commit corresponds to a unique commit ID. Each code commit can include the addition, modification, or deletion of one or more interfaces. When changes to multiple interfaces are completed in a single commit, only one commit ID is generated. The commit ID is used to uniquely identify the interface definition status of the public interface repository at the time the commit is completed. There is a temporal sequence relationship between the commit IDs, which is determined by the commit chain of the version control system (i.e., the temporal sequence formed by connecting code commits according to parent-child relationships). By traversing this commit history, the complete lifecycle of each interface from introduction to deletion can be fully traced, providing a data foundation for the construction of the subsequent interface evolution database.

[0065] In one specific embodiment, the directory structure of the public interface repository 101 is as follows:

[0066] common_inc /

[0067] ├── bap_version.h # Version definition file

[0068] ├── bh_ota_hal.h # OTA upgrade HAL interface

[0069] ├── bsp / # BSP related interfaces

[0070] │ ├── bh_boot_param.h # Boot parameter structure

[0071] │ ├── bh_efuse_map.h # eFuse mapping definition

[0072] │ └── bh_soc_log.h # Log interface

[0073] ├── chip / # Chip register definition

[0074] └── fsi / # Functional Safety Island Interface

[0075] The `bap_version.h` file is the version definition file, which centrally defines the version number macros for all firmware images within the system. For example:

[0076] #define BH_BAP_VERSION_BL1 "2.1.5.0"

[0077] #define BH_BAP_VERSION_BL2 "2.1.5.0"

[0078] #define BH_BAP_VERSION_BL31 "2.1.5.0"

[0079] #define BH_BAP_VERSION_BL32 "2.1.5.0"

[0080] #define BH_BAP_VERSION_BL33 "2.1.5.0"

[0081] #define BH_BAP_VERSION_KERNEL "2.1.5.0"

[0082] #define BH_BAP_VERSION_FSI "2.1.5.0"

[0083] #define BH_BAP_VERSION_CSS "2.1.5.0"

[0084] bh_ota_hal.h is the header file for the OTA upgrade hardware abstraction layer interface, defining the OTA-related interfaces for interaction between different firmware images. For example:

[0085] int bh_hal_ota_init(void);

[0086] int bh_hal_ota_flash_fsi_image(uint32_t addr, uint32_t size);

[0087] int bh_hal_ota_switch_bank(uint32_t bank_id);

[0088] int bh_hal_ota_verify_image(const char *path);

[0089] Each firmware image implementation repository 102 references a specific commit version of the public interface repository 101 through a version locking mechanism. Specifically, when building any firmware image, the commit identifier of the referenced public interface repository is first obtained based on the version locking record. Then, the corresponding public interface repository version is checked out, and finally, the source code of the firmware image is compiled based on the interface definition of that version. This locking record is stored in the version control history of the firmware image implementation repository and can be parsed and extracted to ensure that the interface definition version used in each build is traceable and reproducible. Through the above version locking mechanism, a traceable version association is established between each firmware image implementation repository and the public interface repository, providing a data source for subsequently obtaining the commit identifier of the public interface repository referenced by each firmware image version.

[0090] In one specific embodiment, examples of firmware image implementation repositories 102 are as follows:

[0091] Firmware image implementation repository /

[0092] ├── bl31 / # BL31 implements the repository

[0093] ├── bl32 / # BL32 implements a repository

[0094] ├── kernel / # Linux kernel repository

[0095] └── ...

[0096] Each firmware image implementation repository references a specific commit version of the public interface repository 101 through a version locking mechanism (such as Git submodule, subtree, or configuration file version pin). For example, version v2.2 of the bl31 repository references aaa111, and version v5.15 of the kernel repository references abc123. This locking record is stored in the version control history of each firmware image implementation repository and can be parsed and extracted by the version locking mapping module 105.

[0097] The Interface Evolution Database 107 records the complete change history of each interface in the Public Interface Repository 101 from its introduction to its deletion. The construction process of the Interface Evolution Database 107 is as follows:

[0098] The first step is to iterate through the commit history.

[0099] The interface evolution database construction module 103 traverses the entire code commit history of the public interface repository 101 in chronological order (from earliest to latest), obtaining the commit identifier, corresponding commit time, and commit content for each code commit. In the commit history of the public interface repository 101, each commit may involve the addition, modification, or deletion of one or more interfaces.

[0100] The second step is semantic difference analysis.

[0101] The interface evolution database construction module 103 compares the set of interface definitions in the public interface repository after each code commit with the set of interface definitions in the public interface repository before the commit, and identifies the type of change for each interface through semantic difference analysis. The semantic difference analysis is based on the semantic information of the interface (i.e., function signatures, data structure fields, macro values, etc.), rather than on line-by-line comparison of file text.

[0102] Specifically, the interface evolution database construction module 103 implements semantic difference analysis through an abstract syntax tree parsing tool:

[0103] First, the interface evolution database construction module 103 calls an abstract syntax tree parsing tool (such as Clang's libclang library) to parse each header file in the public interface repository, generating abstract syntax tree representations of all interface definitions before and after this commit.

[0104] Abstract Syntax Tree (AST) is an intermediate representation of the syntax structure of source code using a tree structure. Each node corresponds to a syntax element in the source code (such as function declaration, structure definition, parameter list, etc.). Through AST, the definition information of the interface (such as function name, parameter type, return value type, structure field, etc.) is presented in a structured node form, which facilitates automatic extraction and comparison by the program.

[0105] Taking Clang's libclang interface as an example, it provides the following capabilities:

[0106] The source file is parsed into translation units using clang_parseTranslationUnit, and the root node of the abstract syntax tree corresponding to the file is obtained.

[0107] The root cursor is obtained through clang_getTranslationUnitCursor, which is used to traverse the entire abstract syntax tree;

[0108] The `clang_visitChildren` function recursively traverses each node in the abstract syntax tree, accessing function declaration nodes, struct declaration nodes, macro definition nodes, etc.

[0109] The type of a node can be obtained through clang_getCursorKind (e.g., CXCursor_FunctionDecl indicates a function declaration, and CXCursor_StructDecl indicates a structure declaration).

[0110] Get the interface name using clang_getCursorDisplayName;

[0111] The `clang_getCursorType` function retrieves the type information of an interface (such as the return type of a function, the parameter types, and the field types of a struct).

[0112] Get the complete string representation of the type using clang_getTypeSpelling.

[0113] Then, the interface evolution database construction module 103 extracts the semantic information of each interface from the abstract syntax tree: for function interfaces, it extracts the function name, parameter type list, and return value type; for data structure interfaces, it extracts the structure name, field name list, field type list, and field order; for macro definition interfaces, it extracts the macro name and macro value. The above information constitutes a semantic snapshot of the interface before and after this commit.

[0114] Finally, the interface evolution database construction module 103 compares the interface semantic snapshot after this submission with the interface semantic snapshot before this submission to identify the change type of each interface: if an interface appears in the semantic snapshot after submission but does not exist in the semantic snapshot before submission, it is identified as "added"; if it exists in the semantic snapshot before submission but does not exist in the semantic snapshot after submission, it is identified as "deleted"; if it exists in both semantic snapshots but its semantic information has changed, it is identified as "modified"; if it exists in both semantic snapshots and its semantic information is exactly the same, it is identified as "unchanged".

[0115] The third step is to identify incompatible changes.

[0116] Incompatible changes refer to situations where, after an interface definition is changed, callers that depend on that interface are unable to continue calling the interface correctly or fail to compile without modifying their own code.

[0117] For interfaces identified as "modified," the interface evolution database construction module 103 further determines whether the modification is an incompatible change. Specifically, if the difference before and after the interface modification meets at least one of the following conditions, the modification is determined to be an incompatible change: the number of function parameters changes (except for the case where a fixed parameter is added to the end of a variable parameter function); the parameter type of the function changes; the return value type of the function changes; a field of the data structure is deleted; the field order of the data structure changes; the field type of the data structure changes; or the value of a macro definition changes.

[0118] The above judgment rules are implemented at the interface semantic level, that is, whether the modified interface requires the caller to modify its calling code. If the caller cannot continue to call the interface correctly without modifying its own code, the modification is considered an incompatible change. For example, if the function parameter type is changed from a 32-bit integer to a 64-bit integer, and the caller still passes parameters as 32-bit integers, it may lead to data truncation or errors; therefore, this modification is considered an incompatible change. Similarly, if the number of function parameters increases, and the caller still calls with the original number of parameters, compilation will fail; therefore, this modification is considered an incompatible change. The above judgment rules cover various incompatible change scenarios at the interface semantic level.

[0119] The fourth step is to generate change records.

[0120] Based on the semantic difference analysis and incompatibility change judgment results described above, the interface evolution database construction module 103 generates a corresponding change record for each interface change identified in each submission. Specifically:

[0121] For interfaces identified as "new", a change record is generated for that interface, including at least the interface name, the commit identifier when the interface was first defined, a tag field, and the change operation type. The tag field in a "new" interface indicates a compatibility change, and the change operation type is "new interface".

[0122] For interfaces identified as "deleted", a change record is generated for that interface, including at least the interface name, the commit identifier when the interface was deleted, a tag field, and the change operation type. The tag field in the "deleted" interface indicates a non-compliance change, and the change operation type is "delete interface".

[0123] For interfaces identified as "modified," the semantic changes before and after the modification are used to determine whether the modification is an incompatible change, and a corresponding change record is generated. This record includes at least the name of the interface, the commit identifier when the interface was modified, a flag field indicating whether the modification is an incompatible change, and the change operation type. The change operation type for "modified" interfaces is "modify interface."

[0124] The interface evolution database construction module 103 stores all change records in the interface evolution database 107, forming a complete change history for each interface from its introduction to its deletion.

[0125] This embodiment traverses the entire commit history of the public interface repository 101 in chronological order, establishing a complete lifecycle record for each interface in the interface evolution database 107, from its initial definition to its final deletion. This timeline enables subsequent compatibility testing to accurately pinpoint which interfaces have changed between any two commit identifiers, and whether these changes are incompatible, providing a precise data foundation for the compatibility testing engine.

[0126] In existing technologies, dependency information is manually written and maintained by developers, which carries the risk of dependency declarations becoming disconnected from the actual state of the code. This embodiment automatically extracts interface change information from the commit history of the public interface repository, without relying on any manually written dependency declarations or version metadata. It is automatically built entirely based on the actual code evolution history of the public interface repository 101, eliminating the risks of information omissions and errors introduced by manual maintenance.

[0127] Existing technologies determine compatibility by comparing version number strings, but cannot distinguish between "different versions but compatible interfaces" and "different versions and incompatible interfaces." This embodiment achieves accurate identification of incompatible changes by defining specific interface semantic judgment rules (function parameter changes, structure field changes, macro value changes, etc.). This identification is based on the actual semantic information of the interface, rather than the version number string, and can accurately distinguish between compatible and incompatible changes.

[0128] In this embodiment, it is necessary to establish a pre-established association between the version number of each firmware image and the commit identifier of the public interface repository to obtain a version lock mapping table, so that in subsequent compatibility testing, the commit identifier of the public interface repository referenced by the firmware image can be obtained according to the version of the firmware image.

[0129] Version lock mapping is a data structure that records the association between each version number of each firmware image and the commit identifier of the public interface repository. Version lock mapping uses "(firmware image name, firmware image version)" as the key and "commit identifier of public interface repository" as the value, and is used to convert firmware image versions into corresponding commit identifiers.

[0130] Version Lock Record: In firmware image implementation repository 102, information about specific commit versions in the public interface repository 101 that it references is recorded. This record is stored in the version control history of the firmware image implementation repository, and its specific forms include, but are not limited to, submodule lock records, subtree lock records, or version pin records in configuration files.

[0131] The version locking mapping module 105 is connected to each firmware image repository 102, and its construction process is as follows:

[0132] (1) Obtain the list of firmware image release versions

[0133] The version locking mapping module 105 traverses the version control history of each firmware image to obtain all version numbers of each firmware image (such as "v2.1.5.0", "v2.2.0.0"). Each version number corresponds to a specific code commit time.

[0134] (2) Extract version lock records

[0135] For each version number, the version lock mapping module 105 parses the version lock record at the time of the code commit corresponding to that version number and extracts the commit identifier of the public interface repository it references. Specifically:

[0136] If the Git submodule approach is used, the version locking mapping module 105 parses the .gitmodules file and the corresponding submodule commit record at the time of the code commit for that version number to obtain the commit identifier of the public interface repository;

[0137] If the version pin method is used, the version lock mapping module 105 parses the configuration file (such as manifest.xml or version.lock) at the time of the code commit for that version number, and reads the public interface repository commit identifier recorded therein;

[0138] If the subtree method is used, the version locking mapping module 105 parses the subtree record at the time of the code commit for that version number and obtains the commit identifier of the public interface repository.

[0139] Regardless of the version locking mechanism used, the version locking mapping module 105 can extract the public interface repository commit identifier referenced by the version number from the version control history of the firmware image implementation repository.

[0140] (3) Establish mapping relationship

[0141] Version lock mapping module 105 organizes the extracted information into version lock mapping table 109. Each record in version lock mapping table 109 contains at least the following fields:

[0142] Firmware image name (e.g., "BL31", "KERNEL");

[0143] Firmware image version number (e.g., "v2.1.5.0");

[0144] The version number refers to the commit identifier of the public interface repository (e.g., "abc123def456").

[0145] The following table is an example of a version lock mapping table:

[0146]

[0147] Through the above method, version lock mapping table 109 establishes a precise mapping from firmware image version number to public interface repository commit identifier. In subsequent compatibility testing, when it is necessary to obtain the public interface repository commit identifier referenced by a specific firmware image version number, the compatibility testing module 120 can directly query version lock mapping table 109 to obtain it, without needing to re-parse the version control history of the firmware image implementation repository. Version lock mapping table 109 provides the compatibility testing module 120 with a rapid conversion capability from "firmware image version number" to "public interface repository commit identifier," enabling the compatibility testing module 120 to obtain its corresponding commit identifier using the firmware image version number (which can be specified by the user or read from the image header) as input.

[0148] In this embodiment, a set of interface names belonging to the public interface repository that are called by each version of each firmware image is established, so as to obtain the set of interfaces that each firmware image version depends on when acting as a caller in subsequent compatibility testing.

[0149] The caller refers to the party that initiates the interface call in the interface call relationship, that is, the firmware image that references and calls the interface defined in the public interface repository in its source code.

[0150] A provider refers to the party that implements and provides the interface in the interface call relationship, that is, the firmware image that implements the interface defined in the public interface repository in its source code.

[0151] A firmware image can simultaneously play both of these roles. For example, the BL31 firmware image implements several interfaces defined in the public interface repository for other images such as KERNEL to call; in this case, BL31 acts as a provider. On the other hand, the BL31 firmware image also calls the interfaces provided by the BL2 firmware image in its own source code; in this case, BL31 acts as a caller. These two roles can coexist in the same firmware image. In this embodiment, the role in a specific pairing is determined based on the specific calling relationship.

[0152] The caller interface set refers to a collection of interface names belonging to the public interface repository, which are invoked by a specific version of the firmware image when acting as the caller. This set of interface names is extracted from the firmware image's source code using an abstract syntax tree parsing tool, rather than being manually written.

[0153] The interface role database construction module 104 is connected to the firmware image implementation repository 102, and its construction process is as follows:

[0154] (1) Obtain the list of interface names in the public interface repository

[0155] The interface role database construction module 104 parses all public interface header files at the latest code commit time of the public interface repository 101, extracts the interface names of all defined interfaces, and forms a list of interface names in the public interface repository. This list is used as a filtering basis during subsequent source code parsing: only interface calls belonging to the public interface repository are extracted, excluding calls to private interfaces and standard library functions within the firmware image.

[0156] (2) Traverse the source code of each version of each firmware image

[0157] The interface role database construction module 104 iterates through the version control history of each firmware image to obtain all version numbers for each firmware image. For each version number, the interface role database construction module 104 obtains the source code at the commit time corresponding to that version number.

[0158] (3) Abstract syntax tree parsing

[0159] The interface role database construction module 104 calls the abstract syntax tree parsing tool to parse the source code corresponding to each version number and generate an abstract syntax tree representation. By traversing the abstract syntax tree, all function calls and macro references in the source code can be accurately identified, avoiding false positives and false negatives caused by text-based searches.

[0160] Specifically, the interface role database construction module 104 searches for nodes of the following types in the abstract syntax tree:

[0161] Function call nodes (such as CALL_EXPR) correspond to function call expressions in the source code;

[0162] Macro expansion nodes (such as MACRO_EXPANSION) correspond to macro references in the source code.

[0163] For each function call node or macro expansion node found, the interface role database construction module 104 extracts the symbol name corresponding to the node. This symbol name is the name of the called function or the name of the referenced macro, and is used as the interface name to be matched.

[0164] (4) Filter to form a set of caller interfaces

[0165] The interface role database construction module 104 matches the interface name to be matched extracted in step (3) with the list of public interface repository interface names obtained in step (1): if a certain interface name to be matched belongs to the public interface repository, then the interface name is included in the caller interface set; if it does not belong, then the interface name is ignored (the interface name may correspond to the firmware image's internal private function, standard library function or other non-public interface).

[0166] Through the above filtering, the interface role database construction module 104 generates a corresponding caller interface set for each version of each firmware image, that is, the set of interface names of all interfaces called by that version that belong to the public interface repository.

[0167] (5) Storage mapping relationship

[0168] The interface role database construction module 104 organizes the extracted information into an interface role database 108. Each record in the interface role database 108 contains at least the following fields:

[0169] Firmware image name (e.g., "KERNEL");

[0170] Firmware image version number (e.g., "v5.15.0");

[0171] The set of public interface repository interface names called by this version (such as {"bh_hal_ota_init", "bh_hal_ota_verify_image", ...}).

[0172] Through the above method, the interface role database 108 establishes a precise mapping from firmware image versions to the set of caller interfaces. In subsequent compatibility testing, when it is necessary to obtain the set of interface names from the public interface repository called by a specific version of a firmware image, the compatibility testing module 120 can directly query the interface role database 108 to obtain them.

[0173] The interface role database is pre-built by semantic analysis of the source code of each version of each firmware image. It does not rely on any manually written dependency declarations or interface usage records, but is automatically extracted based entirely on the actual call behavior of the firmware image source code. This eliminates potential information omissions and version number errors that may be introduced by manual maintenance, ensuring consistency between the caller interface set and the actual code. Furthermore, the interface role database can be built offline before system startup (i.e., during the build or deployment phase). During compatibility testing, only this database needs to be queried, eliminating the need for repeated semantic analysis during the online phase. Since offline building does not consume online testing time, the computational overhead of online testing is further reduced, and the testing speed is further improved.

[0174] In this embodiment, a specific implementation method for the image firmware version compatibility detection method executed by the compatibility detection module 120 is described.

[0175] refer to Figure 2 The image firmware version compatibility detection method provided in this embodiment specifically includes the following steps:

[0176] S201. Determine the first version of the first firmware image as the interface caller, and determine the second version of the second firmware image as the interface provider.

[0177] S202. Obtain the commit identifier corresponding to the public interface repository referenced by the interface caller, and record it as the first commit identifier; obtain the commit identifier corresponding to the public interface repository referenced by the interface provider, and record it as the second commit identifier.

[0178] The public interface repository includes the interface definitions used for interaction between all firmware images. Each time the code is changed, a commit identifier is generated in the public interface repository, and there is a temporal relationship between the commit identifiers based on the order of the code changes.

[0179] S203. Obtain the set of interface names of all interfaces that belong to the public interface repository and are called by the interface caller.

[0180] In this embodiment, the interface caller (i.e., the first version of the first firmware image) and the interface provider (i.e., the second version of the second firmware image) are two firmware image versions whose compatibility needs to be tested. The compatibility risk arises only from the interfaces that the interface caller depends on; that is, if the interface caller does not call a certain interface, changes to that interface do not affect the compatibility between the interface caller and the interface provider. Therefore, step S203 only obtains the set of interface names called by the interface caller, without needing to obtain the interface information of the interface provider. Whether the interfaces called by the interface caller are retained and remain compatible in this version determines whether the two versions are compatible.

[0181] Step S204: In the interface evolution database, define the submission time interval by the first submission identifier and the second submission identifier, and query all change records corresponding to each interface in the interface name set within the submission time interval.

[0182] The interface evolution database is used to record the historical change records of each interface in the public interface repository. Each change record includes the interface name, the commit identifier when the change record was generated, and a flag field used to indicate whether it is an incompatible change.

[0183] A commit sequence interval refers to the range of commit times defined by two commit identifiers in the public interface repository. This interval includes the commit record corresponding to the end boundary but excludes the commit record corresponding to the start boundary. The start boundary is the earlier of the two commit identifiers, and the end boundary is the later of the two commit identifiers. The temporal relationship between the commit identifiers is determined by the commit chain of the version control system.

[0184] Specifically, since the temporal relationship between the first commit identifier (i.e., the commit identifier referenced by the interface caller) and the second commit identifier (i.e., the commit identifier referenced by the interface provider) depends on the actual public interface repository commit version referenced by each version and is not fixed in one direction, the compatibility detection module 120 processes them according to the following cases based on the temporal relationship between the two:

[0185] Scenario 1: If the first commit identifier is earlier than the second commit identifier, then the first commit identifier is used as the starting boundary (excluding the second commit identifier) ​​and the second commit identifier is used as the ending boundary (including the second commit identifier). That is, all change records between the first commit identifier and the second commit identifier (inclusive) are queried. This range corresponds to all changes introduced during the evolution from the version corresponding to the API caller to the version corresponding to the API provider.

[0186] Scenario 2: If the second commit identifier is earlier than the first commit identifier, then the second commit identifier is used as the starting boundary (excluding the first commit identifier) ​​and the first commit identifier is used as the ending boundary (including the first commit identifier). That is, all change records between the second commit identifier and the first commit identifier (inclusive) are queried. This range corresponds to all changes introduced during the evolution from the version corresponding to the interface provider to the version corresponding to the interface caller.

[0187] Scenario 3: If the first submission identifier is the same as the second submission identifier, the compatibility detection module 120 directly determines that the version of the interface caller is compatible with the version of the interface provider.

[0188] It should be noted that when the first commit identifier and the second commit identifier are the same, it indicates that the public interface repository versions referenced by the interface caller and the interface provider are exactly the same. There are no differences between the interface definitions of the two versions of the public interface repository. Therefore, regardless of which firmware image (first firmware image or second firmware image) acts as the caller and which acts as the provider, the interface relied upon by the caller has not changed. The compatibility detection module 120 directly determines that the interface caller (first version of the first firmware image) and the interface provider (second version of the second firmware image) are compatible. Therefore, in an optional implementation, before executing step S204, it can be determined whether the first commit identifier and the second commit identifier are the same; if the first commit identifier and the second commit identifier are different, then steps S204 and S205 are executed; if the first commit identifier and the second commit identifier are the same, then steps S204 and S205 are skipped, and the interface caller and the interface provider are directly determined to be compatible.

[0189] The compatibility detection module 120 retrieves all change records containing these commit identifiers from the interface evolution database 107 based on the commit time interval, as a candidate record set. Then, it filters the candidate record set to select change records that match the interface names in the interface name set obtained in step S203, thus obtaining the target change record set. Each change record in the target change record set contains at least the interface name, commit identifier, and a flag field indicating whether it is a non-compatible change.

[0190] In one example, suppose the commit history of the public interface repository contains commit identifiers A, B, and C, with the chronological order being A earlier than B, which in turn is C.

[0191] Scenario 1: The commit identifier referenced by the caller version (i.e., the first commit identifier) ​​is A, and the commit identifier referenced by the provider version (i.e., the second commit identifier) ​​is C. Since A is earlier than C, the starting boundary is A (excluding C) and the ending boundary is C (including C). The commit time interval includes both B and C.

[0192] Scenario 2: The commit identifier referenced by the caller version (i.e., the first commit identifier) ​​is C, and the commit identifier referenced by the provider version (i.e., the second commit identifier) ​​is A. Since A is earlier than C, the starting boundary is still A (excluding C), and the ending boundary is still C (including C). The commit time interval also includes B and C.

[0193] If the set of interface names obtained through step S203 includes interfaces X1 and X2, then the compatibility detection module 120 obtains all change records containing submission identifier B or C and involving interface X1, and all change records containing submission identifier B or C and involving interface X2 from the interface evolution database 107, and merges the above-obtained change records as the target change record set.

[0194] Step S205: If there is a target change record in the queried change record that is marked as an incompatible change, then the interface corresponding to the target change record is determined as the target interface where the incompatible change occurred, and it is determined that the interface caller and the interface provider are incompatible; otherwise, it is determined that the interface caller and the interface provider are compatible.

[0195] In practice, the compatibility detection module 120 iterates through the target change record set to check if there are any change records marked as incompatible changes by a flag field.

[0196] If there is at least one target change record with a flag field indicating an incompatible change, the compatibility detection module 120 determines the interface corresponding to the target change record as the target interface that has undergone an incompatible change, and determines that the interface caller and the interface provider are incompatible.

[0197] If there are no change records marked as incompatible changes (i.e., all matching change records are compatible changes, or there are no matching change records in the query range), then the compatibility detection module 120 determines that the interface caller and the interface provider are compatible.

[0198] The following example illustrates the execution flow of steps S201 to S205.

[0199] Assume the first firmware image is KERNEL, its first version is V2.1, which acts as the interface caller; the second firmware image is BL31, its second version is V2.2, which acts as the interface provider.

[0200] The version lock mapping table 109 contains the following records:

[0201]

[0202] Therefore, the compatibility detection module 120 obtains the first submission identifier as aaa111 and the second submission identifier as bbb222.

[0203] The set of interface names that KERNEL@V2.1 calls and belongs to the public interface repository 101, recorded in the interface role database 108, is as follows:

[0204] bh_hal_ota_init

[0205] bh_hal_ota_verify_image

[0206] bh_hal_ota_check_image

[0207] The relevant change records in the interface evolution database 107 are as follows:

[0208]

[0209] Since the first submission identifier aaa111 is earlier than the second submission identifier bbb222, the submission time interval is from aaa111 to bbb222 (inclusive), which includes the change record corresponding to the submission identifier bbb222.

[0210] The compatibility detection module 120 queries the interface evolution database 107 for change records of each interface within the interface name set during the submission time interval. After obtaining the candidate record set, it filters out the target change records that match the interface name set.

[0211]

[0212] The target change log does not contain any records marked as incompatible changes; therefore, the compatibility detection module 120 determines that KERNEL@V2.1 and BL31@V2.2 are compatible. That is, although the public interface repository commit identifier referenced by KERNEL@V2.1 is aaa111, and the public interface repository commit identifier referenced by BL31@V2.2 is bbb222, and the versions of the public interface repositories referenced by the two versions are different, the interfaces that KERNEL@V2.1 depends on have not undergone incompatible changes between aaa111 and bbb222, therefore they are still considered compatible.

[0213] In step S205 above, the compatibility detection module 120 determines compatibility based on the marker field in the change record. This marker field is obtained through semantic analysis of the interface definitions in the public interface repository. Specifically, this marker field is generated during the interface evolution database construction phase after performing semantic difference analysis on the interface definitions using an abstract syntax tree parsing tool. This marker field is not based on version number comparison, but on the actual semantic information of the interface, i.e., whether there have been substantial incompatible changes to function signatures (including parameter types, number of parameters, return value types, etc.), data structure fields (including field names, field types, field order, etc.), and macro definition values.

[0214] It should be noted that steps S201-S205 above are interface compatibility checks performed with the first version of the first firmware image as the interface caller and the second version of the second firmware image as the interface provider. The test results only indicate whether there are incompatible changes in the public interface repository version referenced by the second version of the second firmware image when the first version of the first firmware image acts as the interface caller. If the test result is compatible, it means that the first version of the first firmware image can normally call the interface provided by the second version of the second firmware image at this interface level; if the test result is incompatible, it means that some interfaces depended on by the first version of the first firmware image have undergone incompatible changes in the public interface repository version of the second version of the second firmware image, and the first version of the first firmware image cannot normally call the second version of the second firmware image without modifying its own code.

[0215] The above test results do not indicate that the second version of the second firmware image can correctly call the interface provided by the first version of the first firmware image when acting as the interface caller. If it is necessary to confirm bidirectional compatibility—that is, to confirm whether the first version of the first firmware image is compatible as the interface caller and the second version of the second firmware image is compatible as the interface provider, and vice versa—then the input order of the two firmware image versions should be swapped, with the second version of the second firmware image as the interface caller and the first version of the first firmware image as the interface provider. Steps S202 to S205 should then be executed again to obtain the test results in the other direction. When the test results in both directions are compatible, it can be determined that the first version of the first firmware image and the second version of the second firmware image are mutually compatible.

[0216] The image firmware version compatibility detection method provided in this embodiment has the following beneficial effects:

[0217] First, implement automatic compatibility detection based on the actual change status of the interface.

[0218] Existing technologies determine compatibility by comparing version numbers, but cannot distinguish between "different versions but compatible interfaces" and "different versions and incompatible interfaces." This application clarifies the direction of compatibility judgment by identifying the first version of the first firmware image as the interface caller and the second version of the second firmware image as the interface provider; it defines the dependency boundaries for compatibility judgment by obtaining the set of interface names called by the interface caller; and it defines the submission time interval by defining the submission identifiers referenced by the interface caller and the interface provider respectively. In the interface evolution database, it only queries the change records of each interface within the set of interface names within the time interval, and determines whether the interface caller and the interface provider are compatible based on the flag fields in the change records that indicate whether the change is incompatible. Therefore, when the public interface repository versions referenced by the two firmware image versions are different, it can accurately determine whether the interface depended on by the interface caller has undergone substantial incompatible changes between the two versions. If the interface depended on by the interface caller has not undergone incompatible changes between the two versions (even if the version numbers of the two versions are different), it is still considered compatible. The input for compatibility judgment has been changed from "manual declaration" to "objective fact deduction," and the granularity of compatibility judgment has been changed from "version number" to "whether there are incompatible changes to the interface." This avoids the misjudgment of existing technologies that directly equate "different version numbers" with "incompatible interfaces," enabling a large number of firmware image combinations with different version numbers but semantically compatible interfaces to be correctly identified as compatible, thereby improving the system's upgrade flexibility and firmware reuse efficiency.

[0219] Second, the granularity of compatibility judgment is accurate to the specific changes made to the interface within a particular version evolution range, avoiding misjudging changes to irrelevant interfaces as incompatibility.

[0220] This application defines the submission time interval using a first submission identifier and a second submission identifier, and queries the interface evolution database to find the specific change records of each interface in the interface name set within that interval. Since the determination is based on the specific change records in the interface evolution database that include the interface name and submission identifier, the granularity of the determination is accurate to the change facts of the interface within a specific version evolution interval, avoiding the misjudgment of changes to irrelevant interfaces as incompatibility.

[0221] Third, it supports gradual upgrades and does not force all firmware images to be upgraded to the same version simultaneously.

[0222] This application uses two commit identifiers to define the query range and does not require two firmware image versions to reference the same public interface repository commit identifier. As long as the interfaces that the caller depends on have not undergone incompatible changes within this time frame, even if the two versions reference different versions of the public interface repository, they are still considered compatible. Therefore, each firmware image can evolve independently according to its own development pace without being forced to synchronize and upgrade to the same version.

[0223] In one optional embodiment, the compatibility detection module 120 obtains the first commit identifier and the second commit identifier by querying a version lock mapping table. The version lock mapping table records the association between the firmware image name and version number of each firmware image, and the commit identifier of the public interface repository it references.

[0224] Specifically, using the firmware image name and version number of the interface caller as the key, the version lock mapping table is queried to obtain the commit identifier of the public interface repository referenced by the interface caller, which is recorded as the first commit identifier; using the firmware image name and version number of the interface provider as the key, the version lock mapping table is queried to obtain the commit identifier of the public interface repository referenced by the interface provider, which is recorded as the second commit identifier.

[0225] A pre-built version lock mapping table is used to structurally store the association between firmware image version numbers and public interface repository commit identifiers. During testing, the compatibility detection module only needs to perform a table lookup operation using the firmware image name and version number as keys to obtain the corresponding commit identifier, without needing to parse the version control history of each firmware image implementation repository in real time. This table lookup operation only involves simple key-value matching, and the computational overhead is far lower than parsing lock records in the version control history, thus improving detection efficiency.

[0226] Different firmware image implementation repositories may employ different version locking mechanisms (such as Git submodules, subtrees, configuration file version pins, etc.). The version locking mapping table, built during the development phase, standardizes these differences into a mapping relationship of "firmware image name + version number → public interface repository commit identifier". The compatibility detection module does not need to be aware of the specific locking mechanisms of each image repository; it only needs to query this mapping table to obtain a unified commit identifier, thus reducing the coupling between the detection module and each image repository.

[0227] In one optional embodiment, the compatibility detection module 120 can obtain the set of interface names of the interface caller by querying the interface role database. The interface role database records the association between the firmware image name and version number of each firmware image and the set of interface names belonging to the public interface repository that it calls. Specifically, the compatibility detection module 120 queries the interface role database 108 using the firmware image name and version number of the interface caller as the key to obtain the set of interface names of all interfaces called by the interface caller that belong to the public interface repository.

[0228] The interface role database is pre-built as follows: semantic analysis is performed on the source code of each version of each firmware image to extract the interface names of all interfaces belonging to the public interface repository called by each version, resulting in a set of interface names for each version of each firmware image; the interface role database is constructed based on the firmware image name, version number, and extracted set of interface names of each firmware image. For the specific construction method of the interface role database, please refer to the aforementioned "Establishment of Interface Role Database" embodiment, which will not be repeated here.

[0229] By storing the set of interface names called by each version of each firmware image in a pre-built interface role database, the compatibility detection module only needs to perform a table lookup operation using the firmware image name and version number as keys to obtain the set of interface names. This eliminates the need for real-time abstract syntax tree parsing of the firmware image's source code during each detection. The table lookup operation involves only simple key-value matching, with computational overhead far lower than source code-level semantic analysis, thus significantly improving detection efficiency and reducing detection latency. This is particularly suitable for embedded system scenarios sensitive to startup time.

[0230] Furthermore, the query operation of the interface role database completely shields the upper-layer caller from the complex implementation details of "how to extract the interface name from the source code". The caller only needs to provide the firmware image name and version number to obtain standardized query results, which reduces the complexity of using the detection module.

[0231] In another alternative embodiment, semantic analysis can be performed on the source code of the interface caller to extract the interface names that reference the public interface repository through function calls or macro references in the source code of the interface caller, and these extracted interface names can be used as the interface name set of the interface caller. For specific implementation details, please refer to the abstract syntax tree parsing method used in the interface role database construction module 104, which will not be elaborated here.

[0232] If the interface role database 108 does not contain a set of interface names corresponding to the interface caller, for example, if the version number corresponding to the interface caller has not yet been processed by the interface role database construction module 104, the compatibility detection module 120 can extract the set of interface names of the interface caller in real time using the same method as the interface role database construction module 104 (i.e., by parsing the source code of the interface caller through the abstract syntax tree parsing tool).

[0233] When the target version of the caller interface set does not exist in the interface role database, the interface name set can be extracted directly from the source code through real-time semantic analysis. This solution does not rely on a pre-built database and can work independently in scenarios not covered by the database, improving the adaptability and robustness of the method.

[0234] In one alternative embodiment, the tag field is obtained based on objective semantic information of the interface definition in a public interface repository.

[0235] Specifically, the tag field can be obtained through either of the following two methods:

[0236] Method 1 (Semantic Difference Analysis): This method obtains the tag field by performing semantic difference analysis on the interface definitions in the public interface repository. Specifically, it uses an abstract syntax tree parsing tool to parse the interface definitions before and after submission, extracting semantic information such as function signatures, data structure fields, and macro values. It then compares whether this semantic information has changed before and after submission and whether the type of change conforms to the incompatibility change rules, thereby generating the tag field. The specific implementation method has been detailed in the construction process of the interface evolution database and will not be repeated here.

[0237] Method 2 (Rule Base Matching): This method uses a predefined incompatible change rule base for pattern matching. It matches the differences before and after the interface modification with the predefined incompatible change patterns in the rule base. If a match is found, the change is marked as incompatible.

[0238] Both of the above methods automatically obtain the tag fields based on the objective semantic information of the interface definition, rather than being manually annotated by the developer. Therefore, they are consistent and reproducible for the same interface changes, eliminating the risk of inconsistent judgment standards and annotation errors that may be introduced by manual annotation.

[0239] The above-mentioned image firmware version compatibility detection method can be applied to code commit inspection scenarios during continuous integration.

[0240] When committing code, the commit identifier of the public interface repository locked in the current version (denoted as the locked commit identifier) ​​is obtained, and the set of interface names newly called in this commit is extracted using an abstract syntax tree parsing tool. Then, using the locked commit identifier as the query endpoint, the commit identifier of the first definition of each interface in the set of newly called interface names is queried in the interface evolution database 107. If the commit identifier of the first definition of an interface is later than the locked commit identifier, or if the interface does not exist in the interface evolution database 107, it is determined that this commit uses an interface that has not yet been defined, the code merge is prevented, and the corresponding interface name and its first definition commit identifier are output.

[0241] By using the above methods, calls to undefined interfaces can be detected and prevented in a timely manner during the code submission phase, thus avoiding merging code with interface dependency issues into the main branch.

[0242] In one optional embodiment, while the compatibility detection module 120 outputs the compatibility detection result of step S205, if the detection result is incompatible, the compatibility detection module 120 can also output a list of interface names with incompatible changes.

[0243] For example, in step S205, if the compatibility detection module 120 determines that the first version of the first firmware image is incompatible with the second version of the second firmware image, the compatibility detection module 120 outputs the incompatibility detection result and outputs the interface name of the incompatible change.

[0244] Specifically, the compatibility detection module 120 filters change records from the candidate record set that match the interface names in the interface name set, obtaining a target change record set. Each change record in the target change record set includes an interface name, a commit identifier, and a tag field. When the compatibility detection module 120 determines in step S205 that there is a change record in the target change record set whose tag field indicates an incompatible change, the compatibility detection module 120 extracts the interface name from that change record. If there are multiple change records in the target change record set whose tag fields indicate incompatible changes, the compatibility detection module 120 extracts the interface name from each change record to form an incompatible interface name list. This list contains all interface names that cause incompatibility between the first version of the first firmware image and the second version of the second firmware image. The compatibility detection module 120 outputs the above incompatible interface name list as part of the detection result.

[0245] Furthermore, the change log also includes change type information. When performing semantic difference analysis on the interface definitions before and after each submission, the interface evolution database construction module 103, in addition to determining whether the change is an incompatible change, also records the corresponding change type. Therefore, when the compatibility detection module 120 extracts the incompatible interface name, it can also extract the corresponding change type of that interface and output the incompatible interface name and its change type. Change types include, but are not limited to: changes in function parameter types, changes in the number of function parameters, changes in function return value types, function deletion, deletion of structure fields, changes in structure field types, changes in the order of structure fields, and changes in macro values.

[0246] Using the above methods, developers and operations personnel can directly obtain the specific interface name causing the incompatibility, quickly locating the root cause of the problem without having to check each interface individually. If the change type is also output, developers and operations personnel can further understand the specific nature of the change (e.g., whether the interface was deleted or the parameters changed), providing more precise information for developing a remediation plan.

[0247] In one alternative embodiment, reference Figure 3Before performing step S202, the image firmware version compatibility detection method of this application embodiment further includes the following steps:

[0248] S210. Obtain the version number embedded in the header file of the API caller and the version number embedded in the header file of the API provider.

[0249] The compatibility detection module 120 reads the version number field embedded in the header file of the interface caller and the version number field embedded in the header file of the interface provider. The version number field embedded in the header file is written by the compilation system during firmware image building, protected by header file checksum, and cannot be tampered with independently, ensuring its trustworthiness.

[0250] S211. Match the combination of the version number of the interface caller and the version number of the interface provider with the version snapshots in the baseline whitelist. If the match is successful, proceed to step S212; if the match fails, proceed to steps S202-S205.

[0251] S212. Ensure that the interface caller and the interface provider are compatible.

[0252] The baseline whitelist construction process includes multiple historical version snapshots, each of which records a set of version number combinations for each firmware image. The construction of the baseline whitelist has been described in detail in the embodiment of the baseline whitelist construction module 106, and will not be repeated here.

[0253] Specifically, the compatibility detection module 120 compares the version numbers of the firmware images corresponding to the interface caller and the interface provider in each historical version snapshot in the baseline whitelist to check if there is a historical version snapshot in which the version number of the firmware image corresponding to the interface caller is the same as the version number of the currently read interface caller, and the version number of the firmware image corresponding to the interface provider is the same as the version number of the currently read interface provider.

[0254] If a historical version snapshot exists in the baseline whitelist, which contains the version numbers of the interface caller and the interface provider read in step S211, the compatibility detection module 120 directly determines that the interface caller and the interface provider are compatible, without needing to execute subsequent steps S202 to S205.

[0255] If there is no historical version snapshot in the baseline whitelist, and it contains the version numbers of the interface caller and interface provider read in step S211, then the compatibility detection module 120 continues to execute steps S202 to S205, that is, to perform accurate interface semantic compatibility verification through the complete compatibility detection process.

[0256] Steps S210 to S212 constitute the rapid pre-inspection process, which is used to quickly match the version number combination of the interface caller and the interface provider by building a baseline whitelist before entering the complete compatibility detection process, thereby improving detection efficiency.

[0257] The following example illustrates the execution flow of the fast preflight method. Assume the API caller is KERNEL@V2.1 and the API provider is BL31@V2.2. The baseline whitelist 110 includes the following historical version snapshots:

[0258]

[0259] The compatibility detection module 120 reads version number V2.1 from the header file of KERNEL@V2.1 and version number V2.2 from the header file of BL31@V2.2. It then matches the read version number combination (V2.1, V2.2) with each historical version snapshot in the baseline whitelist. The match is successful because snapshot 1 shows KERNEL version number V2.1 and BL31 version number V2.2, which matches the currently read version number combination. Therefore, the compatibility detection module 120 directly determines that KERNEL@V2.1 is compatible with BL31@V2.2, without needing to execute subsequent steps S202 to S205.

[0260] In this way, before executing the computationally expensive full compatibility testing process, the compatibility testing module 120 first performs a rapid pre-check by building a baseline whitelist. Since the historical version snapshots in the baseline whitelist are all historically verified combinations of legitimate versions, if a particular historical version snapshot contains the version number combination currently being tested, its compatibility can be directly determined. This rapid pre-check only involves comparing version number strings and does not require querying the interface evolution database, thus having extremely low computational overhead. It is particularly suitable for embedded systems with strict startup time requirements. If the rapid pre-check fails, a precise interface semantic compatibility test is then performed, ensuring both detection accuracy and efficiency.

[0261] It should be noted that the aforementioned rapid pre-inspection process is not a necessary step for implementing this compatibility testing method. Omitting this rapid pre-inspection process and directly executing steps S202 to S205 will still yield correct compatibility conclusions. This rapid pre-inspection step provides an optional implementation method to improve testing efficiency without affecting the core functionality of the compatibility testing method.

[0262] This embodiment describes a specific implementation of the image firmware version compatibility detection method performed by the whole machine verification module 130. (See reference...) Figure 4 The specific execution process of this whole-machine compatibility verification method is as follows:

[0263] S301, Obtain the target firmware set.

[0264] The whole machine verification module 130 obtains the target firmware set.

[0265] The target firmware set refers to the set of firmware images that need to be verified for overall device compatibility. It includes two types: one is all firmware images to be run during the device startup phase (such as the various firmware image versions that exist in the current system); the other is the combination of overall device firmware images formed after simulating OTA upgrade (i.e., the combination formed by upgrading some images and keeping the current version of other images).

[0266] Specifically, each firmware image in the target firmware set corresponds to a version number, and the whole device verification module 130 obtains the name and version number of each firmware image. The target firmware set can be represented as a set P = { (image A, version v1), (image B, version v2), (image C, version v3), ...}.

[0267] S302. Pair the versions of each firmware image in the target firmware set to obtain at least one pairing combination.

[0268] Specifically, if the target firmware set contains N firmware images, the whole machine verification module 130 generates all possible pairings according to the combination method in combinatorial mathematics, and the total number of pairings is N×(N-1) / 2. Each pairing combination contains two different firmware image versions, such as pairing (image A, version v1) and (image B, version v2).

[0269] For example, if the target firmware set contains three firmware images (A, v1), (B, v2), and (C, v3), then the pairing combinations include: (A, v1) and (B, v2), (A, v1) and (C, v3), and (B, v2) and (C, v3).

[0270] S303. Perform bidirectional compatibility testing on each pairing combination.

[0271] The whole machine verification module 130 traverses all the pairing combinations generated in step S302 and performs bidirectional compatibility testing on each pairing combination.

[0272] For any pairing combination, assuming the two firmware images in the pairing combination are image A (version v1) and image B (version v2), the whole-device verification module 130 performs the following bidirectional compatibility test:

[0273] First, using version v1 of image A as the interface caller and version v2 of image B as the interface provider, the compatibility detection module 120 is invoked to execute the following... Figure 2The method steps shown are used to obtain the compatibility test result in this direction (direction one), which is taken as the first compatibility test result.

[0274] Then, using version v2 of image B as the interface caller and version v1 of image A as the interface provider, the compatibility detection module 120 is invoked to execute the following... Figure 2 The method steps shown are used to obtain the compatibility test result for this direction (direction two), which is used as the second compatibility test result.

[0275] If both the first compatibility test result for direction one and the second compatibility test result for direction two are compatible, the whole machine verification module 130 determines that the pairing combination is compatible; otherwise, it determines that the pairing combination is incompatible.

[0276] S304. Generate overall system compatibility conclusions.

[0277] The whole machine verification module 130 generates a whole machine compatibility conclusion based on the test results of all paired combinations:

[0278] If step S303 determines that all paired combinations are compatible, then the whole machine verification module 130 determines that the target firmware set is compatible overall.

[0279] If any pairing is determined to be incompatible, the whole-device verification module 130 determines that the target firmware set is incompatible. In this case, the whole-device verification module 130 can also output incompatible pairing information, including the names and version numbers of the two firmware images in the pairing, the interface name that caused the incompatibility, and the change type, etc.

[0280] Through the above method, the whole machine verification module 130 will Figure 2 The illustrated image firmware version compatibility detection method is extended to multi-image scenarios, achieving global compatibility verification of the entire device firmware combination. This verification method is suitable for version consistency verification before device startup and compatibility pre-check before OTA upgrades, effectively avoiding startup failures or runtime anomalies caused by version mismatches among multiple images. Furthermore, because bidirectional detection is performed on each pairing, it ensures that any two images remain compatible when exchanging interface caller / provider roles, providing a guarantee for the stable operation of the entire system.

[0281] In one alternative embodiment, reference Figure 5 Before step S302, the whole machine verification module 130 performs the following rapid pre-inspection process:

[0282] S401. Obtain the whitelist for building the baseline.

[0283] The baseline whitelist is built by taking multiple historical version snapshots, each of which records a set of version number combinations for each firmware image.

[0284] Specifically, the baseline whitelist is constructed by parsing the commit history of version definition files (such as bap_version.h) in the public interface repository. Each commit of the version definition file records the version number of each firmware image in the system at that moment, forming a historical version snapshot. For example, a commit might record a version number combination of (BL1:v2.1.5.0, BL31: v2.1.5.0, KERNEL: v5.15.0, ...), which is extracted and used as an entry in the baseline whitelist. Each commit of the version definition file represents a set of verified and fully compatible firmware image version number combinations, which are extracted to form the baseline whitelist. If the version number combination of the current target firmware combination completely matches a historical version snapshot in the baseline whitelist, then the target firmware combination has been historically verified as compatible, and subsequent pairwise compatibility checks (i.e., steps S302~S304) are not required.

[0285] S402. Read the version number embedded in the header file of each firmware image in the target firmware set.

[0286] The whole-device verification module 130 reads the version number field embedded in the header file of each firmware image in the target firmware combination to obtain the version number of each firmware image. This version number field is written by the compilation system when the firmware image is built, and is protected by header file checksum and cannot be tampered with individually, ensuring its trustworthiness.

[0287] S403. Match the version number combination of each firmware image in the read target firmware set with each version snapshot in the baseline whitelist.

[0288] If the match is successful, meaning there is a historical version snapshot that contains the version numbers of each firmware image in the target firmware combination, then step S404 is executed, and there is no need to execute subsequent steps S302 to S304 (i.e., pairing and subsequent detection), and the process ends directly.

[0289] If the matching fails, that is, if the baseline whitelist does not contain a historical version snapshot that simultaneously contains the version numbers of each firmware image in the target firmware combination, the whole machine verification module 130 continues to execute steps S302 to S304, that is, by pairing up and calling the compatibility detection module 120 to perform precise interface semantic compatibility detection.

[0290] S404. Determine the overall compatibility of the target firmware combination.

[0291] The following example illustrates the successful matching scenario in steps S401 to S404.

[0292] Assume that the baseline whitelist 110 includes the following two historical version snapshots:

[0293] Snapshot aaa111 (2024-01-10): (BL1: v2.1.4.0, BL2: v2.1.4.0, BL31: v2.1.4.0, BL32: v2.1.4.0, KERNEL: v2.1.4.0)

[0294] Snapshot abc123 (2024-03-15): (BL1: v2.1.5.0, BL2: v2.1.5.0, BL31: v2.1.5.0,BL32: v2.1.5.0, KERNEL: v2.1.5.0)

[0295] Suppose that the version number combination read by the whole machine verification module 130 from the header file of each firmware image in the target firmware set is as follows:

[0296]

[0297] The whole machine verification module 130 compares the version number combination with each historical version snapshot in the baseline whitelist one by one:

[0298] Compared to snapshot aaa111: BL1 version number does not match (current v2.1.5.0 vs snapshot v2.1.4.0), therefore this snapshot does not match.

[0299] Comparison with snapshot abc123: The version numbers of all firmware images are the same as the corresponding version numbers in snapshot abc123, therefore the snapshot match is successful.

[0300] Since snapshot abc123 contains the version numbers of each firmware image in the target firmware set, the match is successful. The whole machine verification module 130 directly determines that the target firmware set is compatible as a whole, without needing to execute subsequent steps S302 to S304.

[0301] In this way, before performing the computationally expensive pairwise pairwise matching test, the whole-device verification module 130 first performs a rapid pre-check by building a baseline whitelist. Since the historical version snapshots in the baseline whitelist are all historically verified legitimate combinations, if the current target firmware combination perfectly matches one of these snapshots, its compatibility can be directly determined. This rapid pre-check only involves comparing version number strings and does not require interface semantic analysis, thus having extremely low computational overhead. It is particularly suitable for scenarios with strict requirements on startup time, such as the device startup phase. If the rapid pre-check fails, a precise interface semantic compatibility test is then performed, ensuring both detection accuracy and efficiency.

[0302] It should be noted that steps S401 to S404 are not essential for achieving overall system compatibility verification. Omitting this rapid pre-inspection step and directly executing steps S302 to S304 will still yield a correct overall system compatibility conclusion. This rapid pre-inspection step provides an optional implementation method to improve detection efficiency without affecting the core functionality of the overall system compatibility verification method.

[0303] In this embodiment, a specific implementation method for the firmware image version number verification method executed by the version number declaration verification module 140 is described.

[0304] Version number declaration correctness: This refers to whether the firmware image's version number correctly reflects the actual degree of change of the image's interface according to semantic versioning rules. Specifically, if the image's interface undergoes incompatible changes, the major version number should be upgraded; if the image's interface only undergoes compatible changes (such as adding a new interface), the minor version number should be upgraded; if the image's interface has not undergone any changes, the version number should not be upgraded, either the major or minor version number.

[0305] refer to Figure 6 The firmware image version number verification method provided in this embodiment specifically includes the following steps:

[0306] S501. Obtain the first and second versions of the target firmware image. The second version is a version of the target firmware image prior to the first version.

[0307] The target firmware image is a firmware image whose version number declaration is to be verified, such as BL31 or KERNEL. The first version of the target firmware image is the current version of the target firmware image (i.e., the version declared in this submission), and the second version of the target firmware image is the previous version of the target firmware image (i.e., the version declared in the previous submission).

[0308] Specifically, during the continuous integration phase, when a developer submits code changes involving the target firmware image, the version number declaration verification module 140 retrieves the version number declared in this commit for the target firmware image from the version control system as the first version, and retrieves the version number declared in the previous commit for the target firmware image as the second version. Both the first and second version numbers are recorded in a version definition file (such as bap_version.h).

[0309] S502. Obtain the commit identifier corresponding to the public interface repository referenced by the first version, and denote it as the first commit identifier; obtain the commit identifier corresponding to the public interface repository referenced by the second version, and denote it as the second commit identifier.

[0310] The public interface repository includes the interface definitions used for interaction between all firmware images. Each time the code is changed, a commit identifier is generated in the public interface repository, and there is a temporal relationship between the commit identifiers based on the order of the code changes.

[0311] Specifically, the version number declaration verification module 140 uses the firmware image name and the first version number of the target firmware image as keys to query the version lock mapping table 109, obtains the public interface repository commit identifier referenced by the first version number, and records it as the first commit identifier. Using the firmware image name and the second version number of the target firmware image as keys, it queries the version lock mapping table 109 to obtain the public interface repository commit identifier referenced by the second version number, and records it as the second commit identifier.

[0312] S503. In the interface evolution database, the first submission identifier and the second submission identifier define the submission time interval, and query all change records of the target firmware image's interface within the submission time interval.

[0313] The interface evolution database is used to record the historical change records of each interface in the public interface repository. Each change record includes the interface name, the commit identifier when the change record was generated, a flag field indicating whether it is an incompatible change, and the change operation type. The construction method of the interface evolution database 107 and the source of the flag fields contained in the change records have been described in detail in the aforementioned "Construction Process of Interface Evolution Database 107" and "Supplementary Explanation of Interface Evolution Database", and will not be repeated here.

[0314] The version number declaration verification module 140 uses the first submission identifier and the second submission identifier to define the submission time interval in the interface evolution database 107, and queries all change records of the target firmware image's interface within the submission time interval.

[0315] The specific implementation of step S503 is the same as that of step S204. Specifically, the version number declaration verification module 140 first determines the temporal sequence relationship between the first commit identifier and the second commit identifier, and uses the commit time interval defined by the two as the query range to obtain all change records located within this interval from the interface evolution database 107. Then, it filters out the change records involving the interface of the target firmware image (i.e., the interface name in the change record belongs to the interface provided or implemented by the target firmware image) from these change records.

[0316] S504. Determine the version number upgrade requirement based on the marker field and change operation type in the queried change record.

[0317] The "Change Operation Type" field identifies the type of interface change operation, with values ​​of "added" for addition, "removed" for deletion, and "modified" for modification. This field is used to distinguish between "added interface" and "deleted / modified" operations in version number upgrade checks.

[0318] The tag fields and change operation types in the change log can be obtained based on the objective semantic information of the interface definitions in the public interface repository. That is, they can be obtained through semantic difference analysis of the interface definitions in the public interface repository, or through pattern matching through a predefined incompatibility change rule base, rather than being manually annotated by developers. The above process has been fully described in the aforementioned "Construction Process of Interface Evolution Database 107" and will not be repeated here.

[0319] In practice, the correspondence between the tag field, the change operation type, and the version number upgrade requirement can be preset.

[0320] In one optional embodiment, step S504 specifically includes:

[0321] If there are incompatible changes in the queried change records, then the version number upgrade requires an upgrade of the major version number;

[0322] If there are no incompatible changes in the queryed change records but there are change records with the change operation type indicated as new, then the version number upgrade requirement is a minor version number upgrade and the major version number not upgrade.

[0323] If there are no incompatible changes in the query records and no change operation type indicated as new, then the version number upgrade requirement is that neither the major version number nor the minor version number should be upgraded.

[0324] Based on the marker fields and change operation types in the change logs, interface changes are clearly categorized into three types: non-compatibility changes, new interfaces, and other changes (or no changes), each corresponding to three different version number upgrade requirements: major version number upgrade, minor version number upgrade, and no upgrade. This rule mapping does not rely on the developer's subjective judgment; it automatically determines upgrade requirements based on objective change records in the interface evolution database, providing a clear and reproducible basis for judging version number declaration errors in weight 12.

[0325] S505, Get the version numbers of the first and second versions.

[0326] Specifically, the version number declaration verification module 140 reads the version number of the target firmware image in this submission from the version definition file (such as bap_version.h) as the first version number, and reads the version number of the target firmware image in the previous submission as the second version number.

[0327] S506. Verify whether the version number has been upgraded according to the version number upgrade requirements.

[0328] Specifically, the version number declaration verification module 140 compares the first version number with the second version number to determine whether the upgrade of the first version number meets the version number upgrade requirements determined in step S505:

[0329] If a version number upgrade requires an upgrade to the major version number, then check whether the major version number of the first version number has been upgraded relative to the major version number of the second version number.

[0330] If the version number upgrade requirement is a minor version number upgrade and the major version number not upgrade, then check whether the minor version number of the first version number has been upgraded relative to the minor version number of the second version number, and whether the major version number of the first version number has not been upgraded relative to the major version number of the second version number.

[0331] If the version number upgrade requirement is that neither the major version number nor the minor version number should be upgraded, then check whether the major version number and minor version number of the first version number have changed relative to the second version number.

[0332] If the version number of the first version is upgraded according to the upgrade requirements of the version number mentioned above, the version number declaration verification module 140 determines that the version number declaration of the first version of the target firmware image is correct; if the version number of the first version is not upgraded according to the upgrade requirements of the version number mentioned above, the version number declaration verification module 140 determines that the version number declaration of the first version of the target firmware image is incorrect.

[0333] The version number declaration verification module 140 outputs the above judgment result. If the version number declaration is determined to be incorrect, the version number declaration verification module 140 can also output the name of the target firmware image, the first version number, the second version number, and a list of interface names and change operation types that caused the version number upgrade requirement to change, so that developers can locate the problem.

[0334] Assuming that during the continuous integration phase, the version number declaration verification module 140 detects that the version number of the first version (this submission) of the target firmware image BL31 is 2.1.4.0, and the version number of the second version (the previous submission) is also 2.1.4.0, that is, the version number has not changed.

[0335] Meanwhile, a query in the Interface Evolution Database 107 revealed the following change records for interface BL31 between the two submissions:

[0336]

[0337] Due to incompatible changes, version number upgrades require an upgrade to the major version number. However, the actual version number did not change (2.1.4.0 → 2.1.4.0), failing to meet the upgrade requirements. The version number declaration verification module 140 determined a version number declaration error and output the following diagnostic information:

[0338] Check the correctness of the BL31 version number declaration...

[0339] Critical error: A breaking change occurred on BL31.

[0340] However, the version number 2.1.4.0 remains unchanged!

[0341] This error will cause subsequent version mix-up detection to fail to identify the incompatibility between this version and other images, undermining the credibility of the entire version verification system.

[0342] Details of the breaking change:

[0343] bh_hal_ota_check_image: Interface deletion

[0344] bh_hal_ota_flash_fsi_image: Parameter type changed (uint32_t → uint64_t)

[0345] Recommendation: Upgrade the Major version number of BH_BAP_VERSION_BL31.

[0346] Current version "2.1.4.0" → Recommended version "3.0.0.0"

[0347] The build has been blocked. Please correct bap_version.h and resubmit.

[0348] Through the above methods, developers and operations personnel can directly learn the specific reasons for version number declaration errors and fix suggestions, quickly locate the problem, and complete the fix.

[0349] Existing technologies rely on developers manually judging the extent of interface changes and manually upgrading version numbers, which carries the risk of errors or omissions. The firmware image version number verification method in this application obtains the first and second versions of the target firmware image, defines the submission time interval using the submission identifiers of the public interface repositories referenced by each version, queries the interface evolution database for all change records of the target firmware image's interfaces within the time interval, and automatically determines how the version number should be upgraded (major version number upgrade, minor version number upgrade, or no upgrade) based on the marker fields and change operation types in the retrieved change records. It then compares the actual version number change with the upgrade requirements, achieving automatic verification of the correctness of the version number declaration. This process does not rely on the developer's subjective judgment, ensuring the credibility of the version number declaration from the source and guaranteeing consistency between the version number and the actual interface changes.

[0350] The version number is the input basis for subsequent rapid pre-detection (such as building a baseline whitelist for matching). If the version number itself is inconsistent with the actual changes to the interface, the conclusions of the rapid detection will lose their credibility. This application verifies the correctness of the version number declaration from the source during the continuous integration phase, ensuring the consistency between the version number and the actual changes to the interface. This provides a reliable input basis for subsequent version mixing detection, thereby closing the trust chain of the entire version verification system.

[0351] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0352] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the descriptions of the above embodiments are only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as limiting the embodiments of this application. Any changes or substitutions that can be made by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for detecting image firmware version compatibility, characterized in that, include: Step S201: Determine the first version of the first firmware image as the interface caller, and determine the second version of the second firmware image as the interface provider; Step S202: Obtain the commit identifier corresponding to the public interface repository referenced by the interface caller, and record it as the first commit identifier; Obtain the commit identifier corresponding to the public interface repository referenced by the interface provider, and denote it as the second commit identifier; wherein, the public interface repository includes interface definitions used for interaction between all firmware images, the public interface repository generates a commit identifier each time the code is changed, and there is a temporal relationship between the commit identifiers based on the order of code changes; Step S203: Obtain the set of interface names of all interfaces belonging to the public interface repository that are called by the interface caller; Step S204: In the interface evolution database, the first submission identifier and the second submission identifier define the submission time interval, and query all change records corresponding to each interface in the interface name set within the submission time interval; wherein, the interface evolution database is used to record the historical change records of each interface in the public interface repository, and each change record includes the interface name, the submission identifier when the change record was generated, and a flag field used to indicate whether it is an incompatible change; Step S205: If there is a target change record in the queried change record that is indicated by the tag field as an incompatible change, then the interface corresponding to the target change record is determined as the target interface where the incompatible change has occurred, and the interface caller is determined to be incompatible with the interface provider; otherwise, the interface caller is determined to be compatible with the interface provider.

2. The method according to claim 1, characterized in that, Obtaining the first commit identifier and the second commit identifier specifically includes: Query the version lock mapping table, which records the association between the firmware image name and version number of each firmware image and the commit identifier of the public interface repository it references; Using the firmware image name and version number of the interface caller as keys, query the version lock mapping table to obtain the first submission identifier; Using the firmware image name and version number of the interface provider as keys, query the version lock mapping table to obtain the second submission identifier.

3. The method according to claim 1, characterized in that, The step of obtaining the set of interface names of all interfaces belonging to the public interface repository called by the interface caller specifically includes: Using the firmware image name and version number of the interface caller as the key, query the interface role database to obtain the set of interface names; The interface role database records the firmware image name and version number of each firmware image, and the association between them and the set of interface names belonging to the public interface repository that they call.

4. The method according to claim 3, characterized in that, The interface role database is pre-built in the following way: Semantic analysis is performed on the source code of each version of each firmware image to extract the interface names of all interfaces belonging to the public interface repository called by each version, thus obtaining the set of interface names of each version of each firmware image. The interface role database is constructed based on the firmware image name, version number, and extracted set of interface names of each firmware image.

5. The method according to claim 1, characterized in that, The step of obtaining the set of interface names of all interfaces belonging to the public interface repository called by the interface caller specifically includes: Semantic analysis is performed on the source code of the interface caller to extract the names of the interfaces that belong to the public interface repository called by the interface caller, thus obtaining the set of interface names.

6. The method according to claim 1, characterized in that, The tag field is obtained based on the objective semantic information of the interface definition in the public interface repository.

7. The method according to claim 6, characterized in that, The interface evolution database is constructed in the following way: The code commits of the public interface repository are traversed in chronological order. Semantic differences in the interface definitions of the public interface repository before and after each code commit are analyzed to identify the addition, deletion and modification of the interface. For newly added interfaces, generate a change record corresponding to the newly added interface, including the interface name, the submission identifier when the newly added interface was first defined, and a flag field indicating that it is a compatibility change; For the deleted interface, generate a change record for the deleted interface, including the interface name, the submission identifier when the interface was deleted, and a flag field indicating that it is a non-compatibility change; For modified interfaces, determine whether the modification is an incompatible change based on the semantic changes before and after the modification, and generate corresponding change records, including the interface name, the commit identifier when the interface was modified, and the tag field.

8. The method according to claim 7, characterized in that, The method of determining whether a modification is an incompatible change based on semantic changes before and after the interface modification specifically includes: If the differences before and after the interface modification meet at least one of the following conditions, the modification is determined to be an incompatible change: The number of parameters in the function changes; The parameter type of the function has changed; The function's return type has changed; The interface symbol has been removed; Fields in the data structure were deleted; The order of fields in the data structure has changed; The field types of the data structure have changed; The value of the macro definition has changed.

9. The method according to claim 1, characterized in that, Before performing step S202, the method further includes: Step S210: Obtain the version number embedded in the header file of the interface caller and the version number embedded in the header file of the interface provider; Step S211: Match the combination of the version number of the interface caller and the version number of the interface provider with each version snapshot in the baseline whitelist; wherein, the baseline whitelist includes multiple historical version snapshots, and each historical version snapshot records a set of version number combinations of each firmware image; if the match is successful, proceed to step S212; if the match fails, proceed to steps S202~S205. Step S212: Determine that the interface caller and the interface provider are compatible.

10. A method for verifying firmware image version number, characterized in that, include: Obtain a first version and a second version of the target firmware image, wherein the second version is a version of the target firmware image prior to the first version; Obtain the commit identifier corresponding to the public interface repository referenced by the first version, and denote it as the first commit identifier; Obtain the commit identifier corresponding to the public interface repository referenced by the second version, and denote it as the second commit identifier; wherein, the public interface repository includes the interface definitions used for interaction between all firmware images, the public interface repository generates a commit identifier each time the code is changed, and there is a temporal relationship between the commit identifiers based on the order of code changes; In the interface evolution database, the first submission identifier and the second submission identifier define the submission time interval, and query all change records of the interface of the target firmware image within the submission time interval; wherein, the interface evolution database is used to record the historical change records of each interface in the public interface repository; each change record includes the interface name, the submission identifier when the change record was generated, a flag field indicating whether it is an incompatible change, and the change operation type; Based on the flag fields and change operation types in the retrieved change records, determine the version number upgrade requirements; Obtain the version number corresponding to the first version and the version number corresponding to the second version; If the version number of the first version is not upgraded according to the version number upgrade requirements relative to the version number of the second version, then the version number declaration of the first version of the target firmware image is determined to be incorrect.

Images