Chip firmware upgrading method and system, electronic device and storage medium

Abstract

The application relates to the computer technical field, and particularly provides a chip firmware upgrading method and system, an electronic device and a storage medium, so as to solve the technical problem of high database maintenance cost caused by supporting different types of chip upgrading in the prior art. For this purpose, the chip firmware upgrading method comprises the following steps: based on the type of a chip to be upgraded, a corresponding container image construction mode is selected, wherein the type of the chip to be upgraded comprises supporting container upgrading and not supporting container upgrading; the built container image is transmitted to a preset database; the container image of the chip to be upgraded is called in the database, and based on the type of the chip to be upgraded, a corresponding upgrading mode is selected to upgrade the firmware of the chip to be upgraded. Through the application, the container images corresponding to the two types of chips can be stored in the same database, the types and quantities of the databases to be maintained are reduced, and the cost is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a chip firmware upgrade method, system, electronic device, and storage medium. Background Technology

[0002] With the evolution of automotive electronic and electrical architecture and the advent of the software-defined vehicle era, vehicle software exhibits significant characteristics such as numerous variations, rapid iteration, and broad layers. To improve the isolation and reusability of automotive software, container technology has been gradually introduced into the software development and over-the-air (OTA) technology of high-performance automotive chips. However, automotive hardware systems themselves are highly heterogeneous, including not only powerful SOC chips but also low-power MCU chips such as M-cores and R-cores that run real-time systems and cannot be deployed in container environments.

[0003] In existing OTA upgrade technologies, because vehicles contain multiple different types of chips, the cloud typically needs to employ multiple completely independent upgrade systems to handle the upgrade requirements of these two types of chips separately. For example, for chips that support container upgrades, their application upgrade packages usually appear in the form of standard container images and are hosted in a private image repository server; while for chips that do not support container upgrades, their upgrade packages are traditional OTA full packages in non-image format, which must rely on another traditional OTA package storage management server for independent storage, hosting, and distribution.

[0004] This hosting and upgrade model has significant drawbacks: because the underlying formats, management logic, and distribution processes of the two types of upgrade packages are completely different, they cannot be efficiently combined and unified on the cloud data plane. This forces the cloud-based operations and maintenance architecture to become extremely complex, resulting not only in a serious waste of server hardware resources but also requiring enterprises to invest substantial human and technical resources in parallel to maintain both the image database and the traditional OTA file database. Summary of the Invention

[0005] This application provides a chip firmware upgrade method, system, electronic device, and storage medium to at least solve the technical problem of high database maintenance costs caused by supporting upgrades of different types of chips in the prior art.

[0006] Firstly, this application provides a chip firmware upgrade method, including: Based on the type of chip to be upgraded, select the corresponding container image building method. The types of chips to be upgraded include those that support container upgrades and those that do not. Transfer the built container image to the preset database; The container image of the chip to be upgraded is retrieved from the database, and the corresponding upgrade method is selected based on the type of chip to be upgraded to upgrade the firmware of the chip.

[0007] In one technical solution of the chip firmware upgrade method of this application, the selection of the corresponding container image building method based on the type of chip to be upgraded includes: If the chip to be upgraded supports container upgrades, then a container image is built based on the preset configuration file corresponding to the chip to be upgraded. If the chip to be upgraded does not support container upgrades, the upgrade program and the latest firmware corresponding to the chip to be upgraded will be packaged together based on the preset base image to build a container image.

[0008] In one technical solution of the chip firmware upgrade method of this application, if the chip to be upgraded does not support container upgrade, the method further includes: Set a unique identifier in the image header information of the container image. The unique identifier is used to indicate that the chip to be upgraded does not support container upgrade.

[0009] In one technical solution of the chip firmware upgrade method of this application, before transferring the built container image to the preset database, the method further includes: Check if the container image was built successfully; If so, then transfer the container image to the database; If not, output the preset prompt message.

[0010] In one technical solution of the chip firmware upgrade method of this application, retrieving the container image of the chip to be upgraded from the database and selecting the corresponding upgrade method to upgrade the firmware of the chip to be upgraded based on the type of the chip includes: If the chip to be upgraded supports container upgrades, the corresponding container image will be transferred to the chip to be upgraded. Based on the chip to be upgraded, execute the upgrade program in the container image to upgrade the firmware of the chip; or, If the chip to be upgraded does not support container upgrades, the corresponding container image will be transferred to the preset target chip, wherein the target chip supports container upgrades and there is a communication protocol between the target chip and the chip to be upgraded. Based on the target chip, the upgrade program in the container image is executed to upgrade the firmware of the chip to be upgraded through a communication protocol.

[0011] In one technical solution of the chip firmware upgrade method of this application, after upgrading the firmware of the chip to be upgraded, the method further includes: Remove the container image from the chip that is executing the upgrade procedure.

[0012] In one technical solution of the chip firmware upgrade method of this application, if the chip to be upgraded does not support container upgrades, the method further includes the following steps before executing the upgrade program in the container image: Check whether the communication link between the target chip and the chip to be upgraded is normal; If so, proceed with the following steps.

[0013] Secondly, this application provides a chip firmware upgrade system, including: The container image building module is used to select the corresponding container image building method based on the type of chip to be upgraded. The types of chips to be upgraded include those that support container upgrades and those that do not. The image storage module is used to transfer the built container image to a pre-defined database; The upgrade module is used to retrieve the container image of the chip to be upgraded from the database, and select the corresponding upgrade method based on the type of the chip to be upgraded to upgrade the firmware of the chip.

[0014] Thirdly, this application provides a control device, comprising: Memory, used to store computer programs; A processor, used to implement the steps of the chip firmware upgrade method in any of the above technical solutions when executing a computer program.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the chip firmware upgrade method in any of the above technical solutions.

[0016] The beneficial effects of this application are: This application selects the corresponding container image building method for the type of chip to be upgraded, converting all types of firmware upgrade content into a unified container image format. This allows upgrade packages for heterogeneous chips to be seamlessly compatible and hosted in the same pre-defined database, achieving a high degree of integration at the storage level. By eliminating the need for multiple sets of heterogeneous data storage and distribution, the complexity of the upgrade process is greatly simplified, thus fundamentally solving the technical problem of high database maintenance costs caused by supporting upgrades for different types of chips. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall architecture for chip firmware upgrades according to an embodiment of this application; Figure 2 This is a schematic flowchart of the main steps of a chip firmware upgrade method according to an embodiment of this application; Figure 3This is a schematic diagram of the process flow for building a container image based on an example provided in this application; Figure 4 This is a schematic diagram of a program flow for upgrading the firmware of a chip to be upgraded, provided according to an example of this application. Figure 5 This is a schematic diagram of the main structure of a chip firmware upgrade system provided according to an embodiment of this application.

[0018] Among them, 51-Container image building module; 52-Image storage module; 53-Upgrade module. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0020] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] See Figure 1 , Figure 1The diagram shows the overall architecture of a chip firmware upgrade according to an embodiment of this application. In one implementation of this embodiment, taking the upgrade of a chip installed in a vehicle as an example, the chip firmware upgrade scheme of this application involves OTA dispatch and management performed by an OTA service center in the cloud. Simultaneously, to avoid the vehicle being unable to perform active OTA due to OTA server malfunction, it is advisable to set up an independent image repository, meaning the image repository does not use the same server as the OTA service center. This setup ensures that manual OTA can be initiated on the vehicle as long as the image server is functioning normally. On the vehicle side, a high-performance SOC chip supporting container environments and possessing network capabilities will serve as the OTA center to handle the upgrade of the entire vehicle, while other heterogeneous systems, i.e., chips that do not support container environments, will exist as peripherals, with the OTA center performing unified upgrades. Communication between the OTA center and various heterogeneous systems is determined by the hardware design scheme and can be Ethernet, SPI, or IIC protocols, etc.

[0023] See Figure 2 , Figure 2 This is a schematic flowchart illustrating the main steps of a chip firmware upgrade method provided in an embodiment of this application. Figure 2 As shown, the chip firmware upgrade method of this application mainly includes the following steps S100-S300: Step S100: Select the corresponding container image building method based on the type of chip to be upgraded.

[0024] In this embodiment, the chip to be upgraded refers to the hardware unit that needs to undergo firmware updates. The firmware update may include, but is not limited to, software programs, application layer code, and the system.

[0025] In this embodiment, the chip to be upgraded may include chips that support container upgrades and chips that do not support container upgrades. Chips that support container upgrades are those that can run operating systems such as Linux or QNX and container engines such as Docker, Containerd, or Podman. They can directly deploy and run applications in isolation using containers as carriers. Chips that do not support container upgrades are typically resource-constrained microcontrollers such as MCUs, digital signal processors such as DSPs, or real-time operating systems such as RTOS. They cannot build the underlying isolation environment of containers and can only receive and run bare-metal firmware or traditional binary packages.

[0026] A container image is a read-only standardized software package that encapsulates application code, runtime environment, system tools, library files, and dependencies. In this embodiment, it can be a standard native container image that can run directly on the chip to be upgraded, or a special image obtained by encapsulating traditional non-image format firmware data and accompanying burning or distribution programs.

[0027] In this embodiment, specific configuration scripts, engineering commands, or compilation tools are used to package and combine the expected software, data, and environmental dependencies into a standard container image according to the container standard layer. Specifically, depending on the type of chip to be upgraded, a standard application configuration image can be compiled to build the container image, or a non-image format firmware package and upgrade program can be converted into a standard container image as a whole.

[0028] In one embodiment of this example, step S100 may further include the following steps: If the chip to be upgraded supports container upgrades, a container image is built based on the preset configuration file corresponding to the chip to be upgraded; if the chip to be upgraded does not support container upgrades, the upgrade program and the latest firmware corresponding to the chip to be upgraded are packaged based on the preset base image to build a container image.

[0029] In this embodiment, the preset configuration file refers to a text configuration script or declarative file specifically used to guide the container build engine to perform automated compilation, layer stacking and packaging. It defines the basic environment, dependencies, copy path and default startup command of the native container image during the build process.

[0030] In this embodiment, the preset base image refers to a pre-compiled, read-only image template at the lowest level, which typically contains only the most basic system directory structure and the most basic system tools.

[0031] In this implementation, for chips that support container upgrades, the corresponding files can be directly called to package the application and dependent libraries into a standard container image. For chips that do not support container upgrades, a lightweight system file layer can be pulled as the base image, and the latest firmware of the chip and an upgrade program for performing flashing or transmission logic can be written as files into this image, thereby obtaining an image capable of performing upgrade tasks in a container environment.

[0032] Combination Figure 3The flowchart shown illustrates the process of building a container image. In one example of this implementation: For native container images, the image is built directly using its accompanying Dockerfile. Once built, it can be pushed to the image repository for storage management. For chips that do not support container upgrades, since their corresponding OTA packages are not applications in a container environment, in order to share an image repository with the former container images, the Busybox image can be used as the base image. The corresponding OTA packages are integrated into the base image to build the container image. In addition to simply encapsulating the OTA packages into the image and then parsing and transmitting them at the OTA center, a more efficient and low-cost building method can be used. Specifically, not only are the OTA packages packaged into Busybox, but the upgrade strategy on the OTA center side is also modified to encapsulate the upgrade program of the corresponding OTA package together with the OTA package, achieving integrated encapsulation of upgrade data and upgrade program.

[0033] This implementation method utilizes a preset base image as a standard universal carrier to package traditional non-image firmware and its accompanying upgrade program together. This allows the upgrade package of the chip to be upgraded, which does not support container upgrades, to be disguised as a standard container image and enter the preset database. Thus, it is stored in the same preset database as the upgrade package of the chip to be upgraded, which supports container environments. This reduces the types and number of databases that need to be maintained and lowers costs.

[0034] Furthermore, the steps of this embodiment may also include: for chips that do not support container upgrades, setting a unique identifier in the image header information of the corresponding container image.

[0035] In this embodiment, the image header information of the container image refers to the metadata set located at the front end of the container image file structure, which is independent of the actual payload data. It is mainly used to declare the global attributes, organizational structure, media type and index association of the image, and can be directly read by the image parsing engine without decompressing the specific data layer.

[0036] In this embodiment, a unique identifier refers to a data tag or key-value pair that, under a specific upgrade environment, can characterize the fact that the chip to be upgraded does not support container upgrades. It is used to demonstrate the uniqueness of the image to an external parser. Combined with... Figure 4 The diagram shown illustrates the program flow for upgrading the firmware of the chip to be upgraded. In this embodiment, the unique identifier is used to determine whether it is a native container image by checking whether the unique identifier is present in the image header information when parsing the container image, thereby facilitating the selection of the correct upgrade logic in subsequent upgrade steps.

[0037] In another implementation, combined with Figure 3The flowchart of container image construction shown herein may include the following steps before step S100 is completed and subsequent step S200 is started: Check if the container image was built successfully; If so, then transfer the container image to the database; If not, output the preset prompt message.

[0038] In this embodiment, detecting whether the container image has been successfully built refers to the process by which the build pipeline, specific control nodes, or testing modules verify, review, and confirm the generated image file after the container image has completed the compilation, packaging, or assembly operations.

[0039] In this embodiment, if the assembly result of the container image fully meets the preset build specifications and expected indicators, the container image is determined to be successfully built. Specifically, this can be: the image file is successfully created physically, that is, no syntax errors occur and no interruption is caused by file loss; or the internal hierarchical structure, key metadata, and encapsulated payload of the image all pass the preset integrity and availability checks.

[0040] In this implementation, if the container image build fails, a prompt message can be output, or the container build process can be attempted again. The prompt message may include, but is not limited to, predefined and stored digital text, status codes, signals, or alarms used to provide feedback to operations personnel, management platforms, log monitoring centers, or user terminals regarding the current operation status, error type, cause of the error, or repair suggestions.

[0041] This implementation method proactively checks whether the container image has been successfully built before it is officially added to the database. This allows for real-time, proactive quality control of the final artifacts during the compilation and packaging stages. Only compliant images that have been confirmed to have been successfully built are allowed to be transferred to the database. This effectively prevents damaged or invalid images caused by compilation errors, missing files, abnormal metadata, or data corruption from flowing into the core database, thus ensuring the health and consistency of the backend stored data.

[0042] continue Figure 1 The embodiment shown in this application further includes step S200, which involves transferring the constructed container image to a preset database.

[0043] In this embodiment, a preset database is used to centrally store, manage, and distribute pre-built container images, which can be deployed on a network, in the cloud, or on a specific node. Since a container image is built for each chip regardless of whether it supports container upgrades, the container images required for both types of chips to be upgraded can be stored in the same preset database. That is, the preset database can store container images required for chips that support container upgrades, as well as container images required for chips that do not support container upgrades.

[0044] Step S300: Retrieve the container image of the chip to be upgraded from the database, and select the corresponding upgrade method based on the type of the chip to be upgraded to upgrade the firmware of the chip.

[0045] In this embodiment, for a chip that does not support container upgrades, since it cannot support the container environment, other chips that can support the container environment are needed to run the upgrade program. Then, based on the communication protocol or based on an intermediate route, the firmware is distributed to the chip to be upgraded. For a chip that supports container upgrades, if its current operating status allows it to self-flash, it can launch the upgrade container itself. If its current operating status does not allow it to self-flash, it can be indirectly upgraded by other chips that also support the container environment.

[0046] In one embodiment of this example, combined with Figure 4 The flowchart shown illustrates the procedure for upgrading the firmware of the chip to be upgraded. Step S300 of this application may further include the following steps: If the chip to be upgraded supports container upgrades, the corresponding container image will be transferred to the chip to be upgraded. Based on the chip to be upgraded, execute the upgrade program in the container image to upgrade the firmware of the chip; or, If the chip to be upgraded does not support container upgrades, the corresponding container image will be transferred to the preset target chip, wherein the target chip supports container upgrades and there is a communication protocol between the target chip and the chip to be upgraded. Based on the target chip, the upgrade program in the container image is executed to upgrade the firmware of the chip to be upgraded through a communication protocol.

[0047] In this embodiment, for chips that support container upgrades, the chip itself directly replaces and runs the new container image. For chips that do not support container upgrades, a third-party target chip that supports containers acts as the host to start the image, launch the upgrade program inside the container, and then push the firmware to the chip via an inter-chip communication protocol to complete the update. Figure 4As shown, after obtaining the container image from the OTA center, the first step is to check if it is a native container image. If it is a native container image, the current system image is replaced according to the upgrade strategy of the native container image; for non-native container images, it means that the image is used to upgrade the underlying components and heterogeneous systems, so the target chip needs to execute the upgrade program inside the container.

[0048] This implementation method allows for the selective execution of different upgrade logic based on the type of chip to be upgraded. For chips that support container environments, the upgrade task is completed by the chip itself. For chips that do not support container environments, the target chip acts as an intermediary agent and host. The target chip launches a container and executes the upgrade program, and then the firmware is pushed to the chip to be upgraded through the communication protocol between the two. This solves the problem that this type of chip cannot be successfully upgraded due to the lack of a container runtime environment and independent networking capabilities, and achieves the goal of using container images to upgrade chips that do not support container environments.

[0049] Furthermore, in this embodiment, the chip firmware upgrade method of this application further includes: if the chip to be upgraded does not support container upgrades, then before executing the upgrade program in the container image, it is necessary to check whether the communication link between the target chip and the chip to be upgraded is normal; if so, then proceed with the subsequent steps. In this embodiment, if the communication link between the target chip and the chip to be upgraded is abnormal, then the subsequent steps are performed only after the communication link is normal. Through this embodiment, it is ensured that subsequent upgrade steps are only allowed to be executed under the premise that the communication channel is normal and secure, fundamentally reducing the risk of hardware damage during the upgrade process.

[0050] Furthermore, in this embodiment, after upgrading the firmware of the chip to be upgraded, the chip firmware upgrade method of this application further includes: deleting the container image from the chip executing the upgrade program. Through this embodiment, the container and its corresponding container image are directly deleted after the upgrade is completed, thereby avoiding space occupation.

[0051] In addition, in this embodiment, during the upgrade process of the chip to be upgraded that supports container upgrades, it can also determine whether to temporarily store the old container image based on user input or preset rules. If so, the old image is saved to the deletion area for temporary storage; otherwise, the old image is directly replaced.

[0052] Furthermore, in this embodiment, during the upgrade process of the chip to be upgraded, it can be determined whether the current environment meets the conditions required for a normal upgrade. Taking an automotive chip as an example, if the vehicle is currently in motion, it can be determined that the current environment is not suitable for chip upgrades. In this case, the upgrade process needs to be temporarily stopped, and the subsequent upgrade steps can only be continued after the vehicle has been stationary for a certain period of time.

[0053] Through the above embodiments, this application selects the corresponding container image construction method for the type of chip to be upgraded, converting all types of firmware upgrade content into a unified container image format. This enables upgrade packages for heterogeneous chips to be seamlessly compatible and hosted in the same preset database, achieving a high degree of integration at the storage level. By eliminating the need for multiple sets of heterogeneous data storage and distribution, the complexity of the upgrade process is greatly simplified, thus fundamentally solving the technical problem of high database maintenance costs caused by supporting upgrades of different types of chips.

[0054] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0055] Furthermore, this application also provides a chip firmware upgrade system.

[0056] See appendix Figure 5 , Figure 5 This is a main structural block diagram of a chip firmware upgrade system according to an embodiment of this application. Figure 5 As shown, the chip firmware upgrade system in this embodiment mainly includes a container image building module 51, an image storage module 52, and an upgrade module 53. In some embodiments, one or more of the container image building module 51, image storage module 52, and upgrade module 53 can be combined into a single module. In some embodiments, the container image building module 51 can be used to select a corresponding container image building method based on the type of the chip to be upgraded, wherein the type of the chip to be upgraded includes those that support container upgrades and those that do not support container upgrades. The image storage module 52 can be used to transfer the built container image to a preset database. The upgrade module 53 can be used to retrieve the container image of the chip to be upgraded from the database and select a corresponding upgrade method based on the type of the chip to be upgraded to upgrade the firmware of the chip to be upgraded. In one embodiment, the specific implementation function of the container image building module 51 can be described in step S100. In one embodiment, the specific implementation function of the image storage module 52 can be described in step S200. In one embodiment, the specific implementation function of the upgrade module 53 can be described in step S300.

[0057] Preferably, the container image building module 51 can also be used to build a container image based on a preset configuration file corresponding to the chip to be upgraded if the chip to be upgraded supports container upgrades; and to build a container image based on a preset base image by packaging the upgrade program and the latest firmware corresponding to the chip to be upgraded.

[0058] Preferably, the container image building module 51 can also be used to set a unique identifier in the image header information of the container image if the chip to be upgraded does not support container upgrade, wherein the unique identifier is used to indicate that the chip to be upgraded does not support container upgrade.

[0059] Preferably, the image storage module 52 can also be used to detect whether the container image has been successfully built before transferring the built container image to a preset database; if so, the container image is transferred to the database; if not, a preset prompt message is output.

[0060] Preferably, the upgrade module 53 can also be used to: if the chip to be upgraded supports container upgrades, transfer the corresponding container image to the chip to be upgraded; based on the chip to be upgraded, execute the upgrade program in the container image to upgrade the firmware of the chip to be upgraded; or, if the chip to be upgraded does not support container upgrades, transfer the corresponding container image to a preset target chip, wherein the target chip supports container upgrades and there is a communication protocol between the target chip and the chip to be upgraded; based on the target chip, execute the upgrade program in the container image to upgrade the firmware of the chip to be upgraded through the communication protocol.

[0061] Preferably, the upgrade module 53 can also be used to remove the container image from the chip that performed the upgrade program after the firmware of the chip to be upgraded has been upgraded.

[0062] Preferably, the upgrade module 53 can also be used to detect whether the communication link between the target chip and the chip to be upgraded is normal before executing the upgrade program in the container image if the chip to be upgraded does not support container upgrade; if so, then execute the subsequent steps.

[0063] The aforementioned chip firmware upgrade system is used for execution Figure 2 The chip firmware upgrade method embodiments shown are similar in technical principle, the technical problems solved and the technical effects produced. Those skilled in the art can clearly understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the chip firmware upgrade system can be referred to the content described in the embodiments of the chip firmware upgrade method, and will not be repeated here.

[0064] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described chip firmware upgrade method embodiments.

[0065] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described chip firmware upgrade method embodiments when running.

[0066] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0067] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the chip firmware upgrade method embodiments described above.

[0068] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described chip firmware upgrade method embodiments.

[0069] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), application-specific standard parts (ASSP), a system-on-chip (SoC), a complex programmable logic device (CPLD), a microcontroller unit (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0070] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0071] The foregoing has provided a detailed description of a chip firmware upgrade method, electronic device, storage medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A chip firmware upgrade method, characterized in that, The method includes: Based on the type of chip to be upgraded, select the corresponding container image building method, wherein the type of chip to be upgraded includes those that support container upgrades and those that do not support container upgrades; The constructed container image is then transferred to a pre-defined database; The container image of the chip to be upgraded is retrieved from the database, and the corresponding upgrade method is selected to upgrade the firmware of the chip to be upgraded based on the type of the chip.

2. The chip firmware upgrade method according to claim 1, characterized in that, The selection of the corresponding container image build method based on the type of chip to be upgraded includes: If the chip to be upgraded supports container upgrades, then the container image is built based on a preset configuration file corresponding to the chip to be upgraded; If the chip to be upgraded does not support container upgrades, the upgrade program and the latest firmware corresponding to the chip to be upgraded are packaged together based on a preset base image to build the container image.

3. The chip firmware upgrade method according to claim 2, characterized in that, If the chip to be upgraded does not support container upgrades, the method further includes: A unique identifier is set in the image header information of the container image, wherein the unique identifier is used to indicate that the chip to be upgraded does not support container upgrade.

4. The chip firmware upgrade method according to any one of claims 1-3, characterized in that, Before transferring the constructed container image to the preset database, the method further includes: Check whether the container image was built successfully; If so, the container image is transferred to the database; If not, output the preset prompt message.

5. The chip firmware upgrade method according to claim 1, characterized in that, The step of retrieving the container image of the chip to be upgraded from the database and selecting the corresponding upgrade method to upgrade the firmware of the chip to be upgraded based on the type of the chip includes: If the chip to be upgraded supports container upgrades, then the corresponding container image is transferred to the chip to be upgraded. Based on the chip to be upgraded, the upgrade program in the container image is executed to upgrade the firmware of the chip to be upgraded; or, If the chip to be upgraded does not support container upgrades, the corresponding container image is transferred to a preset target chip, wherein the target chip supports container upgrades and has a communication protocol with the chip to be upgraded. Based on the target chip, the upgrade program in the container image is executed to upgrade the firmware of the chip to be upgraded through the communication protocol.

6. The chip firmware upgrade method according to claim 5, characterized in that, After upgrading the firmware of the chip to be upgraded, the method further includes: The container image is removed from the chip that is executing the upgrade procedure.

7. The chip firmware upgrade method according to claim 5, characterized in that, If the chip to be upgraded does not support container upgrades, then before executing the upgrade program in the container image, the method further includes: Check whether the communication link between the target chip and the chip to be upgraded is normal; If so, proceed with the next steps.

8. A chip firmware upgrade system, characterized in that, The system includes: The container image building module is used to select the corresponding container image building method based on the type of chip to be upgraded, wherein the type of chip to be upgraded includes those that support container upgrades and those that do not support container upgrades. The image storage module is used to transfer the built container image to a preset database; The upgrade module is used to retrieve the container image of the chip to be upgraded from the database, and select the corresponding upgrade method to upgrade the firmware of the chip to be upgraded based on the type of the chip.

9. A control device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the chip firmware upgrade method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the chip firmware upgrade method as described in any one of claims 1 to 7.

Images