Firmware burning method, device, equipment and medium

Abstract

The invention discloses a firmware burning method, device, equipment and medium, which are applied to the technical field of firmware burning, and the firmware burning method comprises the following steps: determining a weight offset corresponding to a firmware fragment based on a weight value corresponding to the firmware fragment, the weight value being determined based on a fragment type of the firmware fragment; determining a corresponding target address of the firmware fragment in a memory mapping area of the programmable logic device based on the serial number and the weight offset of the firmware fragment; loading firmware fragments to the memory mapping area through a hardware debugging interface according to the target address; and reading the firmware fragments from the memory mapping area, and burning the firmware fragments to a flash memory of the programmable logic device. Therefore, the firmware burning efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware burning, and in particular to a firmware burning method, device, equipment and medium. Background Art

[0002] The current mainstream FPGA firmware burning technology generally uses the UART asynchronous serial communication interface, whose transmission rate is directly proportional to the FPGA's main frequency. When the FPGA main frequency is reduced to a low frequency due to design limitations, the UART baud rate is strictly limited to the order of 4800bps, severely limiting the firmware burning efficiency.

[0003] Therefore, how to improve the efficiency of firmware burning is a problem that those skilled in the art need to solve. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a firmware burning method, device, equipment and medium to improve the efficiency of firmware burning. The specific solution is as follows:

[0005] In a first aspect, the present application discloses a firmware burning method, comprising:

[0006] Determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice, wherein the weight value is determined based on a slice type of the firmware slice;

[0007] Determine a target address corresponding to the firmware slice in a memory mapping area of ​​a programmable logic device based on a serial number and a weight offset of the firmware slice;

[0008] According to the target address, the firmware fragment is loaded into the memory mapping area through the hardware debugging interface;

[0009] The firmware slices are read from the memory mapping area and burned into the flash memory of the programmable logic device.

[0010] Optionally, determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice includes:

[0011] A weight offset corresponding to the firmware slice is determined based on the weight value of the firmware slice and a preset maximum weight value.

[0012] Optionally, determining a target address corresponding to the firmware fragment in a memory mapping area of ​​a programmable logic device based on the serial number and weight offset of the firmware fragment includes:

[0013] A target address corresponding to the firmware slice in the memory mapping area of ​​the programmable logic device is determined based on a base address of a target available memory area in the memory mapping area of ​​the programmable logic device, a serial number of the firmware slice, and a weight offset.

[0014] Optionally, the target available memory area includes a hot zone, a warm zone, and a cold zone, and reading a firmware fragment from the memory mapping area and burning it into a flash memory of the programmable logic device includes:

[0015] Reading the firmware slice from the hot zone and burning it into the flash memory of the programmable logic device;

[0016] The method further includes: loading the firmware slice from the warm zone to the hot zone, and loading the firmware slice from the cold zone to the warm zone.

[0017] Optionally, reading the firmware slice from the hot zone and burning it into the flash memory of the programmable logic device includes:

[0018] If the burning addresses of the multiple firmware slices in the hot zone in the flash memory are continuous, the multiple firmware slices are continuously read from the hot zone and burned into the flash memory of the programmable logic device.

[0019] Optionally, loading the firmware fragment into the memory mapping area according to the target address and through the hardware debugging interface includes:

[0020] The firmware segments are loaded into the memory mapping area according to the target address through a debugging tool and a hardware debugging interface.

[0021] Optionally, also include:

[0022] Detecting a burning flag, wherein the burning flag is configured to be a valid value or an invalid value, the valid value indicating that firmware burning is being performed, and the invalid value indicating that the firmware is started normally;

[0023] When the burning flag is a valid value, a step of determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice is triggered.

[0024] In a second aspect, the present application provides a firmware burning device, comprising:

[0025] A weight offset determination module, configured to determine a weight offset corresponding to a firmware slice based on a weight value corresponding to the firmware slice, wherein the weight value is determined based on a slice type of the firmware slice;

[0026] A target address determination module, configured to determine a target address corresponding to the firmware fragment in the memory mapping area of ​​the programmable logic device based on the serial number and weight offset of the firmware fragment;

[0027] A firmware slice loading module, configured to load the firmware slice into the memory mapping area according to the target address and through a hardware debugging interface;

[0028] The firmware slice burning module is used to read the firmware slice from the memory mapping area and burn it into the flash memory of the programmable logic device.

[0029] In a third aspect, the present application provides an electronic device, comprising:

[0030] memory for storing computer programs;

[0031] A processor is used to execute the computer program to implement the steps of the aforementioned firmware burning method.

[0032] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the aforementioned firmware burning method are implemented.

[0033] In a fifth aspect, the present application provides a computer program product, comprising a computer program / instruction, which implements the steps of the aforementioned disclosed firmware burning method when executed by a processor.

[0034] It can be seen from the above scheme that the present application provides a firmware burning method, including: determining the weight offset corresponding to the firmware slice based on the weight value corresponding to the firmware slice, wherein the weight value is determined based on the slice type of the firmware slice; determining the target address corresponding to the firmware slice in the memory mapping area of ​​the programmable logic device based on the serial number of the firmware slice and the weight offset; according to the target address, and through the hardware debugging interface, loading the firmware slice into the memory mapping area; reading the firmware slice from the memory mapping area, and burning it to the flash memory of the programmable logic device.

[0035] It can be seen that the beneficial effects of the present application are: loading the firmware slice into the memory mapping area of ​​the programmable logic device through the hardware debugging interface, realizing direct mapping of the programmable logic device memory, avoiding the baud rate limitation caused by using the UART serial port, and effectively improving the firmware loading efficiency. When loading the firmware slice into the memory mapping area of ​​the programmable logic device, the target address is determined based on the serial number of the firmware slice and the slice type. While considering the priority of the firmware slice by type, the adjacent burned slices are guaranteed to be stored continuously in the memory as much as possible, thereby reducing the addressing time during burning, thereby improving the firmware burning efficiency.

[0036] Correspondingly, the firmware burning device, equipment and medium provided by this application also have the above technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0038] Figure 1 A flowchart of a firmware burning method provided in an embodiment of the present application;

[0039] Figure 2 A schematic diagram of firmware burning provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of the interaction flow between TRACE32 and FPGA provided in an embodiment of the present application;

[0041] Figure 4 A firmware burning flow chart provided in an embodiment of the present application;

[0042] Figure 5 A sharding data structure diagram provided in an embodiment of the present application;

[0043] Figure 6 A schematic diagram of the structure of a firmware burning device provided in an embodiment of the present application;

[0044] Figure 7 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0046] The terms "including" and "having," as used in the present description and accompanying drawings, and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements and may include steps or elements that are not listed.

[0047] First, the terms involved in this application are explained:

[0048] UART: Universal Asynchronous Receiver / Transmitter, also known as universal asynchronous receiver / transmitter, is a serial, asynchronous, full-duplex communication protocol widely used in the embedded field. It is often used as a communication tool between the host computer and the SoC in embedded development.

[0049] Flash memory, also known as flash mermory, is a non-volatile memory (data is not lost even when power is off). Flash is often used in embedded systems to store system boot firmware.

[0050] FPGA: Field Programmable Gate Array, is a semi-custom circuit in the field of application-specific integrated circuits. It not only solves the shortcomings of custom circuits, but also overcomes the disadvantage of the limited number of gate circuits of original programmable devices.

[0051] RAM: Static Random-Access Memory, a storage device.

[0052] The current mainstream FPGA firmware flashing technology generally uses the UART asynchronous serial communication interface, whose transmission rate is directly linearly proportional to the FPGA's main frequency. When the FPGA's main frequency is reduced to a low frequency range due to design limitations, the UART baud rate is strictly limited to around 4800bps. Taking a 1.4MB firmware as an example, in actual projects, the flashing time exceeds 90 minutes, taking into account factors such as data frame encapsulation overhead (start bit, stop bit, parity bit), protocol retransmission mechanisms, and channel interference. Compared to synchronous serial interfaces (such as SPI and I²C), UART's simplex asynchronous transmission mode cannot leverage the FPGA's parallel processing capabilities, resulting in significant efficiency shortcomings in low-frequency scenarios. Furthermore, traditional baud rate division algorithms cannot exceed the physical layer rate limit, severely restricting firmware update efficiency. The traditional UART protocol relies on an interrupt-driven mechanism for data transmission, requiring at least two interrupts per byte (receive completion and transmit completion). In low-frequency FPGAs, interrupt response latency increases significantly: at a baud rate of 4800bps, the byte transmission interval is 2.08ms, and interrupt processing accounts for as much as 48% of the total processing time (1μs / 2.08ms), resulting in low CPU utilization. More seriously, frequent interrupts disrupt the pipeline prefetch mechanism, causing the instruction cache hit rate to drop by over 40%, creating a vicious cycle of "inefficient transmission, high load, and performance degradation." This problem is particularly prominent in systems that must respond to external events in real time, potentially causing critical task scheduling failures.

[0053] Existing pre-chip testing must be performed on an FPGA. In low-frequency FPGA scenarios, UART-based firmware burning solutions face severe efficiency constraints. For a 1.4MB firmware, the actual download, burning, and verification time totals 90 minutes, making this unacceptable for testers who routinely need to change test versions of the firmware. First, analyzing the rate-limiting bottlenecks of existing offline firmware burning methods, we found that firmware transmission time accounts for approximately 64%, verification time accounts for approximately 31%, and burning time accounts for approximately 5%. To achieve overall speed improvements, this application optimizes the firmware transmission process and employs a hardware interface replacement mechanism: by directly mapping the TRACE32 tool to FPGA memory, it bypasses the baud rate limitations of the UART interface and effectively improves firmware download efficiency. Furthermore, this application utilizes a pre-ordered caching technology for shard burning sequences: by predicting the access order during burning, the physical addresses of shards are proactively adjusted when they are stored in RAM, ensuring that adjacent shards are stored contiguously in memory. This reduces addressing time during burning and takes priority into account.

[0054] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0055] Next, a firmware burning method provided by an embodiment of the present invention is described in detail. Figure 1 A flowchart of a firmware burning method provided by an embodiment of the present invention includes:

[0056] Step S11: determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice, wherein the weight value is determined based on a slice type of the firmware slice.

[0057] In the embodiment of the present application, the firmware slice is the slice data with the burned firmware. Different slice types can correspond to different weight values. The slice type can be boot code, function module, and configuration module. For example, the weight value corresponding to the boot code is 0x3000, the weight value corresponding to the function module is 0x2000, and the weight value corresponding to the configuration module is 0x1000. The priority of the slice burning can be adjusted by the weight value.

[0058] In an embodiment of the present application, a weight offset corresponding to a firmware slice may be determined based on the weight value of the firmware slice and a preset maximum weight value.

[0059] The weight offset is determined based on the weight: weight offset = (maximum weight - current weight) * 64. This way, the firmware shard with the larger weight value is assigned a smaller weight offset, placing the target address of the firmware shard as close to the front as possible and allowing it to be burned first.

[0060] Step S12: determining a target address corresponding to the firmware slice in the memory mapping area of ​​the programmable logic device based on the serial number and weight offset of the firmware slice.

[0061] The serial number of the firmware slice represents the original order generated when the firmware is compiled. The programmable logic device may be an FPGA.

[0062] The embodiment of the present application can determine the target address corresponding to the firmware slice in the memory mapping area of ​​the programmable logic device based on the base address of the target available memory area in the memory mapping area of ​​the programmable logic device, the serial number of the firmware slice, and the weight offset.

[0063] In an optional implementation, the target address = base address + serial number * 4096 + weight offset. Furthermore, each firmware shard has a corresponding flash memory burn address. Using the serial number to determine the target address ensures that consecutive shards are stored consecutively in the memory mapper. Combined with the weights corresponding to the types, this ensures that important firmware shards are burned first. The serial number and weight ensure both continuity and correctness, resulting in a better burn effect.

[0064] Step S13: According to the target address, the firmware fragment is loaded into the memory mapping area through the hardware debugging interface.

[0065] In the embodiment of the present application, the firmware fragment can be loaded into the memory mapping area according to the target address through the debugging tool and the hardware debugging interface.

[0066] The debugging tool can be TRACE32. As firmware debugging code, TRACE32 can directly load binary files into memory. The hardware debugging interface can be a JTAG (Joint Test Action Group, an international standard test protocol) or SWD (Serial Wire Debug) hardware interface.

[0067] The target available memory area includes a hot zone, a warm zone, and a cold zone. The hot zone is used to store the firmware to be burned. Each time a slice is burned, it is taken from the hot zone. For example, the hot zone can store 10 slices. The warm zone is used to store the next 50 slices. The cold zone is used to store the remaining slices to be queued. After loading a firmware slice into the memory-mapped partition, if there is no slice in the hot zone, it can be loaded from the warm zone, and the warm zone can be loaded from the cold zone.

[0068] Step S14: reading the firmware slice from the memory mapping area and burning it into the flash memory of the programmable logic device.

[0069] In an embodiment of the present application, the firmware slice can be read from the hot zone and burned into the flash memory of the programmable logic device; the method further includes: loading the firmware slice from the warm zone to the hot zone, and loading the firmware slice from the cold zone to the warm zone.

[0070] In an optional embodiment, each time a firmware slice is burned into the flash memory, a firmware slice is loaded from the warm zone to the hot zone. In another optional embodiment, when the number of firmware slices in the hot zone falls below a preset threshold, a slice is loaded from the warm zone.

[0071] Furthermore, if the flash memory programming addresses of multiple firmware shards in the hot zone are consecutive, the multiple firmware shards are read consecutively from the hot zone and programmed into the flash memory of the programmable logic device. Specifically, when the programming addresses corresponding to the shards are consecutive, DMA (Direct Memory Access) batch transfer is automatically enabled for programming.

[0072] Furthermore, the embodiment of the present application can detect a burning flag, wherein the burning flag is configured as a valid value or an invalid value, the valid value indicates that the firmware is burned, and the invalid value indicates a normal startup; when the burning flag is a valid value, it triggers a step of determining the weight offset corresponding to the firmware slice based on the weight value corresponding to the firmware slice.

[0073] In the embodiment of the present application, a debugging tool can be used to detect the burn flag bit. The firmware program of the programmable logic device is used to burn the firmware slice. Using the existing firmware code can reduce the additional maintenance cost.

[0074] Furthermore, when the firmware slice is burned into the flash memory of the programmable logic device, the firmware slice is read back from the flash memory, and the read-back firmware slice is verified using a preset verification algorithm, and the verification result is fed back to the debugging tool, so that the accuracy of the burned data can be guaranteed.

[0075] It can be seen that the embodiment of the present application loads the firmware slice into the memory mapping area of ​​the programmable logic device through the hardware debugging interface, realizes direct mapping of the programmable logic device memory, avoids the baud rate limitation caused by the use of the UART serial port, and effectively improves the firmware loading efficiency. When the firmware slice is loaded into the memory mapping area of ​​the programmable logic device, the target address is determined based on the serial number of the firmware slice and the slice type. While considering the priority of the firmware slice by type, the adjacent burned slices are ensured to be stored continuously in the memory as much as possible, thereby reducing the addressing time during burning, thereby improving the firmware burning efficiency.

[0076] Furthermore, in the low-frequency FPGA scenario, the CPU main frequency is reduced to 1.25M, and the serial port baud rate is limited to 4800baud. To bypass the existing hardware frequency limitation, in the embodiment of the present application, the host computer system uses the TRACE32 debugging tool to replace the traditional serial port through the JTAG / SWD hardware interface, thereby breaking through the baud rate limitation. Figure 2 As shown, Figure 2 This is a schematic diagram of firmware burning provided by an embodiment of the present application. The bootloader flag can be checked using the TRACE32 debugging tool. If valid, the firmware fragment is loaded into the FPGA's memory map area and burned by the FPGA burning engine, which is an FPGA firmware. If the flag is invalid, the system boots normally. Loading the firmware fragment can be done directly into the FPGA's memory map area using the JTAG / SWD hardware interface.

[0077] Existing FPGA resources can be used for programming, enabling self-programming of firmware based on existing firmware code. Using existing firmware code reduces additional maintenance costs. This also applies to hardware resources. TRACE32, used for debugging existing firmware code, offers the ability to directly load bin files into memory. This effectively utilizes existing hardware resources, replacing traditional serial ports with JTAG / SWD hardware interfaces, significantly improving firmware download efficiency.

[0078] Furthermore, the interaction process between TRACE32 and FPGA is as follows Figure 3 As shown, Figure 3The present invention provides a flow chart of interaction between TRACE32 and FPGA. It is roughly divided into four stages: (1) Link building stage. This stage mainly completes the link building between TRACE32 and FPGA firmware. TRACE32 determines whether to download the firmware based on the bootloader flag (i.e., the burning flag). If it is valid, the firmware is burned and the firmware download stage is entered. If it is invalid, it indicates a normal startup. (2) Firmware download stage: This stage completes the loading of the slice data and is loaded to the FPGA target address by TRACE32. The firmware header can be the header data of the firmware slice, and the data block is the data of the firmware slice. (3) Firmware burning stage: The target FPGA firmware program is used to complete the burning of the slice data. (4) Verification stage: The flash data is read back and verified using a verification algorithm to ensure the correctness of the data. If the verification passes, it is fed back to the host computer TRACE to start the download and burning of the next slice data until all data is burned. Firmware download and firmware burning can be performed simultaneously. Using TRACE32 for loading can significantly increase the physical layer speed: the JTAG protocol uses a synchronous clock signal (TCK) for full-duplex transmission, while the SWD protocol uses two-wire serial communication (SWDIO / SWCLK), achieving equivalent transmission efficiency at the same main frequency while using less hardware resources. Using direct memory mapping technology, TRACE32 writes the firmware binary data directly into the FPGA's SRAM mapping area (i.e., the memory mapping area) using the Data.LOAD.Binary instruction, bypassing the traditional serial port's byte-by-byte data transfer process and achieving zero-copy transmission. The measured loading time for a 1.4MB firmware was reduced from 90 minutes via the serial port to 3.2 minutes, an efficiency improvement of approximately 28 times.

[0079] The present application provides a fragment burning sequence pre-ordering cache technology that proactively adjusts the physical address of the fragments when they are stored in RAM by pre-judging the access order during burning, so that adjacent fragments are stored continuously in the memory, thereby reducing the addressing time during burning. And it takes into account the priority of the fragments. Figure 4 As shown, Figure 4 A firmware burning flowchart provided in an embodiment of the present application.

[0080] (1) Segment preprocessing: Header tag analysis: such as Figure 5 As shown, Figure 5 A diagram of the slice data structure provided by an embodiment of the present application. Each slice header contains 4 bytes of programming sequence information. The base sequence number is 2 bytes, representing the original sequence generated during firmware compilation; the dynamic weight value (2 bytes) is determined by the slice type (boot code = 0x3000, function module = 0x2000, configuration module = 0x1000).

[0081] Dynamic sorting algorithm: used to calculate the storage location in real time when the fragments are loaded into RAM or flash memory mapping area. The calculation formula is as follows

[0082] Target address = base address + sequence number * 4096 + weight offset.

[0083] The base address represents the starting address of the currently available memory block. Weight offset = (maximum weight - current weight) * 64. Figure 4 The process of calculating the dynamic weight value is to calculate the weight offset.

[0084] (2) Intelligent cache allocation: After completing the priority prediction of the current burning slice, the firmware to be burned is stored according to the calculated target address. The memory mapping area includes three levels of storage areas, which are divided into three types of areas: hot zone: stores the 10 slices to be burned; warm zone: stores the subsequent 50 slices; cold zone: stores other slices to be arranged; dynamic adjustment rules: hot zone management: in an optional implementation method, always ensure that 10 slices to be burned are stored continuously; warm zone optimization: every time a slice is burned, a slice is migrated from the warm zone to the end of the hot zone; cold zone activation: when the warm zone is insufficient, fill it from small to large according to the target address.

[0085] (3) Accelerated burning mechanism: To speed up burning, the continuous burning mode and pre-loading reminder mechanism are enabled.

[0086] Continuous programming mode: When it is detected that the hot zone shard addresses are continuous, DMA batch transfer is automatically enabled. The maximum continuous programming length of a single time can reach 40KB (10 shards, which is the total number of shards in the maximum hot zone).

[0087] Preload reminder: When the number of remaining shards in a hot zone is ≤ 3, preloading of the temperature zone shards is triggered. The preloading process is performed in parallel with the current burning operation. In other words, hot zone management does not always need to maintain 10 shards. Loading can be performed when the number of remaining shards is less than the preset threshold.

[0088] This pre-ordering strategy shifts the sequential requirements of the programming phase to the cache stage, improving the firmware programming rate without increasing hardware costs. This approach is particularly suitable for R&D and testing before chip tape-out, and can meet the debugging needs of frequently changing firmware versions.

[0089] The embodiment of the present application can use the hardware interface replacement mechanism in the low-frequency FPGA scenario, that is, use TRACE32 to complete the firmware loading, and cooperate with the self-developed firmware burning protocol to improve the firmware offline burning rate. The shard burning sequence pre-sorting cache technology is used to predict the existing firmware shard priority, and cooperate with DMA to complete continuous transmission, thereby improving the firmware burning rate. In this way, from the perspective of hardware equipment, high-speed TRACE32 is used to replace the low-speed UART peripheral, breaking through the rate improvement bottleneck of the existing firmware offline burning technology, and cooperating with the self-developed firmware offline burning protocol to greatly improve the firmware burning rate. In the existing low-frequency FPGA environment, the burning rate is increased by about 28 times. From the perspective of firmware caching technology, with the burning sequence pre-sorting cache technology as the core, predicting the shard priority, and applying DMA to complete continuous transmission can also greatly improve the firmware burning rate.

[0090] The present invention provides a method for offline firmware burning based on TRACE32 hardware acceleration. Although the embodiments of the present invention are described above, the above description and definitions are only for the purpose of facilitating understanding of the embodiments of the present invention and are not intended to limit the present invention. Any modifications and variations made without departing from the spirit and scope of the present invention, especially the self-developed TRACE32-based offline firmware burning protocol and the pre-ordered caching technology for the slice burning sequence, are within the scope of protection of the present invention.

[0091] See also Figure 6 As shown, the embodiment of the present application provides a firmware burning device, comprising:

[0092] A weight offset determination module 61 is configured to determine a weight offset corresponding to a firmware slice based on a weight value corresponding to the firmware slice, wherein the weight value is determined based on a slice type of the firmware slice;

[0093] A target address determination module 62 is configured to determine a target address corresponding to the firmware fragment in the memory mapping area of ​​the programmable logic device based on the serial number and weight offset of the firmware fragment;

[0094] A firmware slice loading module 63 is configured to load the firmware slice into the memory mapping area according to the target address and through the hardware debugging interface;

[0095] The firmware slice burning module 64 is used to read the firmware slice from the memory mapping area and burn it into the flash memory of the programmable logic device.

[0096] In an optional implementation, the weight offset determination module 61 is specifically configured to determine a weight offset corresponding to a firmware slice based on the weight value of the firmware slice and a preset maximum weight value.

[0097] In an optional embodiment, the target address determination module 62 is specifically used to determine the target address corresponding to the firmware fragment in the memory mapping area of ​​the programmable logic device based on the base address of the target available memory area in the memory mapping area of ​​the programmable logic device, the serial number of the firmware fragment, and the weight offset.

[0098] The target available memory area includes a hot zone, a warm zone, and a cold zone.

[0099] In an optional implementation, the firmware slice burning module 64 may be specifically configured to read the firmware slice from the hot zone and burn it into the flash memory of the programmable logic device.

[0100] The device is further configured to: load the firmware slice from the warm zone to the hot zone, and load the firmware slice from the cold zone to the warm zone.

[0101] In an optional embodiment, the firmware slice burning module 64 can be specifically used to continuously read multiple firmware slices from the hot zone and burn them into the flash memory of the programmable logic device if the burning addresses of multiple firmware slices in the hot zone in the flash memory are continuous.

[0102] In an optional implementation, the firmware slice loading module 63 may be specifically configured to load the firmware slice into the memory mapping area according to the target address through a debugging tool and a hardware debugging interface.

[0103] In an optional embodiment, the device is further used to:

[0104] Detecting a burning flag, wherein the burning flag is configured to be a valid value or an invalid value, the valid value indicating that firmware burning is being performed, and the invalid value indicating that the firmware is started normally;

[0105] When the burning flag is a valid value, a step of determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice is triggered.

[0106] It can be seen that the embodiment of the present application loads the firmware slice into the memory mapping area of ​​the programmable logic device through the hardware debugging interface, realizes direct mapping of the programmable logic device memory, avoids the baud rate limitation caused by the use of the UART serial port, and effectively improves the firmware loading efficiency. When the firmware slice is loaded into the memory mapping area of ​​the programmable logic device, the target address is determined based on the serial number of the firmware slice and the slice type. While considering the priority of the firmware slice by type, the adjacent burned slices are ensured to be stored continuously in the memory as much as possible, thereby reducing the addressing time during burning, thereby improving the firmware burning efficiency.

[0107] Figure 6 The description of the features in the corresponding embodiment can be found in Figure 1 The relevant descriptions of the corresponding embodiments will not be repeated here one by one.

[0108] Figure 7 A structural diagram of an electronic device provided by an embodiment of the present invention, such as Figure 7 As shown, the electronic device includes: a memory 60 for storing computer programs;

[0109] The processor 61 is configured to implement the steps of the firmware burning method in the above embodiment when executing a computer program.

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

[0111] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601, wherein, after the computer program is loaded and executed by the processor 61, it can implement the relevant steps of the firmware burning method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include but is not limited to firmware data, etc.

[0112] In some embodiments, the electronic device may further include a display screen 62 , an input / output interface 63 , a communication interface 64 , a power supply 65 , and a communication bus 66 .

[0113] In this embodiment, when the processor executes the computer program stored in the memory, it can specifically implement the following steps: determine the weight offset corresponding to the firmware slice based on the weight value corresponding to the firmware slice, wherein the weight value is determined based on the slice type of the firmware slice; determine the target address corresponding to the firmware slice in the memory mapping area of ​​the programmable logic device based on the serial number of the firmware slice and the weight offset; load the firmware slice into the memory mapping area according to the target address and through the hardware debugging interface; read the firmware slice from the memory mapping area and burn it to the flash memory of the programmable logic device.

[0114] In this embodiment, when the processor executes the computer program stored in the memory, the following steps may be specifically implemented: determining a weight offset corresponding to the firmware slice based on the weight value of the firmware slice and a preset maximum weight value.

[0115] In this embodiment, when the processor executes the computer program stored in the memory, the processor may specifically implement the following steps: determining a target address corresponding to the firmware fragment in the memory mapping area of ​​the programmable logic device based on a base address of a target available memory area in the memory mapping area of ​​the programmable logic device, a serial number of the firmware fragment, and a weight offset. The target available memory area includes a hot zone, a warm zone, and a cold zone.

[0116] In this embodiment, when the processor executes the computer program stored in the memory, the following steps can be specifically implemented: reading the firmware slice from the hot zone and burning it to the flash memory of the programmable logic device; loading the firmware slice from the warm zone to the hot zone, and loading the firmware slice from the cold zone to the warm zone.

[0117] In this embodiment, when the processor executes the computer program stored in the memory, the following steps can be specifically implemented: if the burning addresses of multiple firmware fragments in the hot zone in the flash memory are continuous, then the multiple firmware fragments are continuously read from the hot zone and burned to the flash memory of the programmable logic device.

[0118] In this embodiment, when the processor executes the computer program stored in the memory, the following steps may be specifically implemented: loading the firmware fragment into the memory mapping area according to the target address through a debugging tool and through a hardware debugging interface.

[0119] In this embodiment, when the processor executes the computer program stored in the memory, the following steps can be specifically implemented: detecting a burning flag, wherein the burning flag is used to be configured as a valid value or an invalid value, the valid value indicates that the firmware is burned, and the invalid value indicates a normal startup; when the burning flag is a valid value, a step of determining the weight offset corresponding to the firmware slice based on the weight value corresponding to the firmware slice is triggered.

[0120] It can be seen that the embodiment of the present application loads the firmware slice into the memory mapping area of ​​the programmable logic device through the hardware debugging interface, realizes direct mapping of the programmable logic device memory, avoids the baud rate limitation caused by the use of the UART serial port, and effectively improves the firmware loading efficiency. When the firmware slice is loaded into the memory mapping area of ​​the programmable logic device, the target address is determined based on the serial number of the firmware slice and the slice type. While considering the priority of the firmware slice by type, the adjacent burned slices are ensured to be stored continuously in the memory as much as possible, thereby reducing the addressing time during burning, thereby improving the firmware burning efficiency.

[0121] Those skilled in the art will understand that Figure 7 The structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown in the figure.

[0122] It is understood that if the firmware burning method in the above-mentioned embodiment is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and performs all or part of the steps of the various embodiments of the method of the present invention. The aforementioned storage medium includes: USB flash drives, mobile hard drives, read-only memories (ROM), random access memories (RAM), electrically erasable programmable ROMs, registers, hard drives, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media that can store program code.

[0123] Based on this, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned firmware burning method are implemented.

[0124] A computer program product provided in an embodiment of the present application is introduced below. The computer program product described below can be referenced with other embodiments described herein.

[0125] A computer program product includes a computer program / instruction, which implements the steps of the aforementioned firmware burning method when executed by a processor.

[0126] The above describes in detail the firmware burning method, apparatus, device, and medium provided by the embodiments of the present invention. The various embodiments are described in a progressive manner throughout this specification, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between the various embodiments can be referenced for reference. Since the apparatus disclosed in the embodiments corresponds to the method disclosed in the embodiments, the description is relatively simple. For relevant details, refer to the method description.

[0127] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0128] The above describes in detail the firmware burning method, device, equipment, and medium provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only intended to help understand the method and core concept of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from the principles of the present invention, and such improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A firmware burning method, characterized in that: include: Determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice, wherein the weight value is determined based on a slice type of the firmware slice; Determine a target address corresponding to the firmware slice in a memory mapping area of ​​a programmable logic device based on a serial number and a weight offset of the firmware slice; According to the target address, the firmware fragment is loaded into the memory mapping area through the hardware debugging interface; The firmware slices are read from the memory mapping area and burned into the flash memory of the programmable logic device.

2. The firmware burning method according to claim 1, wherein: Determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice includes: A weight offset corresponding to the firmware slice is determined based on the weight value of the firmware slice and a preset maximum weight value.

3. The firmware burning method according to claim 1, wherein: Determining a target address corresponding to the firmware slice in a memory mapping area of ​​a programmable logic device based on the serial number and the weight offset of the firmware slice includes: A target address corresponding to the firmware slice in the memory mapping area of ​​the programmable logic device is determined based on a base address of a target available memory area in the memory mapping area of ​​the programmable logic device, a serial number of the firmware slice, and a weight offset.

4. The firmware burning method according to claim 3, wherein: The target available memory area includes a hot zone, a warm zone, and a cold zone. The firmware fragment is read from the memory mapping area and burned into the flash memory of the programmable logic device, including: Reading the firmware slice from the hot zone and burning it into the flash memory of the programmable logic device; The method further includes: loading the firmware slice from the warm zone to the hot zone, and loading the firmware slice from the cold zone to the warm zone.

5. The firmware burning method according to claim 4, wherein: Reading the firmware slice from the hot zone and burning it into the flash memory of the programmable logic device includes: If the burning addresses of the multiple firmware slices in the hot zone in the flash memory are continuous, the multiple firmware slices are continuously read from the hot zone and burned into the flash memory of the programmable logic device.

6. The firmware burning method according to claim 1, wherein: According to the target address, the firmware fragment is loaded into the memory mapping area through the hardware debugging interface, including: The firmware segments are loaded into the memory mapping area according to the target address through a debugging tool and a hardware debugging interface.

7. The firmware burning method according to any one of claims 1 to 6, characterized in that: Also includes: Detecting a burning flag, wherein the burning flag is configured to be a valid value or an invalid value, the valid value indicating that firmware burning is being performed, and the invalid value indicating that the firmware is started normally; When the burning flag is a valid value, a step of determining a weight offset corresponding to the firmware slice based on a weight value corresponding to the firmware slice is triggered.

8. A firmware burning device, characterized in that: include: A weight offset determination module, configured to determine a weight offset corresponding to a firmware slice based on a weight value corresponding to the firmware slice, wherein the weight value is determined based on a slice type of the firmware slice; A target address determination module, configured to determine a target address corresponding to the firmware fragment in the memory mapping area of ​​the programmable logic device based on the serial number and weight offset of the firmware fragment; A firmware slice loading module, configured to load the firmware slice into the memory mapping area according to the target address and through a hardware debugging interface; The firmware slice burning module is used to read the firmware slice from the memory mapping area and burn it into the flash memory of the programmable logic device.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to execute the computer program to implement the steps of the firmware burning method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the firmware burning method according to any one of claims 1 to 7 are implemented.

Images