Hot update method and apparatus for firmware, chip, electronic device, computer storage medium and computer program product

Abstract

The present application relates to the field of chips, and discloses a hot update method and apparatus for firmware, a chip, an electronic device, a computer storage medium and a computer program product. The chip comprises firmware, which comprises a first firmware segment and a second firmware segment. The method comprises: in response to a power-on operation for the chip, running the first firmware segment; loading the second firmware segment by means of the first firmware segment, and running the second firmware segment; in response to a firmware upgrading instruction, updating data in the second firmware segment to obtain an updated second firmware segment; and re-running the first firmware segment, loading the updated second firmware segment by means of the first firmware segment, and running the updated second firmware segment.

Description

Firmware hot update method, device, chip, electronic device, computer storage medium and computer program product

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on and claims the priority of Chinese patent application with application number 2024101944428 and application date of February 21, 2024. The entire content of the Chinese patent application is hereby incorporated into this application by reference. Technical Field

[0003] The present application relates to the field of chips, and in particular to a firmware hot update method, device, chip, electronic device, computer storage medium, and computer program product. Background Art

[0004] Hot update is a technology that allows firmware to be updated and repaired online without shutting down or restarting the server. In related technologies, hot updates of firmware are guided by Boot Read-Only Memory (Boot ROM). Without Boot ROM, upgrading the firmware requires stopping the server, receiving the new firmware through the chip interface, and restarting the server. However, restarting the server takes a long time, which increases the time required to complete the firmware upgrade. Summary of the Invention

[0005] The present application provides a firmware hot update method, device, chip, electronic device, computer storage medium and computer program product, which can save the time of firmware upgrade when the chip does not include a boot read-only memory and improve the efficiency of firmware upgrade.

[0006] The technical solution of the embodiment of the present application is implemented as follows:

[0007] An embodiment of the present application provides a method for hot updating firmware, the method being executed by a chip, the chip including firmware, the firmware including a first firmware segment and a second firmware segment; the method comprising:

[0008] In response to a power-on operation on the chip, executing a first firmware segment of the firmware;

[0009] loading the second firmware segment through the first firmware segment and running the second firmware segment;

[0010] In response to the firmware upgrade instruction, updating the data in the second firmware segment to obtain an updated second firmware segment;

[0011] The first firmware segment is re-run, the updated second firmware segment is loaded through the first firmware segment, and the updated second firmware segment is run.

[0012] An embodiment of the present application provides a firmware hot update device, the device being executed by a chip, the chip including firmware, the firmware including a first firmware segment and a second firmware segment; the device comprising:

[0013] an execution module configured to execute a first firmware segment of the firmware in response to a power-on operation on the chip;

[0014] The running module is configured to load the second firmware segment through the first firmware segment and run the second firmware segment;

[0015] a processing module configured to update the data in the second firmware segment in response to a firmware upgrade instruction to obtain an updated second firmware segment;

[0016] The running module is configured to re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

[0017] An embodiment of the present application provides a chip, the chip including firmware, the firmware including a first firmware segment and a second firmware segment;

[0018] The chip is configured to execute the first firmware segment of the firmware in response to a power-on operation on the chip;

[0019] The chip is configured to load the second firmware segment through the first firmware segment and run the second firmware segment;

[0020] The chip is configured to update the data in the second firmware segment in response to a firmware upgrade instruction to obtain an updated second firmware segment;

[0021] The chip is configured to re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

[0022] An embodiment of the present application provides an electronic device, the electronic device including a chip, the chip including a processor and a memory, the memory being configured to store computer-executable instructions or computer programs;

[0023] The processor is configured to implement the above-mentioned firmware hot update method when executing the computer executable instructions or computer program stored in the memory.

[0024] The present embodiment provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions are executed by a processor, the above-mentioned firmware hot update method is implemented.

[0025] The present application provides a computer program product, including computer executable instructions or a computer program, which, when executed by a processor, implements the above-mentioned firmware hot update method.

[0026] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0027] The hot update method for firmware provided in an embodiment of the present application is executed by a chip, the chip includes firmware, and the firmware includes a first firmware segment and a second firmware segment. In response to a power-on operation on the chip, the first firmware segment of the firmware is run; the second firmware segment is loaded through the first firmware segment, and the second firmware segment is run; in response to a firmware upgrade instruction, the data in the second firmware segment is updated to obtain an updated second firmware segment, the first firmware segment is re-run, the updated second firmware segment is loaded through the first firmware segment, and the updated second firmware segment is run.

[0028] In an embodiment of the present application, the first firmware segment can load the second firmware segment. When the data of the second firmware segment is updated to obtain the updated second firmware segment, the updated second firmware segment can be loaded through the first firmware segment, so that the updated second firmware segment can be run, which is equivalent to completing a hot update of the firmware. That is, in an embodiment of the present application, a hot update of the firmware can be completed when the chip does not include a boot read-only memory. Moreover, in the embodiment of the present application, during the hot update of the firmware, there is no need to restart the server where the chip is located. Compared with the related art, it can save the time for firmware upgrade when the chip does not include a boot read-only memory, which is equivalent to improving the efficiency of firmware upgrade. Moreover, when there is no need to restart the server where the chip is located, the business running on the server will not stop, that is, it will not affect the operation of the business on the server, and can improve the utilization rate of the server where the chip is located. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0030] FIG1 shows a block diagram of a firmware hot update system provided by an exemplary embodiment of the present application;

[0031] FIG2 is a schematic diagram showing a method for hot updating firmware provided by an exemplary embodiment of the present application;

[0032] FIG3 shows a flowchart of a method for hot updating firmware provided by an exemplary embodiment of the present application;

[0033] FIG4 shows a schematic diagram of firmware provided by an exemplary embodiment of the present application;

[0034] FIG5 shows a schematic diagram of a firmware header provided by an exemplary embodiment of the present application;

[0035] FIG6 shows a schematic diagram of firmware provided by an exemplary embodiment of the present application;

[0036] FIG7 is a schematic diagram showing a method for hot updating firmware provided by an exemplary embodiment of the present application;

[0037] FIG8 shows a block diagram of a firmware hot update device provided by an exemplary embodiment of the present application;

[0038] FIG9 shows a block diagram of a chip structure provided by an exemplary embodiment of the present application;

[0039] FIG10 shows a block diagram of a chip structure provided by an exemplary embodiment of the present application;

[0040] FIG11 shows a schematic diagram of a chip provided by an exemplary embodiment of the present application;

[0041] FIG12 shows a schematic diagram of a hardware state machine according to an exemplary embodiment of the present application;

[0042] FIG13 shows a structural block diagram of an electronic device provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0044] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0045] The terms used in this application are for the purpose of describing particular embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0046] It should be understood that although the terms first, second, etc. may be used in this application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, a first parameter may also be referred to as a second parameter, and similarly, a second parameter may also be referred to as a first parameter. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0047] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0048] Boot ROM: A read-only memory embedded in a chip. The boot ROM contains the boot program. The function of the boot ROM is to initialize the hardware and load the firmware.

[0049] Firmware: A program written into a chip's memory, configured to control basic hardware functions or provide a low-level operating interface. Firmware is designed for specific hardware and is infrequently updated. It's typically stored in non-volatile storage media (such as Flash or EEPROM) to ensure it survives power outages.

[0050] Hot Update: It is a technology that updates and repairs firmware online without shutting down or restarting the server.

[0051] Baseboard Management Controller (BMC): An embedded controller configured to monitor the server's hardware status and perform remote management tasks, such as power on, power off, and restart, without requiring direct access to the server. A BMC enables administrators to remotely manage the server's hardware.

[0052] I2C (Inter-Integrated Circuit) is a two-wire serial communication protocol that allows multiple devices (such as sensors, microcontrollers, and other ICs) to communicate on the same bus.

[0053] Flash memory (FLASH): A nonvolatile memory, also known as a form of electronically erasable programmable read-only memory, allows for multiple erasing and rewriting during operation. It is primarily used for general data storage. In this embodiment, the flash memory may also be referred to as the first memory.

[0054] Instruction Random-Access Memory (IRAM): This is a specialized memory specifically configured to store instructions. It increases instruction read speed and reduces access latency. The microprocessor in the chip can fetch instructions from the IRAM and execute them. In this embodiment, the IRAM can also be referred to as the secondary memory.

[0055] Direct Memory Access (DMA): A technology that directly reads and writes computer memory without going through the central processing unit, which can improve data transmission efficiency.

[0056] Cyclic Redundancy Check (CRC): A cyclic code is a commonly used checksum with error detection and correction capabilities, widely used in communications. It is often used to verify data between external storage devices and computers for synchronous communication.

[0057] Clock and Reset Generator (CRG): It is the reset and clock generator of the chip. It is a circuit that can be used to generate reset signals and reset signals.

[0058] FIG1 shows a block diagram of a firmware hot update system provided by an exemplary embodiment of the present application. The firmware hot update system 100 shown in FIG1 includes: a terminal 110 and a server 120 .

[0059] Terminal 110 may be an electronic device such as a mobile phone, tablet computer, vehicle-mounted terminal (vehicle computer), wearable device, PC (Personal Computer), or unmanned reservation terminal. Terminal 110 may be equipped with a chip for implementing hot firmware updates. This chip may be installed and run various types of firmware, such as embedded firmware, upgradeable firmware, cloud-based firmware, and third-party router firmware. Embedded firmware refers to firmware that cannot be modified or updated. Upgradeable firmware refers to firmware that can be modified or upgraded, and can be overwritten or upgraded to a new version. Cloud-based firmware is firmware with embedded internet communication capabilities, including remote upgrade firmware in IoT devices. The firmware in this embodiment is upgradeable firmware. Optionally, the chip in this embodiment does not include a Boot ROM, and the chip can implement hot firmware updates without restarting terminal 110. The firmware in this chip in terminal 110 may be in the form of an app (Application), mini-program, or webpage installed in terminal 110, but this embodiment does not limit this.

[0060] Server 120 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides cloud computing services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), as well as basic cloud computing services such as big data and artificial intelligence platforms.

[0061] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to enable data computing, storage, processing, and sharing. Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology, all based on the cloud computing business model. It can form a resource pool that can be used on demand with flexibility and convenience. Cloud computing technology will become a crucial support. Backend services for technical network systems, such as video websites, image websites, and more portals, require extensive computing and storage resources. With the rapid development and application of the internet industry, every item will likely have its own unique identification mark and will need to be transmitted to backend systems for logical processing. Data of varying levels will be processed separately, and data from all industries will require a strong system backend, which can only be achieved through cloud computing.

[0062] In some embodiments, the server 120 can also be implemented as a node in a blockchain system. Blockchain is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (for anti-counterfeiting) and generate the next block. Blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0063] The terminal 110 and the server 120 may communicate with each other via a network, such as a wired or wireless network.

[0064] The server 120 is equipped with a chip for implementing hot updates of the firmware. The chip does not include a BOOT ROM, and the chip is capable of implementing hot updates of the firmware without restarting the server 120. The server 120 can issue a series of instructions to the chip, such as firmware upgrade instructions, which instruct the chip to perform a hot update of the firmware through these instructions. In addition, the server 120 can also serve as a background server for the terminal 110, configured to provide background services for the terminal 110 and the chip installed in the terminal 110. For example, the server 120 can issue a series of instructions to the terminal 110, such as firmware upgrade instructions and update instructions, which instruct the chip in the terminal 110 to perform a hot update of the firmware through these instructions.

[0065] In the firmware hot update method provided in an embodiment of the present application, the execution subject of each step can be an electronic device, which refers to an electronic device with data calculation, processing and storage capabilities, and the electronic device is equipped with a chip for implementing firmware hot update.

[0066] In some embodiments, taking the solution implementation environment shown in Figure 1 as an example, the firmware hot update method can be executed by the chip in the terminal 110, or by the chip in the server 120, or by the chip in the terminal 110 and the chip in the server 120 interacting and cooperating to execute, and this application does not limit this.

[0067] Those skilled in the art will appreciate that the number of terminals 110 and servers 120 can be greater or lesser. For example, there can be only one terminal 110 or server 120, or there can be dozens, hundreds, or even more terminals 110 or servers 120. One or more chips can also be installed in the terminals 110 and servers 120. The embodiments of this application do not limit the number and type of terminals 110, servers 120, or chips.

[0068] The increasing demand for computing power and acceleration has led to the emergence of heterogeneous servers. Heterogeneous servers are servers that integrate multiple different types of computing resources within a single computer system or cluster. These computing resources include at least one of a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing unit (TPU), or other specialized accelerators. The purpose of heterogeneous servers is to meet diverse computing needs by leveraging the strengths of different processing units. For example, specific workloads, such as graphics rendering or deep learning scenarios, can benefit from GPU acceleration, while routine business logic processing is more suited to the CPU. By integrating multiple computing resources within the same computer system or cluster, efficient resource allocation and optimized performance can be achieved. By processing chips into a card format compatible with the high-speed Peripheral Component Interconnect Express (PCIe) standard, these chips can be used as accelerators to power servers. Accelerators typically communicate with the CPU via the PCIe interface to complete acceleration tasks assigned by the CPU.

[0069] In the related art, the chip includes a boot read-only memory (Boot ROM), and the function of the Boot ROM is to load the firmware when the chip starts. The hot update of the firmware is guided by the Boot ROM. For example, the new firmware is written to the flash memory (FLASH memory) of the chip. In the case that the chip has a Boot ROM, after the server sends a hot reset (Hot Reset) signal, the chip will first execute the program inside the Boot ROM. The Boot ROM will load the new firmware in the FLASH memory into the instruction RAM (IRAM), and then the chip's processor can fetch and run the instruction, so that the new firmware can run and take effect, thereby completing the hot update of the firmware.

[0070] However, when the chip lacks a Boot ROM, the lack of a fixed Boot ROM boot process makes hot firmware updates difficult. Often, the only way to reload the new firmware into IRAM is to restart the server. For example, all services on the server must be stopped, the new firmware must be written to the chip's FLASH memory via the Baseboard Management Controller (BMC) and the I2C interface, and the server must be restarted for the new firmware to take effect. Alternatively, the new firmware can be stored on the server, distributed to the chip's main memory via PCIe, written to the chip's IRAM, and finally restarted by the server for the new firmware to take effect. Alternatively, an additional PCIe driver card can be added to act as a link between the server and the chip, cooperating with the BMC to implement the firmware update. However, restarting the server is very time-consuming, and because other services may be running on the server, restarting the server has a wide impact. Adding additional devices to the server increases the update cost.

[0071] Based on this, an embodiment of the present application proposes a hot update method for firmware, which can implement hot update of the firmware in the chip without restarting the server and adding additional devices when there is no Boot ROM in the chip.

[0072] FIG2 is a schematic diagram of a firmware hot update method provided by an exemplary embodiment of the present application. Chip 140 may be located in server 120 or in another external device that can communicate with server 120 to facilitate server 120 issuing a series of instructions to the chip in the external device or transmitting data between the server 120 and the chip in the external device.

[0073] Exemplarily, chip 140 is installed and running firmware 1410, which is the firmware before the update. Firmware 1410 includes a first firmware segment 1421 and a second firmware segment 1422. First firmware segment 1421 is used to load second firmware segment 1422, and second firmware segment 1422 is used to implement the configuration function of firmware 1410. Optionally, the configuration function includes at least one of hardware initialization, driving, control, decoding, transmission, detection, error correction, burning, and playback control.

[0074] In this embodiment, the chip 140 can perform a hot update on the firmware 1410. The updated firmware is the firmware 1420. That is, the firmware 1420 is a firmware obtained by performing a hot update on the basis of the firmware 1410. The steps of the hot update method of the firmware executed by the chip 140 are as follows:

[0075] 1. In response to a power-on operation for chip 140, first firmware segment 1421 of the firmware is executed; second firmware segment 1422 is loaded through first firmware segment 1421 and executed. The power-on operation refers to the operation of powering on chip 140. It should be noted that the power-on process of chip 140 is a ramp-up process, not an instantaneous process. The power-on moment of chip 140 is not the same as the power-on completion moment; the power-on completion moment is later than the power-on moment. When the power-on completion moment is reached, it is determined that chip 140 is powered on, and the execution of first firmware segment 1421 begins.

[0076] 2. In response to the firmware upgrade instruction, the chip 140 updates the data in the second firmware segment 1422 to obtain an updated second firmware segment 1423. In some embodiments, the second firmware segment 1422 can be overwritten with the updated second firmware segment 1423 to obtain the updated second firmware segment 1423.

[0077] The firmware upgrade instruction is used to instruct to update the data of the second firmware segment 1422 , and may also instruct to overwrite the second firmware segment 1422 . The updated second firmware segment 1423 has the same address as the second firmware segment 1422 .

[0078] Here, overwriting means overwriting, and overwriting means replacing the second firmware segment 1422 with the second firmware segment 1423, which is equivalent to completely replacing the original content. In some embodiments, the data of the second firmware segment 1422 can be cleared and the second firmware segment 1423 can be written to the address of the second firmware segment 1422, so that the second firmware segment 1422 can be completely replaced with the updated second firmware segment 1423.

[0079] The counterpart of overwriting is appending, which refers to adding new content to the original content. Optionally, at the first moment, chip 140 responds to the firmware upgrade instruction and can overwrite second firmware segment 1422 with updated second firmware segment 1423 between the first moment and the second moment.

[0080] 3. In response to the update instruction, chip 140 re-runs first firmware segment 1421 in chip 140 and loads updated second firmware segment 1423 through first firmware segment 1421, and chip 140 executes updated second firmware segment 1423. The update instruction instructs re-running first firmware segment 1421. Optionally, at a second moment, chip 140 re-runs first firmware segment 1421 in chip 140 in response to the update instruction and loads updated second firmware segment 1423 through first firmware segment 1421, and chip 140 executes updated second firmware segment 1423. Thus, updated second firmware segment 1423 executes and takes effect, achieving a hot update of firmware 140.

[0081] In the embodiment of the present application, a hot update of the firmware can be completed even when the chip does not include a boot read-only memory. Moreover, during the hot update of the firmware, the embodiment of the present application does not require a restart of the server where the chip is located. Compared with the related art, this can save the time required to perform a firmware upgrade when the chip does not include a boot read-only memory, which is equivalent to improving the efficiency of the firmware upgrade. Moreover, even when the server where the chip is located does not need to be restarted, the business running on the server will not be stopped, which means that the operation of the business on the server will not be affected, thereby improving the utilization rate of the server where the chip is located. Furthermore, in the embodiment of the present application, there is no need to add additional equipment for hot updates when the chip does not include a boot read-only memory.

[0082] FIG3 shows a flowchart of a method for hot updating firmware provided by an exemplary embodiment of the present application. This method can be executed by the chip of the terminal 120 shown in FIG1 alone, or by the chip of the server 140 shown in FIG1 alone, or by the chip of the terminal 120 shown in FIG1 and the chip of the server 140 shown in FIG1 in collaboration.

[0083] The firmware hot update method provided in the embodiment of the present application is executed by a chip, the chip includes firmware, the firmware may include a first firmware segment and a second firmware segment, and the firmware hot update method includes steps 320, 340, 360, and 380:

[0084] Step 320 , in response to a power-on operation on the chip, executing a first firmware segment of the firmware;

[0085] The power-on operation refers to the operation of powering on the chip. It should be noted that the chip power-on process is a ramp-up process, not an instantaneous process. Therefore, the chip power-on moment and the power-on completion moment are not the same moment. The power-on completion moment is later than the power-on moment. There is a first time difference between the power-on moment and the power-on completion moment. The power-on moment plus the first time difference equals the power-on completion moment. When the power-on completion moment is reached, the chip is powered on and can then run the first firmware segment.

[0086] In some embodiments, the chip is powered on according to at least one of the number of power supplies and the voltage required by the chip. In response to the chip power-on operation, after the power-on is complete, a first firmware segment of the firmware in the chip can be executed; the first firmware segment can be used to load a second firmware segment, thereby enabling the execution of the second firmware segment. At this point, the firmware in the chip has not been upgraded, and the chip is operating based on the firmware before the upgrade.

[0087] The firmware in the embodiment of the present application includes a first firmware segment and a second firmware segment. The first firmware segment is used to load the second firmware segment, and the second firmware segment is used to implement the configuration function of the firmware. Optionally, the configuration function includes at least one of: hardware initialization, driving, control, decoding, transmission, detection, error correction, burning, and playback control.

[0088] In some embodiments, the first firmware segment can be compiled, linked and assembled in advance to obtain a first file of the first firmware segment, and the second firmware segment can also be compiled, linked and assembled in advance to obtain a second file of the second firmware segment, wherein the first file and the second file can both be binary files.

[0089] After obtaining the first file and the second file, the first file of the first firmware segment and the second file of the second firmware segment can be merged to obtain a third file, and the merged third file can be burned into the chip, wherein the third file is also a binary file.

[0090] In some embodiments, the combined third file can be burned into the first memory of the chip, which can be a flash memory (FLASH). It should be noted that the above-mentioned compilation, linking, assembly, and burning processes can be performed by a server, can be controlled by the server to execute the chip itself, or can be manually performed by a developer, and are not limited here.

[0091] In some embodiments, the firmware may include a boot firmware header, a first firmware segment, a second firmware segment, and padding data, wherein the boot firmware header may be referred to as a firmware header. For example, FIG4 shows a schematic diagram of firmware provided by an exemplary embodiment of the present application. The firmware includes: a first firmware segment 20, a second firmware segment 40. The firmware also includes: a firmware header 10 located before the first firmware segment 20, and data padding 30 located between the first firmware segment 20 and the second firmware segment 40. The firmware shown in FIG4 includes the firmware header 10, the first firmware segment 20, the data padding 30, and the second firmware segment 40 arranged in sequence.

[0092] The firmware header 10 is the beginning of a firmware file (i.e., firmware). The firmware header 10 stores firmware information, including a magic number. The magic number can be a pre-set numeric value or string that identifies the format and type of the firmware. The firmware can be stored as a firmware file, which includes firmware data.

[0093] The firmware information may further include the length information of the firmware file. The firmware information may further include a check code for verifying the integrity of the firmware file, that is, the check code may be used to verify whether the firmware data is complete.

[0094] The firmware information may also include firmware version information, firmware partition information and firmware startup address, wherein the partition information is the offset address and length of different contents included in the firmware, the different contents included in the firmware may be a boot loader, a kernel and a file system, the boot loader is the boot loader, and the firmware startup address is the first address of the first firmware segment in the firmware.

[0095] The firmware header 10 is used to instruct the boot loader to load firmware data. In some embodiments, the firmware data can be stored in a flash memory (FLASH), which is also referred to as the first memory in this embodiment. The firmware header 10 can be used to instruct the boot loader to load the firmware data from the flash memory. In some embodiments, the size of the firmware header can be set to 32 bytes and can be stored at address 0x0 of the flash memory (FLASH). The size of the firmware is the number of bytes occupied by the firmware header in the first memory.

[0096] The version information of the firmware may also be referred to as a firmware version field (Boot FW Version). The version information may be represented by at least one of a date, a number, a letter, and a symbol, and may be determined based on actual usage.

[0097] The firmware information may also include the firmware size (Firmware Total Size), which is used to characterize the size of the space occupied by the firmware file, that is, the number of bytes occupied by the firmware in the first memory. The firmware size can be determined by the firmware page size field (Boot FW Page Size) and the firmware page number field (Boot FW Page Len).

[0098] In some embodiments, the firmware size can also be determined based on the firmware header size, firmware code size, firmware data size, verification code size, and reserved field size, that is, the firmware size is the sum of the firmware header size, firmware code size, firmware data size, verification code size, and reserved field size. It should be noted that the firmware data includes the data corresponding to the entire firmware, that is, the firmware data includes the firmware header data, firmware code, firmware data, verification code, and reserved fields, and the firmware data is the firmware configuration data and pre-set static data.

[0099] In some embodiments, FIG5 shows a schematic diagram of a firmware header provided by an exemplary embodiment of the present application. In this embodiment, the data format of the firmware header 10 can be: [31:0] is the firmware version field, occupying 32 bits; [36:32] is the firmware page size field, occupying 5 bits; [39:37] is the reserved field, occupying 3 bits; [59:40] is the firmware page number field, occupying 20 bits; [127:60] is the reserved field, occupying 68 bits; and [255:128] is the checksum field, occupying 128 bits.

[0100] The firmware page size field defines the size of each page of the firmware stored in the first memory. The page is the basic unit of the first memory and is used for erase and write operations on the first memory. The firmware page size field is used to indicate the page size of the firmware moved from the first memory, where the page refers to the memory page. The firmware data is moved according to the memory page, and the page size range is 16-256 bytes.

[0101] The Firmware Page Number field defines the number of pages occupied by the firmware in the first memory and is used to indicate the number of firmware pages transferred from the first memory. The product of the Firmware Page Size field and the Firmware Page Number field is used to represent the firmware size. The firmware size is less than or equal to the first threshold. In other words, the upper limit of the firmware size satisfies the following condition: the Firmware Page Size field multiplied by the Firmware Page Number field multiplied by 16 bytes is less than or equal to 128 kilobytes.

[0102] The check code field (i.e., the check code) is used to check whether there is any loading error in the firmware data. Optionally, the check code can be at least one of a parity check code, a Hamming check code, a hash code, and a cyclic redundancy check code (CRC).

[0103] The parity check code can be used for at least one of odd parity and even parity. Odd parity ensures that the number of 1s in the binary bits of the data is odd, while even parity ensures that the number of 1s in the binary bits of the data is even. The parity check code can include at least one of a horizontal parity check code, a vertical parity check code, and a horizontal and vertical parity check code.

[0104] Hamming check codes are used to correct bit errors by introducing redundant bits into the data. Hash check codes are used to verify data integrity by converting data into a fixed-length hash value through a hash function. The hash code changes significantly when the data changes.

[0105] Cyclic redundancy check (CRC) uses polynomial division to generate a redundancy check code. The sender divides the data by the generating polynomial and appends the remainder to the end of the data before sending it. The receiver then divides the data using the same generating polynomial. If the remainder is not zero, it indicates an error in the data.

[0106] In this embodiment, a cyclic redundancy check code can be used, and the check code field is a CRC check code field. CRC calculation is performed simultaneously during the process of transporting the firmware data, and a check code calculation result is calculated when the transport is completed. By comparing the check code calculation result with the check code in the check code field, it is determined whether there is a loading error in the firmware data. When the check code calculation result is the same as the check code in the check code field, it is determined that there is no loading error in the data, which means that the firmware data is complete. When the check code calculation result is different from the check code in the check code field, it is determined that there is a loading error in the data. At this time, the firmware data can be reloaded, or the pre-backed-up firmware can be loaded. In this way, it can be accurately determined whether the transported firmware data is complete, so that the firmware data can be used for the subsequent operation of the first firmware segment, thereby ensuring the successful operation of the first firmware segment.

[0107] In some embodiments, FIG6 shows a schematic diagram of firmware provided by an exemplary embodiment of the present application. Referring to the left side (1) of FIG6 , the firmware includes a first firmware segment 20 and a second firmware segment 40 .

[0108] The first firmware segment 20 includes a first portion 21, a second portion 22, a third portion 23, and a fourth portion 24. The first portion 21 is used to store the internal interrupt vectors (Internal Interrupt Vectors 0-15) of the first firmware segment, where 0-15 represent the bits occupied by the internal interrupt vectors. In some embodiments, the internal interrupt vectors include at least one of the following: an initial stack pointer, a reset handler, and a system timer interrupt handler. The initial stack pointer and reset handler enable proper startup and initialization of the hardware and team environment. The system timer interrupt handler is used to handle timer interrupts.

[0109] The second portion 22 is used to store the external interrupt vectors (External Interrupt Vectors 16-255) of the first firmware segment, where bits 16-255 represent the bits occupied by the external interrupt vectors. The third portion 23 is used to store the boot loader startup code (Boot Loader Startup Code). By running this boot loader startup code, the first firmware segment 10 can load the second firmware segment 40. The content stored in the fourth portion 24 can be set according to actual usage requirements and is not limited here.

[0110] It should be noted that both the internal interrupt vector and the external interrupt vector mentioned above can be referred to as interrupt vectors. An interrupt vector is the address used by the processor to locate the interrupt handler when an interrupt occurs. An internal interrupt vector refers to an interrupt vector triggered by an internal processor event (such as an exception or system call), while an external interrupt vector refers to an interrupt vector triggered by an external processor event (such as an external device request).

[0111] An interrupt vector is the address of the interrupt entry point generated by hardware or the address of the interrupt service routine. An interrupt occurs when an exception or a pre-set request occurs during program execution. The chip stops the current program and processes the exception or pre-set request. After processing, the chip returns to the point where the current program was interrupted and continues executing the original program (i.e., the interrupted program).

[0112] 6 , the second firmware segment 40 includes a first portion 41, a second portion 42, a third portion 43, and a fourth portion 44. The first portion 41 is used to store the internal interrupt vectors (Internal Interrupt Vectors 0'-15') of the second firmware segment, where 0'-15' represent the bits occupied by the internal interrupt vectors, and the symbol ' is used to distinguish the internal interrupt vectors of the first firmware segment 20 from the internal interrupt vectors of the second firmware segment 40.

[0113] Second section 42 is used to store the external interrupt vectors (External Interrupt Vectors 16'-255') of the second firmware segment. 16'-255' represents the bits occupied by the external interrupt vectors, and the symbol ' is used to distinguish the external interrupt vectors of first firmware segment 20 from the external interrupt vectors of second firmware segment 40. Third section 43 is used to store the second firmware segment startup code (Secondary Fw Startup Code), which enables the successful startup of second firmware segment 40. The content stored in fourth section 44 can be set according to actual usage requirements and is not limited here.

[0114] Continuing to refer to FIG. 3 , step 340 is to load the second firmware segment through the first firmware segment and run the second firmware segment.

[0115] In some embodiments, the first firmware segment is used to load the second firmware segment. The second firmware segment can be recorded in the first firmware segment, thereby enabling the second firmware segment to be executed. In some embodiments, after the chip is powered on, the firmware data can be loaded from the first memory to the second memory, thereby enabling the first firmware segment stored in the second memory to be executed. The second firmware segment can be recorded in the first firmware segment, thereby enabling the second firmware segment stored in the second memory to be executed. In this manner, the second firmware segment can be executed.

[0116] Step 360: In response to the firmware upgrade instruction, update the data in the second firmware segment to obtain an updated second firmware segment.

[0117] In some embodiments, the firmware upgrade instruction may be sent from a server to the chip. In some embodiments, in response to the firmware upgrade instruction, the second firmware segment may be overwritten with an updated second firmware segment, where the address of the updated second firmware segment is the same as the address of the second firmware segment. In this manner, the data in the second firmware segment may be updated, thereby achieving a firmware update.

[0118] The firmware upgrade instruction is used to instruct to overwrite the second firmware segment with the updated second firmware segment, overwriting means overwriting, and overwriting means replacing the second firmware segment with the updated second firmware segment.

[0119] In some embodiments, the address of the second firmware segment can be obtained, the second firmware segment can be cleared, and the updated second firmware segment can be written to the address of the second firmware segment, thereby completely replacing the second firmware segment with the updated second firmware segment. The address of the updated second firmware segment is the same as the address of the second firmware segment. In this way, the data in the second firmware segment can be updated, thereby achieving a firmware update.

[0120] The address of the second firmware segment refers to the address of the second firmware segment in the chip, for example, the address of the second firmware segment in the chip's memory. The address can be represented by at least one of a number, a letter, and a symbol. The first firmware segment pre-stores the address of the second firmware segment, and the first firmware segment can load the second firmware segment according to the address of the second firmware segment.

[0121] In some embodiments, in response to a firmware upgrade instruction, the address where the second firmware segment is stored can be obtained. The address where the second firmware segment is stored can be a second address. Based on the second address, the data in the second firmware segment can be updated to obtain an updated second firmware segment. In this way, the data in the second firmware segment can be updated, thereby achieving a firmware update.

[0122] In some embodiments, in response to a firmware upgrade instruction, first data is obtained, which is the data of the updated second firmware segment, the data of the second firmware segment is deleted, and the first data is stored at the second address to obtain the updated second firmware segment. In this way, the data in the second firmware segment can be updated, thereby achieving a firmware update.

[0123] In some embodiments, obtaining the first data may include receiving the first data sent by an external device, which may be a terminal or a server, or a removable storage device, and may be configured according to actual usage requirements. In this way, accurate first data may be obtained, thereby improving the accuracy of firmware upgrades.

[0124] In some embodiments, obtaining the first data can also be obtaining the first data from a third address of the chip. The third address can be an address corresponding to any location in the first memory, which is equivalent to pre-storing the data of the updated second firmware segment to the chip. When a firmware upgrade is required, the first data can be obtained based on the third address. In this way, accurate first data can be obtained, thereby improving the accuracy of firmware upgrades. In the embodiments of the present application, different methods can be used to obtain the first data, thereby increasing the diversity of obtaining the first data.

[0125] In some embodiments, the firmware can be stored in flash memory (FLASH), that is, the second firmware segment is stored in flash memory (FLASH). In some embodiments, the firmware can also be stored in erasable programmable read-only memory (EEPROM), that is, the second firmware segment is stored in EEPROM. In some embodiments, the firmware can also be stored in a designated memory in the chip, that is, the second firmware segment is stored in the designated memory.

[0126] In some embodiments, the chip responds to the firmware upgrade instruction and overwrites the second firmware segment with an updated second firmware segment according to the address of the second firmware segment; wherein the address of the updated second firmware segment is the same as the address of the second firmware segment. In an embodiment of the present application, the address of the updated second firmware segment is the same as the address of the second firmware segment, and the address of the second firmware segment (i.e., the second address) is stored in the first firmware segment. For the first firmware segment, if the data of the second firmware segment is not updated, the first firmware segment can be used to load the first firmware segment. If the data of the second firmware segment is updated, the second firmware segment can be used to load the second firmware segment. That is to say, the first firmware segment can load different second firmware segments at different times according to the address of the second firmware segment. For different second firmware segments, the first firmware segment does not need to maintain the addresses of different second firmware segments. In this way, the cost of maintaining the addresses of different second firmware segments can be saved, and the efficiency of loading different second firmware segments can be improved.

[0127] In other words, the first firmware segment does not need to modify or store the addresses required to load the second firmware segment and the updated second firmware segment for different second firmware segments, nor does it need to store other new addresses. The first firmware segment can still load the updated second firmware segment according to the address of the second firmware segment (i.e., the second address), which is conducive to improving data loading efficiency.

[0128] It should be noted that the duration corresponding to the process of overwriting the second firmware segment with the updated second firmware segment in this embodiment is less than the preset duration, where the preset duration is a maximum value to increase the update speed of the entire firmware and achieve fast and imperceptible firmware upgrades.

[0129] In some embodiments, during the execution of step 360, in order to further improve the accuracy of the hot update of the firmware, the chip can stop the operation of the firmware, thereby overwriting the second firmware segment with the updated second firmware segment, that is, updating the data in the second firmware segment, so as to obtain the updated second firmware segment. In this way, the accuracy of the data in the updated second firmware segment can be further improved, thereby further improving the accuracy of the hot update of the firmware.

[0130] Step 380: re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

[0131] In some embodiments, steps 360 and 380 shown in FIG3 can both be triggered by a firmware upgrade instruction. In response to the firmware upgrade instruction, the data in the second firmware segment can be updated to obtain an updated second firmware segment. In response to obtaining the updated second firmware segment, the first firmware segment can be re-run. The updated second firmware segment can then be loaded through the first firmware segment and the updated second firmware segment can be run. In this way, a single firmware upgrade instruction can be used to completely update the data in the second firmware segment and run the second firmware segment, thereby improving the efficiency of firmware hot updates.

[0132] In some embodiments, in response to an update instruction, the first firmware segment may be re-run, the updated second firmware segment may be loaded through the first firmware segment, and the updated second firmware segment may be run, wherein the update instruction may be sent from a server to the chip.

[0133] In some embodiments, the update instruction may be a hot reset instruction. A hot reset refers to the process of reinitializing a portion of the chip's hardware to its initial state without turning off the power supply. The aforementioned portion of hardware may be registers in the processor. For example, after a hot reset and before running the first firmware segment in the second memory, the register will point to the first firmware segment, while the contents of the second memory remain unchanged. A hot reset instruction, also known as a hot reset command, is an online instruction that is valid only when the chip is in online mode.

[0134] In some embodiments, the chip re-runs the first firmware segment in the chip in response to the update instruction. Since the first firmware segment in this embodiment is used to load the second firmware segment, and the first firmware segment stores the second address (i.e., the address where the updated second firmware segment is stored), when the first firmware segment is re-run, the first firmware segment automatically loads the updated second firmware segment and can jump to the updated second firmware segment for execution. This is equivalent to loading the updated second firmware segment through the first firmware segment, and the chip can then execute the updated second firmware segment.

[0135] The firmware hot update method provided in the embodiment of the present application is executed by a chip. The chip includes firmware, and the firmware includes a first firmware segment and a second firmware segment. The first firmware segment is used to load the second firmware segment, and the second firmware segment is used to implement the configuration function of the firmware.

[0136] In the hot update method of firmware provided in an embodiment of the present application, in response to a power-on operation on a chip, a first firmware segment of the firmware is run; a second firmware segment is loaded through the first firmware segment, and the second firmware segment is run; in response to a firmware upgrade instruction, data in the second firmware segment is updated to obtain an updated second firmware segment, the first firmware segment is re-run, the updated second firmware segment is loaded through the first firmware segment, and the updated second firmware segment is run.

[0137] In an embodiment of the present application, the first firmware segment can load the second firmware segment. When the data of the second firmware segment is updated to obtain the updated second firmware segment, the updated second firmware segment can be loaded through the first firmware segment, so that the updated second firmware segment can be run, which is equivalent to completing a hot update of the firmware. That is, in an embodiment of the present application, a hot update of the firmware can be completed when the chip does not include a boot read-only memory. Moreover, in the embodiment of the present application, during the hot update of the firmware, there is no need to restart the server where the chip is located. Compared with the related art, it can save the time for firmware upgrade when the chip does not include a boot read-only memory, which is equivalent to improving the efficiency of firmware upgrade. Moreover, when there is no need to restart the server where the chip is located, the business running on the server will not stop, that is, it will not affect the operation of the business on the server, and can improve the utilization rate of the server where the chip is located.

[0138] That is to say, the embodiment of the present application can run the first firmware segment, and the first firmware segment can load and run the second firmware segment, so that the second firmware segment can run and take effect. Thus, when the chip does not contain a boot read-only memory, the second firmware segment can be overwritten with the updated second firmware segment, and by re-running the first firmware segment, the first firmware segment can load and run the updated second firmware segment, so that the updated second firmware segment can run and take effect. Since the second firmware segment is used to implement the configuration function of the firmware, when the updated second firmware segment runs and takes effect, the hot update of the entire firmware is also realized. During the firmware update process in this solution, there is no need to restart the server where the chip is located, and there is no need to stop other services on the server, which greatly simplifies and accelerates the firmware upgrade process and realizes the imperceptible upgrade of the firmware.

[0139] In some embodiments, the chip includes a processor, which may also be referred to as a microprocessor, wherein the microprocessor is a central processing unit composed of one or a few large-scale integrated circuits. The chip may execute the re-running of the first firmware segment in step 380 shown in FIG. 3 .

[0140] In some embodiments, step 380 shown in FIG3 can be implemented by resetting the processor in response to the update instruction and re-running the first firmware segment. In some embodiments, the processor includes a first register. In response to the update instruction, the processor can be reset and the first firmware segment can be re-run based on the first firmware segment pointed to by the first register in the reset processor. The first register is a program counter.

[0141] In some embodiments, in response to the update instruction, the processor may be reset, and resetting the processor includes register initialization, peripheral initialization, interrupt system initialization, memory mapping initialization, and other hardware initialization.

[0142] Among them, the registers may include a first register, a second register and a third register, etc. The first register may be a program counter, the second register may be a stack pointer, and the third register may be a status register. Of course, they can be set according to actual usage requirements and are not limited here.

[0143] The following describes register initialization. Regarding the first register, during a processor reset, the first register can be set to an initial value. The initial value of the first register points to the first address of the first firmware segment. The initial value is the address of the reset handler function in the reset vector table (i.e., the first address). The reset vector is stored in the processor's memory. The first entry in the reset vector table is the value of the initial stack pointer, and the second entry in the reset vector table is the address of the reset handler function.

[0144] For the second register, during the process of resetting the processor, the second register can be set to the value of the initial stack pointer. For the third register, during the process of resetting the processor, the third register can be set to a default value indicating that the processor is in an initial state.

[0145] Peripheral initialization simply sets the peripherals to their first default state. Interrupt system initialization disables interrupts and sets the interrupt controller to its second default state. Memory mapping initialization sets the memory map to its third default state. The first, second, and third default states can be set based on actual usage requirements.

[0146] In some embodiments, the first firmware segment can be re-executed based on the first firmware segment pointed to by the first register in the processor after the reset. The first firmware segment pointed to by the first register means that the first register is set to the address of the reset processing function in the reset vector table, i.e., the first address. This is equivalent to re-executing the first firmware segment based on the first address. In some embodiments, the processor can re-execute the first firmware segment based on the first address of the first firmware segment. In this way, the first firmware segment can be accurately re-executed.

[0147] In the firmware hot update method provided in the embodiment of the present application, the chip responds to the update instruction, resets the processor, and re-runs the first firmware segment. In this way, the first firmware segment in the firmware can be successfully run even if the chip does not have a Boot ROM.

[0148] In the hot update method of firmware provided in the embodiment of the present application, since the first firmware segment can be used to load the updated second firmware segment, the successful operation of the subsequent updated second firmware segment can be achieved by running the first firmware segment, thereby realizing the hot update of the firmware.

[0149] In some embodiments, in response to the update instruction, the processor is reset. After the reset, the processor can fetch instructions and execute them, thereby re-running the first firmware segment. In some embodiments, after the reset, the processor can fetch the first instruction from the first address pointed to by the program counter, which is equivalent to fetching the first instruction from the first firmware segment based on the first register in the reset processor pointing to the first firmware segment.

[0150] Then, the processor may compile the first instruction and determine the type and operation of the first instruction. The operation of the first instruction is used to instruct the execution of the first firmware segment, so the first firmware segment may be re-executed.

[0151] In some embodiments, the first register is a program counter (PCR), also known as an instruction pointer (IPR). The first register is used to store the address of the next instruction to be executed. In some embodiments, the chip's processor reads the address of the current instruction from the first register and then executes the current instruction based on the instruction type, addressing mode, and other factors of the current instruction. After the current instruction is executed, the first register stores the address of the next instruction, and the chip's processor repeats the above instruction execution process to execute the next instruction.

[0152] In some embodiments, in response to an update instruction, the processor is reset, instructions are fetched and executed based on the first firmware segment pointed to by the first register in the reset processor, and the first firmware segment is re-executed; wherein the first register in the reset processor is used to point to the first firmware segment.

[0153] In some embodiments, after resetting the processor in the chip, the first register in the processor is restored to its initial state. In this embodiment, since the chip does not have a boot read-only memory, the first register in the processor is pre-set to point to the first firmware segment in the initial state. The chip can re-run the first firmware segment, thereby loading the second firmware segment through the first firmware segment and executing the second firmware segment.

[0154] It should be noted that in the related art, when a chip has a boot read-only memory, when the first register is in its initial state, the first register in the processor generally points to the boot read-only memory, allowing the chip to run the program in the boot read-only memory and load the updated firmware through the boot read-only memory to run the updated firmware. By comparison, it can be seen that the first register in the processor in the embodiment of the present application and the first register in the processor in the related art point to different objects.

[0155] In some embodiments, in response to the update instruction, the chip resets the processor in the chip and, based on the first firmware segment pointed to by the first register in the reset processor, fetches instructions from the first firmware segment to execute the first firmware segment in the chip. In this way, after receiving the update instruction, the chip can execute the first firmware segment, thereby loading the second firmware segment through the first firmware segment and executing the second firmware segment.

[0156] In the firmware hot update method provided in an embodiment of the present application, the update instruction is a hot reset instruction. Upon receiving the hot reset instruction, the processor can be reset. After the processor is reset, the program counter in the processor points to the first firmware segment, enabling the successful execution of the first firmware segment in the chip even when the chip does not have a boot read-only memory. In some embodiments, because the first firmware segment can be used to load the second firmware segment, if the first firmware segment is successfully executed through the first register in this embodiment, the subsequent updated second firmware segment can also be successfully executed, ultimately achieving a hot update of the firmware.

[0157] In some embodiments, the chip includes a memory, which may include a first memory and a second memory. The first memory is a flash memory (FLASH), and the second memory is an instruction memory (IRAM). In some embodiments, the first memory is configured to store a first firmware segment and a second firmware segment in the firmware, and the first memory is further configured to store an updated second firmware segment.

[0158] In some embodiments, the firmware stored in the first memory cannot be directly executed, but the firmware stored in the second memory can be directly executed. Therefore, the firmware needs to be transferred from the first memory to the second memory and then executed.

[0159] In some embodiments, the firmware in the chip is first stored in a first memory, and a boot loader loads the firmware from the first memory into a second memory for execution. A first register in a processor in the chip points to a first firmware segment in the second memory, and after the processor is reset, the first firmware segment in the second memory can be executed.

[0160] In response to the update instruction, the chip runs the first firmware segment in the second memory. When the firmware has not yet been updated, the first firmware segment is used to load the second firmware segment to run the second firmware segment. After the second firmware segment is overwritten with the updated second firmware segment, the first firmware segment is used to load the updated second firmware segment to run the updated second firmware segment.

[0161] In some embodiments, the chip executes step 380 of loading the updated second firmware segment through the first firmware segment and running the updated second firmware segment, which can be achieved by loading the updated second firmware segment from the first memory to the second memory through the first firmware segment, and running the updated second firmware segment in the second memory.

[0162] In some embodiments, the updated second firmware segment is stored in the first memory. Since the first memory is a flash memory (FLASH), which is a non-volatile storage medium, the content stored in the flash memory (FLASH) can still be saved even if the chip is powered off. Therefore, the first firmware segment, the second firmware segment, and the updated second firmware segment are stored in the first memory. The first firmware segment, the second firmware segment, and the updated second firmware segment are not easily lost, thereby ensuring data security.

[0163] Furthermore, since the second memory is an instruction memory (IRAM), and the contents stored in the instruction memory (IRAM) disappear after the chip is powered off, this embodiment uses the first firmware segment to load the updated second firmware segment from the first memory into the second memory, thereby enabling the update and execution of the second firmware segment in the second memory. This ensures that the updated second firmware segment is acquired and executed, thereby improving the overall firmware update efficiency and effectiveness. Furthermore, after the chip is powered off, the firmware segment stored in the second memory can be cleared, saving storage space in the second memory and thereby improving the efficiency of the second memory.

[0164] In some embodiments, after the processor is reset, the first firmware segment in the second memory is executed. Since, after an external interrupt occurs, the processor only obtains the interrupt vector value from a fixed address in the second memory, which is the frontmost storage space in the second memory (where the interrupt vector corresponding to the first firmware segment is stored), to ensure normal operation of the chip, the updated second firmware segment can use a loop overwrite function to overwrite the first external interrupt vector of the first firmware segment with the second external interrupt vector, ensuring that the external interrupt function of the updated second firmware segment can normally respond to external interrupt requests.

[0165] In some embodiments, the updated second firmware segment is loaded from the first memory to the second memory through the first firmware segment, a loop overwriting function of the updated second firmware segment is executed, and the updated second firmware segment in the second memory is run.

[0166] In some embodiments, the loop overwrite function is used to successfully execute the updated second firmware segment in the second memory. In some embodiments, the loop overwrite function is used to use the second external interrupt vector of the updated second firmware segment to overwrite the first external interrupt vector of the first firmware segment.

[0167] In some embodiments, the first firmware segment loads the updated second firmware segment from the first memory to the second memory, and by executing the loop overwriting function of the updated second firmware segment, the second external interrupt vector of the updated second firmware segment overwrites the first external interrupt vector corresponding to the first firmware segment, and runs the updated second firmware segment in the second memory.

[0168] The first external interrupt vector is the external interrupt vector of the first firmware segment, the second external interrupt vector is the external interrupt vector of the updated second firmware segment, and the second external interrupt vector is used to indicate the external interrupt function position of the updated second firmware segment in the second memory.

[0169] In some embodiments, the external interrupt function of the second firmware segment is a subroutine primarily used to receive and process external interrupt requests from external devices. After processing the external interrupt request, the interrupted operation can be resumed. For example, an I / O operation, a status update, or a memory update can be performed. After the external interrupt function completes execution, the external interrupt request has been processed, and the previously interrupted operation can be resumed.

[0170] The first external interrupt vector is the external interrupt vector corresponding to the first firmware segment, and can be referred to as the external interrupt vector in the second portion 22 of the first firmware segment 20 in the left diagram (1) of FIG6 . The second external interrupt vector is the external interrupt vector corresponding to the updated second firmware segment, and can be referred to as the left diagram (1) of FIG6 . The second external interrupt vector is located in the second portion 42 of the updated second firmware segment 40.

[0171] Please refer to the right figure (2) in Figure 6. The external interrupt vector of the updated second firmware segment 40 can overwrite the external interrupt vector in the first firmware segment 20. At this time, the second part 22 of the first firmware segment 20 becomes the second part 22', so that the external interrupt function in the updated second firmware segment 40 can be executed, thereby normally operating the second firmware segment 40 in the second memory.

[0172] Based on the description of the interrupt vector in step 320, it can be seen that the external interrupt vector includes multiple elements, each of which is essentially an address that points to an instruction in the first firmware segment in the second memory. In some embodiments, a loop copy step can be performed, that is, a loop overwrite function can be used to overwrite the external interrupt vector in the first firmware segment with the second external interrupt vector in the updated second firmware segment to ensure that the external interrupt function in the updated second firmware segment can be correctly executed, thereby running the updated second firmware segment.

[0173] In some embodiments, the chip can load the updated second firmware segment from the first memory to the second memory in response to the first firmware segment, and overwrite the first external interrupt vector of the first firmware segment with the second external interrupt vector of the updated second firmware segment, so that in response to the external interrupt request, the external interrupt function of the updated second firmware segment can be executed.

[0174] In the embodiment of the present application, the first firmware segment can load the updated second firmware segment into the second memory for execution, and enable the firmware to be run continuously, thereby improving the operating efficiency of the firmware, avoiding operating freezes, and avoiding the operating delays that may occur before and after the second firmware segment is updated. By continuously looping the copying step, the second firmware segment can overwrite the external interrupt vector of the first firmware segment with its own external interrupt vector, enabling the external interrupt function to be successfully executed, thereby enabling the entire firmware to be run continuously, and improving the operating efficiency of the entire firmware.

[0175] In some embodiments, when the first firmware segment is re-run, the first external interrupt vector of the first firmware segment can be replaced with the second external interrupt vector of the updated second firmware segment. When the updated second firmware segment is run, the first external interrupt vector of the first firmware segment can be replaced with the second external interrupt vector of the updated second firmware segment. That is to say, the embodiment of the present application provides multiple opportunities for replacing external interrupt vectors, which can be set according to actual usage requirements.

[0176] In some embodiments, the external interrupt function of the first firmware segment can handle fewer external interrupt requests, and the external interrupt function of the updated second firmware segment can handle more external interrupt requests. By replacing the first external interrupt vector of the first firmware segment with the second external interrupt vector of the updated second firmware segment, the success rate of processing external interrupt requests can be improved.

[0177] In some embodiments, after the first external interrupt vector of the first firmware segment is replaced with the second external interrupt vector of the updated second firmware segment, an external interrupt request can be received, and then, based on the second external interrupt vector, an external interrupt function of the updated second firmware segment can be called to handle the external interrupt request. In this way, the success rate of handling external interrupt requests can be improved.

[0178] In some embodiments, step 360 shown in Figure 3 can be implemented in the following manner: in response to a firmware upgrade instruction, based on the address of the second firmware segment, the updated second firmware segment is written to the address of the second firmware segment in the first memory, thereby overwriting the second firmware segment with the updated second firmware segment.

[0179] The updated second firmware segment may be obtained from an external device. The firmware upgrade instruction is used to instruct to update the second firmware segment in the first memory, or to instruct to overwrite the second firmware segment in the first memory with the updated second firmware segment.

[0180] In some embodiments, in response to a firmware upgrade instruction, the first data can be obtained, and based on the address of the second firmware segment, the first data can be written into the first memory, and then the updated second firmware segment can be obtained. The first data is the data of the updated second firmware segment.

[0181] In some embodiments, the firmware upgrade instruction may be sent from a server to the chip. In some embodiments, the firmware upgrade instruction may be obtained before the update instruction. That is, the server first sends the firmware upgrade instruction at a first moment. In response to the firmware upgrade instruction, the chip may overwrite the second firmware segment in the first memory with the updated second firmware segment, thereby updating the second firmware segment in the first memory. The server sends the update instruction at a second moment. In response to the update instruction, the chip may re-run the first firmware segment in the second memory, thereby loading the updated second firmware segment through the first firmware segment and running the updated second firmware segment. The updated second firmware segment then runs and takes effect in the second memory, thereby updating the second firmware segment in the second memory.

[0182] The updated second firmware segment can be obtained from an external device, which can be a server containing the chip, or a server that issues firmware upgrade instructions to the chip, or a server that issues update instructions to the chip. The updated second firmware segment can be deployed on the external device by the developer. In other embodiments, the updated second firmware segment can also be deployed directly by the developer into the designated memory of the chip. In this way, the updated second firmware segment can be obtained in a variety of ways.

[0183] In some embodiments, the second firmware segment is updated by overwriting. In response to a firmware upgrade instruction, the chip can write the updated second firmware segment into the first memory based on the address of the second firmware segment, overwriting the second firmware segment with the updated second firmware segment. The updated second firmware segment has the same address as the unupdated second firmware segment. Furthermore, in response to the update instruction, the chip can execute the first firmware segment in the second memory. The first firmware segment can load the updated second firmware segment from the address of the unupdated second firmware segment in the first memory, thereby executing the updated second firmware segment.

[0184] In the embodiment of the present application, the updated second firmware segment is written into the first memory, which is a flash memory (FLASH). The flash memory (FLASH) is a non-volatile storage medium, so the data security of the updated second firmware segment can be guaranteed. In addition, the address of the updated second firmware segment is the same as that of the unupdated second firmware segment. Therefore, for the first firmware segment in this embodiment, the first firmware segment does not need to know whether the second firmware segment is the unupdated second firmware segment or the updated second firmware segment, nor does it need to modify or store the addresses required for loading the second firmware segment and the updated second firmware segment respectively, nor does it need to store other newly added addresses. The first firmware segment can still load the updated second firmware segment according to the address of its unupdated second firmware segment, which is conducive to improving data loading efficiency and facilitating the rapid implementation of hot firmware updates.

[0185] In some embodiments, the chip includes a boot loader and a memory, and the memory includes a first memory and a second memory. Among them, the boot loader is a program that runs before the operating system kernel runs. Through the boot loader, the software and hardware environment of the operating system can be adjusted to a suitable state to prepare for the final call of the operating system kernel. The first memory is a flash memory (FLASH) and the second memory is an instruction memory (IRAM). The firmware is stored in the first memory. After the chip is powered on, the firmware needs to be loaded from the first memory to the second memory for execution.

[0186] In some embodiments, step 320 shown in Figure 3 can be implemented by running a boot loader in response to a power-on operation, loading firmware data from a first memory into a second memory through the boot loader, and running the first firmware segment in the second memory.

[0187] The boot loader is configured to load firmware data, or the boot loader is configured to load firmware data from a first memory into a second memory, or the boot loader is used to load a first firmware segment and a second firmware segment from the first memory into the second memory, or the boot loader is configured to load a firmware header of the firmware, or the boot loader is configured to load a firmware header of the firmware and load the firmware data based on the firmware header.

[0188] In some embodiments, the chip further includes a first controller, which is a direct memory access controller. The boot loader can configure the direct memory access controller so that the direct memory access controller can load firmware data from the first memory to the second memory, and the boot loader can receive the firmware data. In other words, the boot loader's function is to configure the direct memory access controller, enable the direct memory access controller to load firmware data from the first memory to the second memory, and receive data loaded by the direct memory access controller (i.e., firmware data).

[0189] In some embodiments, the boot loader can load the firmware data from the first memory into the second memory via the direct memory access controller. When the firmware data loading is complete, the chip can execute the first firmware segment in the second memory. In other words, the boot loader can load the first firmware segment and the second firmware segment included in the firmware from the first memory into the second memory via the direct memory access controller, and can execute the first firmware segment in the second memory.

[0190] In the firmware hot update method provided in the embodiment of the present application, the firmware data is stored in a first memory, which is a flash memory (FLASH). Flash memory (FLASH) is a non-volatile storage medium, and thus the firmware data security can be guaranteed. By running a boot loader, the boot loader can load the firmware data from the first memory into the second memory via a direct memory access controller and run the first firmware segment, thereby ensuring that the firmware data is loaded into the second memory, thereby enabling the normal operation of the firmware.

[0191] In some embodiments, the firmware further includes a firmware header, which is used to instruct the boot loader in the chip to load the firmware data from the first memory. Among them, at least one of the firmware version field, the firmware page size field, the firmware page number field, the reserved field, and the check code field; wherein the firmware version field is used to indicate the version information of the firmware data; the firmware page size field is used to indicate the page size of the firmware data transferred from the first memory; the firmware page number field is used to indicate the number of pages of the firmware data transferred from the first memory; the product of the firmware page size field and the firmware page number field is used to characterize the firmware size; the check code field is used to check whether there is a loading error in the firmware data. Please refer to the above description and do not repeat it here.

[0192] In some embodiments, the boot loader loads the firmware data from the first memory into the second memory based on the firmware header, thereby executing the first firmware segment in the second memory. In some embodiments, the boot loader loads the firmware data from the first memory into the second memory based on the firmware header, thereby enabling the chip to execute the first firmware segment in the second memory.

[0193] In some embodiments, the boot loader may first load the firmware header. After the firmware header is loaded, the boot loader may load the first firmware segment and the second firmware segment included in the firmware from the first memory to the second memory based on the firmware header. In some embodiments, padding data between the first firmware segment and the second firmware segment included in the firmware may also be loaded from the first memory to the second memory.

[0194] In some embodiments, the firmware information stored in the firmware header can be parsed by a boot loader, and a direct memory access controller can be configured based on the firmware information through the boot loader. Then, the firmware data can be loaded from the first memory to the second memory through the direct memory access controller, and the first firmware segment can be run. In this way, the firmware data can be accurately loaded from the first memory to the second memory.

[0195] In some embodiments, when the chip is powered on and in a first state, data of the firmware header is read by the first controller and sent to the boot loader; the first state is used to represent loading the data of the firmware header;

[0196] After the firmware header data is loaded and the chip is in the second state, the boot loader loads the firmware data from the first memory to the second memory based on the firmware header data, and executes the first firmware segment in the second memory. The second state indicates that the firmware header data has been loaded. In this way, the chip can be controlled to different states according to different stages, thereby improving the accuracy of chip operation.

[0197] In some embodiments, when the chip is powered on and in the third state, the boot loader runs and loads firmware data from the first memory into the second memory via the boot loader. When the chip is in the fourth state, the first firmware segment in the second memory runs. The third state indicates that the firmware data has been loaded, and the fourth state indicates that the firmware data has been loaded. In this way, the chip can be controlled to different states according to different stages, thereby improving the accuracy of chip operation.

[0198] In some embodiments, after the firmware data has been loaded and the chip is in the fifth state, the firmware data is verified to obtain a verification result. The fifth state is used to indicate that the firmware data has been verified. If the verification result is successful, the chip state jumps from the fifth state to the sixth state. In this way, the chip can be controlled to be in different states according to different stages, thereby improving the accuracy of chip operation.

[0199] In some embodiments, in order to further ensure the accuracy of the firmware data. During the firmware loading process, the boot loader in the chip will simultaneously perform a check code calculation, and obtain a check code calculation result when the firmware loading is completed. Then, before running the first firmware segment in the second memory, the chip can also first verify the firmware data based on the check code calculation result and the check code in the check code field in the firmware header. When the verification passes, the first firmware segment included in the firmware in the second memory is run. In this way, when it is determined that the firmware data is complete, the first firmware segment included in the firmware can be run, which can not only further ensure the accuracy of the firmware data, but also ensure the success rate of the operation of the first firmware segment.

[0200] In some embodiments, in response to the completion of firmware loading, the chip obtains a check code calculation result calculated by the boot loader, where the check code calculation result is calculated during the period of loading the firmware data from the first memory to the second memory; the chip compares the check code calculation result with the check code in the check code field in the firmware header, and when the check code calculation result is the same as the check code in the check code field, it is determined that there is no loading error, and the first firmware segment of the firmware in the second memory is executed.

[0201] When the check code calculation result is different from the check code in the check code field, it is determined that there is a loading error. At this time, the chip reloads the firmware or loads the backup firmware until there is no loading error, and runs the first firmware segment of the firmware in the second memory.

[0202] In the firmware hot update method provided in an embodiment of the present application, the firmware further includes a firmware header, which can instruct a boot loader to load firmware data. The boot loader can be used to load the firmware from a first memory into a second memory for execution, thereby ensuring that the second memory obtains the firmware data, thereby enabling the normal operation of the firmware. In addition, before the firmware is executed, the firmware data can be verified, and the firmware can be executed only after it is determined that there are no loading errors in the data, thereby ensuring the accuracy of the data loading and thus ensuring the normal operation of the firmware.

[0203] In some embodiments, while the boot loader in the chip is loading the firmware data from the first memory to the second memory based on the firmware header, the processor of the chip is in a reset state. After the firmware has been loaded from the first memory, the chip de-resets the processor, placing the processor in a de-resistance state. At this point, the processor of the chip can fetch instructions and execute, thereby executing the first firmware segment. For details on instruction fetching and execution, please refer to the above description and will not be repeated here.

[0204] In some embodiments, a reset is used to restore the processor to its initial state. The reset state refers to the state in which the processor automatically resets after power-on. In the reset state, the processor performs at least one of the following actions: stopping instruction execution, clearing registers (corresponding to initialization registers), initializing the state machine, clearing caches and pipelines, and setting the startup address.

[0205] Among them, stopping the execution of instructions means that the processor stops the current activity and abandons the instruction being executed. Clearing registers means setting the first register, status register and other working registers to the initial state. Initializing the state machine means resetting the state machine and control logic inside the processor. Clearing the cache and pipeline means clearing the instruction and data cache and clearing the pipeline. Setting the startup address means that the first register is set to a predetermined startup address, which is generally a fixed location in the memory, such as the 0x0 address. In this embodiment, the 0x0 address is the address of the firmware header, so that the operation of the first firmware segment can be realized when the reset is released.

[0206] In some embodiments, a reset is used to enable the processor to begin instruction fetching. The reset state refers to a state in which the reset signal is released and the chip's processor begins normal execution. In this reset state, the processor begins executing instructions from a specified startup address (i.e., the first address), and the actions performed include at least one of the following: executing startup code, initializing memory and peripherals, and loading the operating system.

[0207] Executing boot code refers to the boot loader loading firmware or initializing hardware. Initializing memory and peripherals refers to setting up the stack, initializing the memory controller, or configuring peripheral interfaces. Loading the operating system refers to the boot loader loading the operating system from flash memory into RAM, if one exists.

[0208] In some embodiments, the boot loader loads the firmware data from the first memory into the second memory based on the firmware header, resets the processor, and runs the first firmware segment in the second memory; wherein, the reset is used to enable the processor to fetch instructions and run.

[0209] In some embodiments, the boot loader loads the firmware from the first memory into the second memory based on the firmware header, resets the processor, and executes the first firmware segment in the second memory. The first firmware segment is used to load the second firmware segment. The first firmware segment can automatically load the second firmware segment and jump to the second firmware segment to start execution, thereby enabling the subsequent execution of the second firmware segment in the second memory.

[0210] In some embodiments, the second firmware segment performs a cyclic copying step, where the third external interrupt vector of the second firmware segment may overwrite the first external interrupt vector of the first firmware segment to ensure that the external interrupt function in the second firmware segment can execute. For details, see the description of the second external interrupt vector overwriting the first external interrupt vector; this description is omitted here.

[0211] In an embodiment of the present application, after the firmware data is loaded from the first memory into the second memory, the processor can be reset, and the first firmware segment in the second memory can be run. Since the first firmware segment is used to load the second firmware segment, the subsequent running of the second firmware segment in the second memory can be successfully achieved by running the first firmware segment. Therefore, before the updated second firmware segment is overwritten, the normal operation of the non-updated firmware can be guaranteed.

[0212] The following is an overall description of the firmware hot update method of this embodiment with reference to a schematic diagram.

[0213] Firmware segmentation

[0214] The chip in this embodiment does not include a Boot ROM. The firmware in this embodiment is divided into two sections. Referring to FIG4 , the firmware includes a first firmware section 20 and a second firmware section 40. Optionally, the firmware also includes a firmware header 10 and data padding 30. The first firmware section 20 has the function of loading the second firmware section 40 from a first memory, which is a flash memory (FLASH). After loading the second firmware section 40, the first firmware section 20 automatically jumps to run the second firmware section 40. That is, in this embodiment, the first firmware section 20 is used to load the second firmware section 40, and the second firmware section 40 is used to implement the firmware configuration function. The first firmware section 20 and the second firmware section 40 are compiled, linked, and assembled separately to obtain a first file corresponding to the first firmware section 20 and a second file corresponding to the second firmware section 40. The first and second files are then merged into a third file, which is then burned into the first memory.

[0215] Firmware header

[0216] Referring to FIG5 , the firmware header in this embodiment is used to instruct the boot loader to load the firmware data. It has a fixed size of 32 bytes and is fixedly placed at address 0x0 of the first memory. It includes the following four fields:

[0217] 1. Checksum field (CRC_CHKSUM): Contains the CRC checksum corresponding to the firmware. The boot loader performs CRC calculations while loading the firmware data. When the transfer is complete, a checksum calculation result is calculated. By comparing the checksum calculation result with the CRC checksum in the checksum field, it can be determined whether there is a data loading error.

[0218] 2. Firmware version field (Boot FW Version): Contains the firmware version information.

[0219] 3. Firmware Page Size field (Boot FW Page Size): used to indicate the page size for data transfer from the first memory, in 16-byte units, with a maximum page size of 256 bytes. The size range is 16-256 bytes.

[0220] 4. Firmware page number field (Boot FW Page Len): used to indicate the number of pages for data transfer from the first memory. The upper limit of the firmware size needs to meet Boot FW Page Len*Boot FW Page Size*16B≤128KB.

[0221] Hot update of firmware

[0222] Figure 7 shows a schematic diagram of an exemplary firmware hot update method provided by this application. Taking the example of a chip located in a server and the firmware located in the chip, the chip includes a processor and memory, including FLASH and IRAM, and also includes a boot loader. In the initial state, the firmware is stored in the FLASH.

[0223] The firmware includes a first firmware segment 20 and a second firmware segment 40. The first firmware segment 20 is used to load the second firmware segment 40, which is used to implement the firmware's configuration functions. The firmware also includes padding data, which is displayed as the blank space between the first firmware segment 20 and the second firmware segment 40 as shown in Figure 7. The horizontal axis in Figure 7 represents time.

[0224] Before the first moment (corresponding to t0), the chip is powered on, and the boot loader begins to work. The boot loader first loads the firmware header. After the firmware header is loaded, the first firmware segment 20, padding data, and second firmware segment 40 corresponding to the firmware in the FLASH are loaded into the IRAM according to the firmware header. Next, the chip resets the processor, and the first register of the processor points to the first firmware segment in the IRAM. As a result, the processor fetches instructions and runs the first firmware segment 20 in the IRAM. The first firmware segment 20 will load the second firmware segment 40, and then the processor can jump to the second firmware segment 40 to run, thereby achieving normal operation of the unupdated firmware.

[0225] At a first moment, the server sends a firmware upgrade instruction to the chip, instructing it to update the second firmware segment 40 in the FLASH. After receiving the firmware upgrade instruction, the chip overwrites the second firmware segment 40 in the FLASH with the updated second firmware segment 40' between the first moment and the second moment (corresponding to t1). The address of the updated second firmware segment 40' is the same as that of the second firmware segment 40, thereby updating the unupdated second firmware segment 40 in the FLASH. Because the FLASH already stores the first firmware segment 20 and the updated second firmware segment 40', the firmware upgrade in the FLASH is achieved.

[0226] At the second moment, the server sends an update instruction to the chip, which can be a hot reset command. The hot reset instruction is used to instruct the update of the second firmware segment 40 in the IRAM. After receiving the hot reset instruction, the chip resets the processor, and the first register of the processor will point to the first firmware segment 20 in the IRAM. The processor then fetches instructions to re-run the first firmware segment 20. The first firmware segment 20 then loads the updated second firmware segment 40' from the FLASH into the IRAM to run the updated second firmware segment 40'. Through the above process, a hot update of the firmware in the IRAM can be achieved. Since the updated second firmware segment 40' in the IRAM is already running, the updated firmware is run.

[0227] In some embodiments, the second firmware segment 40 in both the FLASH and IRAM is updated to the updated second firmware segment 40', and the updated second firmware segment 40' is also executed and takes effect. This implements a hot update of the firmware in the FLASH and IRAM. During this update process, there is no need to restart the server.

[0228] In summary, the firmware hot update method provided in this embodiment can achieve at least the following beneficial effects:

[0229] 1. Time cost. Restarting a server typically takes more than 10 minutes. However, the above embodiment allows for a hot update of the firmware without restarting the server where the chip resides, and for the updated firmware to take effect. The firmware upgrade and effectiveness in this embodiment only takes about one minute, saving approximately 90% of the time, further reducing time costs and accelerating firmware upgrades.

[0230] 2. Business impact: Since the server where the chip is located does not need to be restarted, other services on the server are not affected by the chip firmware update, allowing other services on the entire server to continue operating normally, which can improve server utilization and operating efficiency.

[0231] 3. Hardware cost: The related art requires adding an additional PCIe driver card as a link between the server and the chip, and cooperating with the BMC to implement hot updates of the firmware. However, the chip of this embodiment can implement hot updates of the firmware without adding additional devices or equipment, thus saving costs.

[0232] FIG8 shows a block diagram of a firmware hot update device provided by an exemplary embodiment of the present application. The firmware hot update device 800 is configured to be executed by a chip, the chip including firmware, the firmware including a first firmware segment and a second firmware segment, the first firmware segment being used to load the second firmware segment, and the second firmware segment being used to implement the configuration function of the firmware; the firmware hot update device 800 includes:

[0233] An execution module 810 is configured to execute a first firmware segment of the firmware in response to a power-on operation on the chip;

[0234] The running module 810 is configured to load the second firmware segment through the first firmware segment and run the second firmware segment;

[0235] The processing module 820 is configured as a firmware upgrade instruction to update the data in the second firmware segment to obtain an updated second firmware segment;

[0236] The running module 810 is configured to re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

[0237] In some embodiments, the chip includes a processor; the execution module 810 is further configured to:

[0238] In response to the update instruction, the processor is reset and the first firmware segment is re-run.

[0239] In some embodiments, the processor includes a first register; the execution module 810 is further configured to:

[0240] In response to the update instruction, the processor is reset, and the first firmware segment is re-run based on the first firmware segment pointed to by the first register in the reset processor.

[0241] In some embodiments, the execution module 810 is further configured to: reset the processor in response to the update instruction;

[0242] During the process of resetting the processor, the first register is set to an initial value; wherein the initial value of the first register points to the first address of the first firmware segment.

[0243] In some embodiments, the running module 810 is further configured to: re-run the first firmware segment based on the first address of the first firmware segment.

[0244] In some embodiments, the chip includes a memory, the memory includes a first memory and a second memory, the updated second firmware segment is stored in the first memory, and the running first firmware segment is located in the second memory;

[0245] The operation module 810 is further configured to:

[0246] The updated second firmware segment is loaded from the first memory into the second memory through the first firmware segment, and the updated second firmware segment in the second memory is executed.

[0247] In some embodiments, the operation module 810 is further configured to:

[0248] The updated second firmware segment is loaded from the first memory into the second memory through the first firmware segment, and a loop overwriting function of the updated second firmware segment is executed to run the updated second firmware segment in the second memory.

[0249] In some embodiments, the operation module 810 is further configured to:

[0250] The updated second firmware segment is loaded from the first memory into the second memory through the first firmware segment, and the second external interrupt vector of the updated second firmware segment is overwritten with the first external interrupt vector of the first firmware segment by executing the loop overwriting function of the updated second firmware segment, and the updated second firmware segment in the second memory is run.

[0251] In some embodiments, the first firmware segment includes a first external interrupt vector, the updated second firmware segment includes a second external interrupt vector, and the second external interrupt vector points to an external interrupt function of the updated second firmware segment;

[0252] The running module 810 is further configured to: after running the updated second firmware segment, replace the first external interrupt vector of the first firmware segment with the second external interrupt vector of the second firmware segment;

[0253] An external interrupt request is received, and based on the second external interrupt vector, an external interrupt function of the second firmware segment is called to process the external interrupt request.

[0254] In some embodiments, the chip includes a memory, the memory includes a first memory, the second firmware segment is stored in the first memory, and the running first firmware segment is located in the second memory; the processing module 820 is further configured to:

[0255] In response to the firmware upgrade instruction, first data is acquired, and based on the address of the second firmware segment, the first data is written into the first memory to obtain an updated second firmware segment.

[0256] In some embodiments, the chip includes a boot loader and a memory, the memory includes a first memory and a second memory, and the firmware is stored in the first memory; the execution module 810 is configured to:

[0257] In response to a power-on operation on the chip, the boot loader is executed, and the firmware data is loaded from the first memory to the second memory through the boot loader, and the first firmware segment in the second memory is executed.

[0258] In some embodiments, the firmware further includes a firmware header, and the firmware header is used to instruct the boot loader to load the firmware data from the first memory; the execution module 810 is further configured to:

[0259] The boot loader loads the firmware data from the first memory into the second memory based on the firmware header, and runs the first firmware segment in the second memory.

[0260] In some embodiments, the firmware header includes: at least one of a firmware version field, a firmware page size field, a firmware page number field, a reserved field, and a checksum field;

[0261] Among them, the firmware version field is used to indicate the version information of the firmware data; the firmware page size field is used to indicate the page size of the firmware data transferred from the first memory; the firmware page number field is used to indicate the number of pages of the firmware data transferred from the first memory; the product of the firmware page size field and the firmware page number field is used to represent the firmware size; the check code field is used to check whether there is a loading error in the firmware data.

[0262] In some embodiments, the chip includes a processor; the execution module 810 is further configured to:

[0263] The boot loader loads the firmware data from the first memory into the second memory based on the firmware header, and the processor is reset to run the first firmware segment in the second memory.

[0264] In some embodiments, the chip further includes a first controller, and the operation module 810 is further configured to: when the chip is powered on and the chip is in a first state, read the data of the firmware header through the first controller and send the data of the firmware header to the boot loader; the first state is used to indicate that the data of the firmware header is loaded;

[0265] When the firmware header data is loaded and the chip is in the second state, the boot loader loads the firmware data from the first memory to the second memory based on the firmware header data, and runs the first firmware segment in the second memory. The second state is used to indicate that the firmware header data has been loaded.

[0266] In some embodiments, the running module 810 is further configured to: when the chip is powered on and the chip is in the third state, run the boot loader, and load the firmware data from the first memory to the second memory through the boot loader;

[0267] When the chip is in a fourth state, executing the first firmware segment in the second memory;

[0268] The third state is used to indicate that the data of the firmware has been loaded, and the fourth state is used to indicate that the loading of the data of the firmware has been completed.

[0269] In some embodiments, when the firmware data is loaded and the chip is in the fifth state, the firmware data is verified to obtain a verification result; wherein the fifth state is used to represent the verification of the firmware data;

[0270] When the verification result is successful, the state of the chip jumps from the fifth state to the sixth state.

[0271] It should be noted that the definitions of the embodiments of the one or more firmware hot update devices 800 provided above can be found in the definitions of the firmware hot update method described above and will not be repeated here. The modules of the above-mentioned device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor of the electronic device in the form of hardware, or can be stored in the memory of the electronic device in the form of software so that the processor can call and execute the corresponding operations of each module.

[0272] In an exemplary embodiment, the present application provides a chip for implementing hot update of firmware, wherein the chip includes at least one of a programmable logic circuit and a program instruction. When the chip runs on an electronic device, it is configured to implement the hot update method of firmware provided in the above method embodiment.

[0273] In some embodiments, the chip includes firmware, the firmware including a first firmware segment and a second firmware segment;

[0274] The chip is configured to execute a first firmware segment of the firmware in response to a power-on operation on the chip;

[0275] The chip is configured to load the second firmware segment through the first firmware segment and run the second firmware segment;

[0276] The chip is configured to update the data in the second firmware segment in response to the firmware upgrade instruction to obtain an updated second firmware segment;

[0277] The chip is configured to re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

[0278] For example, FIG9 shows a block diagram of a chip structure provided by an exemplary embodiment of the present application. The chip 140 includes a processor 144 and a memory 146. The firmware includes a first firmware segment and a second firmware segment. The first firmware segment is used to load the second firmware segment, and the second firmware segment is used to implement the configuration function of the firmware.

[0279] The processor 144 is configured to execute the first firmware segment in the memory 146 in response to a power-on operation on the chip;

[0280] The processor 144 is configured to load the second firmware segment through the first firmware segment and run the second firmware segment;

[0281] The processor 144 is configured to update the data in the second firmware segment in response to the firmware upgrade instruction to obtain an updated second firmware segment;

[0282] The processor 144 is configured to re-run the first firmware segment in the memory 146 , load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

[0283] In some embodiments, the processor 144 is configured to reset the processor 144 and re-execute the first firmware segment in the memory 146 in response to the update instruction.

[0284] In some embodiments, the processor 144 includes a first register; the processor 144 is configured to reset the processor 144 in response to the update instruction, and re-run the first firmware segment based on the first register in the reset processor pointing to the first firmware segment.

[0285] In some embodiments, the processor 144 is configured to reset the processor 144 in response to an update instruction, and in the process of resetting the processor 144, set the first register to an initial value; wherein the initial value of the first register points to the first address of the first firmware segment.

[0286] In some embodiments, the processor 144 is configured to re-execute the first firmware segment based on the first address of the first firmware segment.

[0287] In some embodiments, the processor 144 is configured to replace the first external interrupt vector of the first firmware segment with the second external interrupt vector of the updated second firmware segment; receive an external interrupt request, and based on the second external interrupt vector, call the external interrupt function of the updated second firmware segment to handle the external interrupt request.

[0288] In some embodiments, Figure 10 shows a block diagram of a chip structure provided by an exemplary embodiment of the present application. Chip 140 includes memory 146, which includes a first memory 1461 and a second memory 1462. The updated second firmware segment is stored in first memory 1461, and the running first firmware segment is located in second memory 1462. The updated second firmware segment is loaded from first memory 1461 to second memory 1462 via the first firmware segment, and chip 140 can execute the updated second firmware segment in second memory 1462.

[0289] In some embodiments, the first firmware segment loads the updated second firmware segment from the first memory 1461 to the second memory 1462 , executes the loop overwrite function of the updated second firmware segment, and runs the updated second firmware segment in the second memory 1462 .

[0290] In some embodiments, the first firmware segment loads the updated second firmware segment from the first memory 1461 to the second memory 1462, and by executing the loop overwrite function of the updated second firmware segment, the second external interrupt vector of the updated second firmware segment overwrites the first external interrupt vector of the first firmware segment, and runs the updated second firmware segment in the second memory 1462.

[0291] In some embodiments, the chip 140 includes a memory 146, the memory 146 includes a first memory 1461 and a second memory 1462, the second firmware segment is stored in the first memory 1461, and the running first firmware segment is located in the second memory 1462; the processor 144 is configured to respond to a firmware upgrade instruction, obtain the first data, and write the first data into the first memory 1461 based on the address of the second firmware segment to obtain an updated second firmware segment.

[0292] In some embodiments, the chip 140 includes a boot loader 1481 and a memory 146, the memory 146 includes a first memory 1461 and a second memory 1462, and the firmware is stored in the first memory 1461; the processor 144 is configured to run the boot loader 1481 in response to a power-on operation; and load the firmware data from the first memory 1461 to the second memory 1462 through the boot loader 1481, and the chip 140 can run the first firmware segment in the second memory 1462.

[0293] In some embodiments, the firmware also includes a firmware header, which is used to instruct the boot loader 1481 to load firmware data from the first memory 1461; the boot loader 1481 loads the firmware data from the first memory 1461 to the second memory 1462 based on the firmware header, and the chip 140 can run the first firmware segment in the second memory 1462.

[0294] In some embodiments, the firmware header includes: at least one of: a firmware version field, a firmware page size field, a firmware page number field, a reserved field, and a check code field; wherein the firmware version field is used to indicate the version information of the firmware data; the firmware page size field is used to indicate the page size of the firmware data transferred from the first memory; the firmware page number field is used to indicate the number of pages of the firmware data transferred from the first memory; the product of the firmware page size field and the firmware page number field is used to characterize the firmware size; the check code field is used to check whether there is a loading error in the firmware data.

[0295] In some embodiments, the chip 140 includes a processor 144 ; the boot loader 1481 loads the firmware from the first memory 1461 to the second memory 1462 based on the firmware header, resets the processor 144 , and runs the first firmware segment in the second memory 1462 .

[0296] It should be noted that the definitions of the embodiments of the one or more chips 140 for implementing firmware hot updates provided above can be found in the definitions of the firmware hot update method above, and will not be repeated here. Each module of the above chip can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor of the electronic device in the form of hardware, or can be stored in the memory of the electronic device in the form of software to facilitate the processor to call and execute the corresponding operations of each module.

[0297] In some embodiments, please continue to refer to FIG. 10 , and FIG. 11 shows a schematic diagram of a chip provided by an exemplary embodiment of the present application. Optionally, the chip further includes a controller 148 , which is connected to the processor 144 and memory 146 in the chip 140 via a bus 142 . The memory 146 includes a first memory 1461 and a second memory 1462 . The first memory 1461 is a flash memory (FLASH), and the second memory 1462 is an instruction memory (IRAM). The controller 148 is also referred to as a hardware controller.

[0298] It should be noted that the controller 148 can be located within the chip 140 or implemented as another hardware control device. In the following embodiments, the controller 148 is located within the chip 140 as an example. For example, the controller 148 may optionally include: a boot loader 1481, a controller configuration module 1482, a direct memory access module (DMA module) 1483, and a read / write controller 1484. The direct memory access module (DMA module) 1483 is a direct memory access controller.

[0299] The boot loader 1481 is configured to start the processor 144 (for example, Cortex-M3). That is, after the chip is powered on and reset, the boot loader 1481 automatically moves the instructions run by the processor 144 to the second memory 1462 through the hardware state machine. The boot loader 1481 initiates a control signal to release the reset of the processor 144, and the processor 144 fetches instructions and executes them, entering the working state.

[0300] The controller configuration module 1482 is configured to configure the controller 148 after the processor 144 works normally, for example: configure the DMA module 1483, configure the read and write mode of the first memory 1461 (FLASH), the firmware page size, the number of firmware pages, the firmware data read and write address and other configuration information.

[0301] The DMA module 1483 is controlled by the processor 144 and the boot loader 1481 and is configured to transfer the firmware data in the read / write controller 1484 to the second memory 1462, or to transfer the firmware data in the chip 140 to the read / write controller 1484. The DMA module 1483 is a general DMA module and will not be described in detail here.

[0302] Read / write controller 1484 may be a serial peripheral interface (SPI FLASH) read / write controller 1484, configured to implement standard SPI memory data reading and writing. It is driven by DMA module 1483. Specifically, when DMA module 1483 initiates a data read / write request, it generates a read / write operation and an operation response for first memory 1461 (FLASH). This read / write controller 1484 is a general-purpose SPI FLASH read / write controller and is not further described here.

[0303] In some embodiments, the boot loader 1481 executes the hardware state machine and implements firmware data loading based on each state of the hardware state machine and the jump logic between states. In this embodiment, the hardware state machine starts working when the chip is powered on, and the boot loader 1481 can load the firmware data from the first memory 1461 to the second memory 1462 based on the various states of the hardware state machine, so that the subsequent processor can run the first firmware segment and the second firmware segment of the firmware in the second memory 1462. At this time, the state of the hardware state machine will no longer jump. It can be understood that when the chip receives a firmware upgrade instruction to overwrite the second firmware segment in the first memory 1461, and when the chip receives an update instruction to run the first firmware segment and the updated second firmware segment in the second memory 1462, the state of the hardware state machine is the same as at this time.

[0304] Figure 12 shows a schematic diagram of a hardware state machine according to an exemplary embodiment of the present application. The states of the hardware state machine include at least one of the following: idle state 210, firmware header loading state 220 (corresponding to the first state), firmware header loading complete state 230 (corresponding to the second state), firmware loading state 240 (corresponding to the third state), firmware verification state 250 (corresponding to the fifth state), firmware verification complete state 260 (corresponding to the sixth state), and firmware verification failure state 270.

[0305] Idle state (IDLE state) 210: is an initial state. After the chip is powered on and reset, the hardware state machine automatically jumps to the firmware header loading state (HD_LOAD state) 220. It should be noted that when the chip is in debug mode, it will not jump to the firmware header loading state (HD_LOAD state) 220.

[0306] Firmware Header Loading State (HD_LOAD State) 220: When the hardware state machine transitions from Idle State 210 to this Firmware Header Loading State 220, DMA module 1483 is configured and triggered to transfer the firmware header (boot header). DMA module 1483 begins driving read / write controller 1484 to read the firmware header data from first memory 1461. Boot loader 1481 receives the firmware header data transferred by DMA module 1482. Exemplarily, DMA module 1483 is configured as follows: the transfer address in first memory 1461 is 0x0, and the transferred data size is 32 bytes.

[0307] Firmware Header Loading Completed State (HD_DONE State) 230: When DMA module 1483 completes loading the firmware header data, it returns a completion signal to boot loader 1481, causing the hardware state machine to jump from firmware header loading state 220 to firmware header loading completed state 230. In firmware header loading completed state 230, boot loader 1481 parses the firmware header data and then jumps to firmware loading state 240.

[0308] Firmware loading state (FW_LOAD state) 240 : When the hardware state machine jumps to the firmware loading state 240 , the DMA module 1483 is triggered to move the firmware. At this time, the DMA module 1483 drives the controller 148 to read the firmware data from the first memory 1461 .

[0309] Firmware Verification State (FW_VER State) 250: When the DMA module 1483 returns a completion signal to the boot loader 1481, the hardware state machine jumps to the firmware verification state 250. At this time, the boot loader 1481 determines whether the firmware verification has passed based on the CRC check code calculation result returned by the DMA module 1483.

[0310] Firmware Verification Completed State (FW_DONE State) 260: When the verification result is successful, the hardware state machine jumps to the Firmware Verification Completed State 260 and remains there. The boot finish (boot_finish) level signal notifies the clock reset generation module (CRG) to release the reset signal of the processor 144, thereby resetting the processor 144.

[0311] Firmware verification failure state (FW_FAIL state) 270: When the verification result is verification failure, the hardware state machine jumps to the firmware verification failure state 270. If this is the first time the firmware is loaded, the hardware state machine jumps back to the firmware loading state 240 and instructs the DMA module 1483 to load the backup firmware and perform another firmware verification after loading.

[0312] In some embodiments, the steps performed by chip 140 can be briefly described as follows:

[0313] When the chip is powered on and the hardware state machine is in the firmware verification completion state, the processor runs the first firmware segment in the chip through the controller. The first firmware segment is used to load the second firmware segment to run the second firmware segment. At this time, the hardware state machine is in the firmware verification completion state and no longer jumps; when the chip receives a firmware upgrade instruction, the processor overwrites the second firmware segment with an updated second firmware segment through the controller, and the address of the updated second firmware segment is the same as the address of the second firmware segment; when the chip receives an update instruction, the processor re-runs the first firmware segment; when the first firmware segment loads the updated second firmware segment, the processor runs the updated second firmware segment, and the update instruction is used to instruct the re-running of the first firmware segment.

[0314] In some embodiments, when the chip receives an update instruction, the processor is configured to, in response to the update instruction, reset the processor via the controller to control the processor to re-execute the first firmware segment in the memory. That is, the controller notifies the clock reset generation module (CRG) module via a boot_finish level signal to release the processor's reset signal to control the processor to reset and re-execute the first firmware segment.

[0315] In some embodiments, when the chip receives an update instruction, the controller notifies the CRG module through the boot_finish level signal to release the processor's reset signal to control the processor to be reset. The processor then fetches instructions from the first firmware segment based on the first firmware segment pointed to by the register in the reset processor to run the first firmware segment in the chip; wherein, the first register in the reset processor is used to point to the first firmware segment.

[0316] In some embodiments, the processor controls the DMA module, thereby driving the read-write memory to read and write data, so that the first firmware segment loads the updated second firmware segment from the first memory to the second memory; then, the processor can run the updated second firmware segment in the second memory.

[0317] In some embodiments, the processor controls the DMA module, and then drives the read-write memory to read and write data, so that the first firmware segment loads the updated second firmware segment from the first memory to the second memory; because after an external interrupt occurs, the processor will only obtain the value of the interrupt vector from the fixed address of the second memory (that is, the frontmost space of the second memory), therefore, the updated second firmware segment performs a loop copy (Loop Copy) step to overwrite the first external interrupt vector of the first firmware segment with the second external interrupt vector to ensure that the external interrupt function of the updated second firmware segment can be executed correctly, so that the processor can ensure that the external interrupt function of the updated second firmware segment can respond to the interrupt signal normally to run the updated second firmware segment in the second memory.

[0318] In some embodiments, the processor will overwrite the first external interrupt vector corresponding to the first firmware segment with the second external interrupt vector corresponding to the updated second firmware segment to ensure that the external interrupt function of the updated second firmware segment can respond to the interrupt signal normally and run the updated second firmware segment in the second memory; wherein, the first external interrupt vector is the external interrupt vector corresponding to the first firmware segment, the second external interrupt vector is the external interrupt vector corresponding to the updated second firmware segment, and the second external interrupt vector is used to indicate the location of the external interrupt function of the updated second firmware segment in the second memory.

[0319] In some embodiments, the processor is configured to respond to the firmware upgrade instruction and, based on the address of the second firmware segment, write the updated second firmware segment into the first memory through the controller to overwrite the second firmware segment with the updated second firmware segment.

[0320] In some embodiments, when the chip receives a firmware upgrade instruction, the DMA module in the controller can initiate a data read and write request. The controller then controls the DMA module to drive the read-write memory to write the updated second firmware segment into the first memory based on the address of the second firmware segment, so as to overwrite the second firmware segment with the updated second firmware segment.

[0321] In some embodiments, when the chip is powered on and the hardware state machine is in the firmware loading state, the boot loader is run to load the firmware from the first memory into the second memory; when the hardware state machine is in the firmware verification completion state, the first firmware segment in the second memory is run.

[0322] In some embodiments, when the chip is powered on and the hardware state machine is in the firmware loading state, the controller can control the running of the boot loader, and control the DMA module through the boot loader to drive the read-write controller to load the firmware from the first memory to the second memory; and when the hardware state machine is in the firmware verification completion state, the processor runs the first firmware segment in the second memory.

[0323] In some embodiments, when the chip is powered on and the hardware state machine is in the firmware header loading state, the data of the firmware header is read and sent to the boot loader; when the firmware header loading is completed and the hardware state machine is in the firmware header loading completion state, the boot loader loads the firmware from the first memory to the second memory based on the firmware header, and runs the first firmware segment in the second memory.

[0324] In some embodiments, the firmware also includes a firmware header, which is used to instruct the boot loader to load firmware data from the first memory; when the chip is powered on and the hardware state machine is in the firmware header loading state, the controller controls the DMA module through the boot loader to drive the read-write controller to read the firmware header data and send it to the boot loader; when the firmware header loading is completed and the hardware state machine is in the firmware header loading completion state, the controller controls the DMA module through the boot loader to drive the read-write controller to load the firmware from the first memory to the second memory based on the firmware header, and the processor runs the first firmware segment in the second memory.

[0325] Optionally, when the firmware loading is completed and the hardware state machine is in the firmware verification state, the firmware is verified to obtain a verification result; when the verification result is a successful verification, the hardware state machine jumps to the firmware verification completion state. Exemplarily, when the firmware loading is completed and the hardware state machine is in the firmware verification state, the controller verifies the firmware through the boot loader to obtain a verification result. When the verification result is a successful verification, the hardware state machine jumps to the firmware verification completion state, and when it jumps to the firmware verification completion state, the state of the hardware state machine no longer jumps. When the verification result is a verification failure, the hardware state machine jumps to the firmware verification failure state. When this firmware loading is the first loading, the hardware state machine is transferred from the firmware verification failure state back to the firmware loading state, and the controller instructs the DMA module to drive the read-write controller to load the backup firmware, and then performs the firmware verification again after loading.

[0326] In some embodiments, when the firmware loading is completed, the processor is reset so that the processor runs the first firmware segment in the second memory, so that when the first firmware segment loads the second firmware segment, the processor can continue to run the second firmware segment in the second memory.

[0327] In the above embodiments, the chip executes corresponding steps and realizes corresponding functions through the controller, hardware state machine, processor, and memory. In addition, it should be noted that the structures of the chip, controller, processor, and memory provided in Figures 9, 10, and 11 in the above embodiments do not constitute a limitation on the chip, controller, processor, and memory. In actual applications, the chip, controller, processor, and memory may include more or fewer components than shown in the figure, or combine certain components, or adopt different component arrangements. It is understandable that the various states of the above-mentioned hardware state machine are only examples. In actual applications, more or fewer states can be used to represent them, and each state can also use a different name. When the chip, controller, processor, memory, and hardware state machine can achieve the same, similar, or similar effects as those in the above embodiments, they are all within the scope of protection of the embodiments of the present application.

[0328] An embodiment of the present application also provides an electronic device, which includes the above-mentioned chip for implementing hot update of firmware, and the chip includes: a processor and a memory, the memory is configured to store computer-executable instructions or computer programs, and the processor is configured to execute the computer-executable instructions or computer programs stored in the memory to implement the hot update method of firmware provided by the above-mentioned method embodiments.

[0329] In some embodiments, FIG13 is a block diagram of an electronic device provided by an exemplary embodiment of the present application. In some embodiments, the electronic device 1000 is a server 1000. The server 1000 includes a chip, which includes: a processor 1001 and a memory 1002.

[0330] The processor 1001 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and the like. The processor 1001 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 1001 may also include a main processor and a coprocessor. The main processor is a processor configured to process data in an awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor configured to process data in a standby state. In some embodiments, the processor 1001 may be integrated with a graphics processing unit (GPU), and the GPU is configured to be responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1001 may also include an artificial intelligence (AI) processor, which is configured to process computing operations related to machine learning.

[0331] The memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1002 is configured to store at least one instruction, which is configured to be executed by the processor 1001 to implement the hot update method of the firmware provided in the method embodiment of the present application.

[0332] In some embodiments, the server 1000 may further optionally include an input interface 1003 and an output interface 1004. The processor 1001, the memory 1002, and the input interface 1003 and the output interface 1004 may be connected via a bus or a signal line. Each peripheral device may be connected to the input interface 1003 and the output interface 1004 via a bus, a signal line, or a circuit board. The input interface 1003 and the output interface 1004 may be configured to connect at least one peripheral device related to input / output (I / O) to the processor 1001 and the memory 1002. In some embodiments, the processor 1001, the memory 1002, and the input interface 1003 and the output interface 1004 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1001, the memory 1002, and the input interface 1003 and the output interface 1004 may be implemented on a separate chip or circuit board, which is not limited in the embodiments of the present application.

[0333] Those skilled in the art will understand that the structure shown in FIG13 does not constitute a limitation on the electronic device 1000 , and may include more or fewer components than shown, or combine certain components, or adopt a different component arrangement.

[0334] The present application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions are executed by a processor, the hot update method of the firmware provided in the above method embodiment is implemented.

[0335] The present application provides a computer program product or a computer program, including computer executable instructions or a computer program. When the computer executable instructions or the computer program are executed by a processor, the hot update method of the firmware provided by the above method embodiment is implemented.

[0336] In some embodiments, the computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the processor of the electronic device to load and execute the instructions to implement the firmware hot update method provided in the above method embodiment. The electronic device may also be referred to as a computer device.

[0337] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0338] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0339] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0340] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for hot updating firmware, the method being executed by a chip, the chip including firmware, the firmware including a first firmware segment and a second firmware segment; the method comprising: In response to a power-on operation on the chip, executing a first firmware segment of the firmware; loading the second firmware segment through the first firmware segment and running the second firmware segment; In response to the firmware upgrade instruction, updating the data in the second firmware segment to obtain an updated second firmware segment; The first firmware segment is re-run, the updated second firmware segment is loaded through the first firmware segment, and the updated second firmware segment is run.

2. The method according to claim 1, wherein The chip includes a processor; The re-running of the first firmware segment includes: In response to the update instruction, the processor is reset and the first firmware segment is re-run.

3. The method according to claim 2, wherein: The processor includes a first register; The step of resetting the processor and re-running the first firmware segment in response to the update instruction includes: In response to the update instruction, the processor is reset, and the first firmware segment is re-run based on the first firmware segment pointed to by the first register in the reset processor.

4. The method according to claim 3, wherein: The step of resetting the processor in response to the update instruction includes: Resetting the processor in response to the update instruction; During the process of resetting the processor, the first register is set to an initial value; wherein the initial value of the first register points to the first address of the first firmware segment.

5. The method according to claim 4, wherein The re-running of the first firmware segment includes: Based on the first address of the first firmware segment, the first firmware segment is re-executed.

6. The method according to any one of claims 1 to 5, wherein: The chip includes a memory, the memory includes a first memory and a second memory, the updated second firmware segment is stored in the first memory, and the running first firmware segment is located in the second memory; The step of loading the updated second firmware segment through the first firmware segment and running the updated second firmware segment includes: The updated second firmware segment is loaded from the first memory into the second memory through the first firmware segment, and the updated second firmware segment in the second memory is executed.

7. The method according to claim 6, wherein: The step of loading the updated second firmware segment from the first memory to the second memory through the first firmware segment, and running the updated second firmware segment in the second memory, includes: The updated second firmware segment is loaded from the first memory into the second memory through the first firmware segment, a loop overwriting function of the updated second firmware segment is executed, and the updated second firmware segment in the second memory is run.

8. The method according to claim 7, wherein: The step of loading the updated second firmware segment from the first memory to the second memory through the first firmware segment, executing a loop overwriting function of the updated second firmware segment, and running the updated second firmware segment in the second memory includes: The updated second firmware segment is loaded from the first memory into the second memory through the first firmware segment, and the second external interrupt vector of the updated second firmware segment is overwritten with the first external interrupt vector of the first firmware segment by executing the loop overwriting function of the updated second firmware segment, and the updated second firmware segment in the second memory is run.

9. The method according to any one of claims 1 to 8, wherein: The first firmware segment includes a first external interrupt vector, the updated second firmware segment includes a second external interrupt vector, and the second external interrupt vector points to an external interrupt function of the updated second firmware segment; After running the updated second firmware segment, the method further includes: Replacing the first external interrupt vector of the first firmware segment with the second external interrupt vector of the updated second firmware segment; An external interrupt request is received, and based on the second external interrupt vector, an external interrupt function of the updated second firmware segment is called to process the external interrupt request.

10. The method according to any one of claims 1 to 9, wherein: The chip includes a memory, the memory includes a first memory, the second firmware segment is stored in the first memory, and the running first firmware segment is located in the second memory; The updating of the data in the second firmware segment in response to the firmware upgrade instruction to obtain an updated second firmware segment includes: In response to the firmware upgrade instruction, first data is acquired, and based on the address of the second firmware segment, the first data is written into the first memory to obtain an updated second firmware segment.

11. The method according to any one of claims 1 to 10, wherein: The chip includes a boot loader and a memory, the memory includes a first memory and a second memory, and the data of the firmware is stored in the first memory; In response to a power-on operation on the chip, running the first firmware segment of the firmware includes: In response to a power-on operation on the chip, the boot loader is executed, and the firmware data is loaded from the first memory to the second memory through the boot loader, and the first firmware segment in the second memory is executed.

12. The method according to claim 11, wherein The firmware further includes a firmware header, and the firmware header is used to instruct the boot loader to load data of the firmware from the first memory; The step of loading the firmware data from the first memory to the second memory by the boot loader and running the first firmware segment in the second memory includes: The boot loader loads the firmware data from the first memory into the second memory based on the firmware header, and runs the first firmware segment in the second memory.

13. The method according to claim 12, wherein: The firmware header includes: at least one of a firmware version field, a firmware page size field, a firmware page number field, a reserved field, and a check code field; Among them, the firmware version field is used to indicate the version information of the firmware data; the firmware page size field is used to indicate the page size of the firmware data transferred from the first memory; the firmware page number field is used to indicate the number of pages of the firmware data transferred from the first memory; the product of the firmware page size field and the firmware page number field is used to represent the firmware size; the check code field is used to check whether there is a loading error in the firmware data.

14. The method according to any one of claims 12 to 13, wherein: The chip includes a processor; The step of loading the firmware data from the first memory to the second memory based on the firmware header by the boot loader and running the first firmware segment in the second memory includes: The boot loader loads the firmware data from the first memory into the second memory based on the firmware header, resets the processor, and runs the first firmware segment in the second memory.

15. The method according to claim 14, wherein The chip further includes a first controller, and the boot loader loads the firmware data from the first memory to the second memory based on the firmware header, resets the processor, and runs the first firmware segment in the second memory, including: When the chip is powered on and in a first state, the first controller reads the data of the firmware header and sends the data of the firmware header to the boot loader; the first state is used to indicate that the data of the firmware header is loaded; When the firmware header data is loaded and the chip is in the second state, the boot loader loads the firmware data from the first memory to the second memory based on the firmware header data, and runs the first firmware segment in the second memory. The second state is used to indicate that the firmware header data has been loaded.

16. The method according to any one of claims 11 to 15, wherein: In response to a power-on operation on the chip, running the boot loader, loading the firmware data from the first memory to the second memory through the boot loader, and running the first firmware segment in the second memory, includes: When the chip is powered on and is in a third state, running the boot loader and loading the firmware data from the first memory to the second memory through the boot loader; When the chip is in a fourth state, executing the first firmware segment in the second memory; The third state is used to indicate that the data of the firmware has been loaded, and the fourth state is used to indicate that the loading of the data of the firmware has been completed.

17. The method according to claim 16, wherein The method further comprises: When the firmware data is loaded and the chip is in the fifth state, verifying the firmware data to obtain a verification result; wherein the fifth state is used to represent the verification of the firmware data; When the verification result is successful, the state of the chip jumps from the fifth state to the sixth state.

18. A firmware hot update device, the device being executed by a chip, the chip including firmware, the firmware including a first firmware segment and a second firmware segment; the device comprising: an execution module configured to execute a first firmware segment of the firmware in response to a power-on operation on the chip; The running module is configured to load the second firmware segment through the first firmware segment and run the second firmware segment; a processing module configured to update the data in the second firmware segment in response to a firmware upgrade instruction to obtain an updated second firmware segment; The running module is configured to re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

19. A chip, comprising firmware, wherein the firmware comprises a first firmware segment and a second firmware segment; The chip is configured to execute the first firmware segment of the firmware in response to a power-on operation on the chip; The chip is configured to load the second firmware segment through the first firmware segment and run the second firmware segment; The chip is configured to update the data in the second firmware segment in response to a firmware upgrade instruction to obtain an updated second firmware segment; The chip is configured to re-run the first firmware segment, load the updated second firmware segment through the first firmware segment, and run the updated second firmware segment.

20. The chip according to claim 19, wherein The chip further includes a processor, a memory, and a controller, wherein the controller is connected to the processor, and the controller is connected to the memory; The processor is configured to, in response to an update instruction, reset the processor via the controller to re-execute the first firmware segment in the memory.

21. The chip according to any one of claims 19 to 20, wherein: The processor includes a first register; The processor is configured to, in response to the update instruction, reset the processor through the controller, fetch instructions from the first firmware segment based on the first register in the reset processor pointing to the first firmware segment, and re-run the first firmware segment.

22. An electronic device, comprising a chip, the chip comprising a processor and a memory, the memory being configured to store computer-executable instructions or computer programs; The processor is configured to implement the firmware hot update method according to any one of claims 1 to 17 when executing the computer executable instructions or computer program stored in the memory.

23. A computer-readable storage medium storing computer-executable instructions or a computer program, wherein when the computer-executable instructions are executed by a processor, the method for hot updating firmware according to any one of claims 1 to 17 is implemented.

24. A computer program product, comprising computer executable instructions or a computer program, wherein when the computer executable instructions or the computer program are executed by a processor, the method for hot updating firmware according to any one of claims 1 to 17 is implemented.

Images