A computer firmware rapid debugging method, device, equipment and medium

Abstract

The application discloses a kind of computer firmware fast debugging method, device, equipment and medium, comprising: using dummy firmware replaces the firmware to be debugged, and dummy firmware is written to the external storage of the computer of the firmware to be debugged;After the computer is powered on, the central processing unit of the computer is controlled dummy firmware is loaded from external storage to the internal storage of the computer;The firmware to be debugged is loaded to internal storage by JTAG debugging interface;Dummy firmware checks whether the firmware to be debugged is loaded completely.The application belongs to the field of computer firmware software development and test.The application is replaced by introducing dummy firmware instead of original debugging firmware, and when executing, it jumps to the original debugging firmware loaded to fixed memory address by JTAG debugging interface at high speed, so that the time of replacing debugging firmware is greatly shortened during firmware development, and the debugging efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer firmware software development and testing, and particularly relates to a computer firmware rapid debugging method, device, equipment and medium. BACKGROUND

[0002] Computer firmware is a kind of software embedded in hardware devices, which provides basic functions to control, monitor and support device hardware. Firmware is an abstraction layer between hardware and operating system, which ensures that hardware can correctly perform its basic operations and provides necessary interfaces and services for operating system or higher-level software. Existing computer firmware (including BIOS, UEFI, U-Boot, PMON, etc.) is stored on external storage media such as EEPROM and Flash Memory. In the prior art, if firmware needs to run on a computer device, it needs to be loaded from external storage media to internal memory by the corresponding storage interface after the processor is powered on, and then executed by the processor.

[0003] The debugging of computer firmware software, like the debugging of general-purpose computer software, requires a large number of source code modifications, compilations and tests to achieve stable operation. Due to the above characteristics, during the development and debugging of computer firmware software, the process of re-burning the test firmware to EEPROM and Flash and other external storage media must be constantly executed, and any changes to the firmware code require re-execution of the entire firmware code compilation and burning process, which is inefficient and inconvenient for rapid verification and debugging ideas, and has a great impact on the development cycle of computer firmware software. Therefore, it is urgent to provide a computer firmware rapid debugging method to solve the problem of low efficiency of computer firmware debugging. SUMMARY

[0004] The present application provides a computer firmware rapid debugging method, device, equipment and medium, which solves the technical problem of low efficiency of firmware debugging in the prior art and achieves the technical effect of improving the efficiency of firmware debugging.

[0005] In a first aspect, the present application provides a computer firmware rapid debugging method, which comprises:

[0006] A dummy firmware is used to replace the firmware to be debugged, and the dummy firmware is burned into the external storage of the computer to be debugged, wherein the binary size of the dummy firmware is less than a preset size threshold;

[0007] After the computer is powered on, the central processing unit of the computer loads the dummy firmware from the external storage into the internal memory of the computer;

[0008] The firmware to be debugged is loaded into the internal memory through the JTAG debugging interface.

[0009] The dummy firmware checks whether the to-be-debugged firmware is loaded completely.

[0010] Further, the method further comprises:

[0011] If the to-be-debugged firmware is not loaded completely, the dummy firmware rechecks whether the to-be-debugged firmware is loaded completely again.

[0012] If the to-be-debugged firmware is loaded completely, the dummy firmware jumps to the to-be-debugged firmware and controls the to-be-debugged firmware to run.

[0013] Further, the method further comprises:

[0014] Determining an actual occupied space of the binary file of the to-be-debugged firmware.

[0015] According to the actual occupied space, determining a supposed occupied space of the binary file of the to-be-debugged firmware.

[0016] Filling the binary file of the to-be-debugged firmware in the form of 0xFF per byte until the actual occupied space of the binary file of the to-be-debugged firmware is changed to the supposed occupied space.

[0017] Further, according to the actual occupied space, determining a supposed occupied space of the binary file of the to-be-debugged firmware, comprises:

[0018] Taking the actual occupied space up to the nearest integer, to obtain the size of the supposed occupied space of the binary file of the to-be-debugged firmware.

[0019] Further, the dummy firmware checks whether the to-be-debugged firmware is loaded completely, comprises:

[0020] Setting the last 16 bytes of the burn address in the binary file of the to-be-debugged firmware to 0x00.

[0021] The dummy firmware checks whether the last 16 bytes in the internal memory of the computer are all 0xFF.

[0022] If yes, the loading is completed, and if no, the loading is not completed.

[0023] Further, the dummy firmware is burned into the external storage of the computer of the to-be-debugged firmware, comprises:

[0024] Based on the JTAG debugging interface, the dummy firmware is burned into the external storage of the computer of the to-be-debugged firmware.

[0025] Further, the dummy firmware is burned into the external storage of the computer of the to-be-debugged firmware, further comprises:

[0026] Burn dummy firmware to external storage of the computer to be debugged based on Serial Peripheral Interface, Inter Integrated Circuit, Universal Asynchronous Receiver / Transmitter or USB.

[0027] In a second aspect, the present application provides a computer firmware rapid debugging device, the device comprising:

[0028] a replacement module configured to replace the firmware to be debugged with a dummy firmware and burn the dummy firmware to external storage of the computer to be debugged, wherein the binary size of the dummy firmware is less than a preset size threshold;

[0029] a first loading module configured to control a central processing unit of the computer to load the dummy firmware from the external storage to internal storage of the computer after the computer is powered on;

[0030] a second loading module configured to load the firmware to be debugged to the internal storage through a JTAG debugging interface;

[0031] a checking running module configured to check whether the firmware to be debugged is loaded completely by the dummy firmware.

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

[0033] a processor;

[0034] a memory configured to store processor-executable instructions;

[0035] wherein the processor is configured to execute to implement the computer firmware rapid debugging method provided in the first aspect.

[0036] In a fourth aspect, the present application provides a non-transitory computer readable storage medium, when instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute to implement the computer firmware rapid debugging method provided in the first aspect.

[0037] One or more technical solutions provided in the present application have at least the following technical effects or advantages:

[0038] The application introduces a dummy firmware with a small binary file and a very short burning time to replace the original debugging firmware, and the dummy firmware is quickly burned into an external storage medium such as an EEPROM or a Flash Memory, and when executed, it jumps to the original debugging firmware loaded at a fixed memory address through a JTAG debugging interface at a high speed, so that the time for replacing the debugging firmware during the firmware development process is greatly shortened, and the debugging efficiency is improved.

[0039] The method provided by the application only needs to burn the dummy firmware into an external storage medium such as an EEPROM or a Flash Memory once during the debugging process, and then the firmware development and debugging can be performed unlimited times, thereby greatly reducing the service life consumption of the external storage medium.

[0040] In the case that the firmware debugging only needs to modify a small function point, the method provided by the application can perform a modification operation in the dummy firmware, so that the effect of quickly verifying the debugging idea is achieved without modifying the debugging firmware. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are some embodiments of the application, and other drawings can also be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0042] Figure 1 A flowchart of a computer firmware rapid debugging method provided by the application is shown in the figure.

[0043] Figure 2 A flowchart of an existing firmware debugging method provided by the application is shown in the figure.

[0044] Figure 3 A structure diagram of an existing firmware debugging provided by the application is shown in the figure.

[0045] Figure 4 A structure diagram of a computer firmware rapid debugging provided by the application is shown in the figure.

[0046] Figure 5 A flowchart of another computer firmware rapid debugging method provided by the application is shown in the figure. DETAILED DESCRIPTION

[0047] The embodiment of the application provides a computer firmware rapid debugging method, which solves the technical problem of low efficiency of firmware rapid debugging in the prior art.

[0048] The technical scheme of the application is as follows to solve the above technical problems:

[0049] The application discloses a computer firmware rapid debugging method, and the method comprises the following steps: replacing a to-be-debugged firmware with a dummy firmware, and burning the dummy firmware into an external storage of the to-be-debugged firmware, wherein the binary size of the dummy firmware is smaller than a preset size threshold; after the computer is powered on, a central processing unit of the computer is controlled to load the dummy firmware from the external storage into an internal storage of the computer; the to-be-debugged firmware is loaded into the internal storage through a JTAG debugging interface; and the dummy firmware checks whether the to-be-debugged firmware is loaded completely.

[0050] In order to better understand the above technical solutions, the above technical solutions will be described in detail in combination with the drawings of the specification and specific embodiments.

[0051] Firstly, the term "and / or" appearing in the present document only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone. In addition, the character " / " in the present document generally represents an "or" relationship between the front and rear associated objects.

[0052] As shown in Figure 2 , when computer firmware is debugged, after the source code of the computer firmware is modified each time, the newly compiled complete set of debugging firmware needs to be first burned into the external storage of the computer for storing firmware through a JTAG debugging interface (or other EEPROM, Flash storage access mode). The operation time is 3-5 minutes, and under certain hardware architecture, the operation time is 10-20 minutes. Once the attempt of the code modification does not produce an effect, or a new bug is introduced, even if the time for debugging and analyzing the problem is not considered, the attempt again needs to spend such a long time to deploy the test version firmware. This has a great influence on the efficiency of the research and development work.

[0053] As shown in Figure 3 , when the existing computer firmware is debugged, the "official firmware" (that is, the to-be-debugged firmware in the present application) to be debugged is burned into the computer to be debugged through a JTAG debugger, and is loaded into the memory after the computer to be debugged is started.

[0054] The application provides a computer firmware rapid debugging method as shown in Figure 1 , which comprises steps S11-S14, in addition to Figure 1 , the method provided by the application can also refer to the debugging firmware in Figure 4 and Figure 5 , Figure 4 The debugging firmware in the present application is the to-be-debugged firmware in the present application, Figure 5 The official firmware in the present application is also the to-be-debugged firmware in the present application:

[0055] In step S11, a dummy firmware is used to replace the to-be-debugged firmware, and the dummy firmware is burned into the external storage of the computer of the to-be-debugged firmware, wherein the binary size of the dummy firmware is less than a preset size threshold.

[0056] The to-be-debugged firmware in the application includes but is not limited to legacy BIOS, UEFI-BIOS, U-Boot, PMON, and the main work of which is hardware initialization, booting of an operating system, and basic function configuration of a computer.

[0057] The dummy firmware in the application refers to a binary size that is extremely small and can be burned into a computer firmware storage peripheral (including but not limited to EEPROM and Flash Memory). The dummy firmware can run in a central processing unit of a computer, has functions such as memory access and peripheral IO operation, and makes the central processing unit jump to a computer firmware (including but not limited to legacy BIOS, UEFI-BIOS, U-Boot, and PMON firmware) software for running. The firmware software can be written in assembly code compatible with the central processing unit architecture to ensure the smallest binary code size after compilation, or can be written in a high-level language commonly used for computer firmware (the binary code size is relatively larger than that of assembly code).

[0058] In the case of using assembly code to write, only having the functions of checking and jumping to run the debugged firmware after the firmware is burned, the dummy firmware can be only 1 KB in size. Compared with the to-be-debugged firmware, the size of which is usually 1 MB to 3 MB, the dummy firmware is only 1 / 3000 to 1 / 1000 of the to-be-debugged firmware. The preset size threshold can be determined according to actual conditions, which is not limited here.

[0059] The dummy firmware can be burned into the external storage of the computer of the to-be-debugged firmware based on a JTAG debugging interface.

[0060] JTAG (Joint Test Action Group) is a standardized test and debugging interface, which is originally designed for testing and diagnosing at the circuit board level. With the development of time, the JTAG interface is widely used in embedded system development, especially in the debugging and programming of devices such as microcontrollers, processors, and FPGAs.

[0061] The original design purpose of the JTAG debugging interface is to perform interconnection testing on the circuit board to ensure the normal connection between components. By adding a shift register chain (called boundary scan register) at the boundary of each IC chip, the signal path on the circuit board can be tested without directly accessing the signal pin.

[0062] In embedded system development, JTAG interface is commonly used for debugging and programming target devices. Developers can perform online debugging, download firmware, set breakpoints, view register and memory content, etc. through JTAG interface.

[0063] JTAG debugging interface supports debugging devices at runtime, including single-step execution, viewing variable values, setting breakpoints, etc. It helps developers quickly locate and solve problems.

[0064] In addition to burning dummy firmware into the external storage of the computer to be debugged, it also includes:

[0065] Based on Serial Peripheral Interface, Inter Integrated Circuit, Universal Asynchronous Receiver / Transmitter or USB, burn dummy firmware into the external storage of the computer to be debugged.

[0066] SPI is a synchronous serial communication interface, widely used in communication between microcontrollers and peripheral devices.

[0067] Embedded systems can use SPI Flash as storage medium, and can directly program Flash through SPI interface.

[0068] I²C (Inter Integrated Circuit) is a two-wire serial bus, mainly used for short distance communication. I²C is commonly used for configuration and control of devices, and can also be used for small capacity firmware programming.

[0069] UART is an asynchronous serial communication interface, commonly used for data exchange with external devices. Some devices support firmware update through UART interface.

[0070] USB is a universal serial bus standard, widely used in connection between computers and their peripheral devices.

[0071] Step S12, after the computer is powered on, the central processor of the computer loads the dummy firmware from the external storage into the internal storage of the computer.

[0072] When the computer is powered on, the POST process will be performed first, which is part of the BIOS or UEFI firmware. The POST process checks the basic functions of the hardware and initializes the system. After the POST is completed, the computer will try to load the bootloader from the specified boot device (such as hard disk, SSD, Flash, etc.). The bootloader is responsible for further loading the operating system or other critical firmware.

[0073] After the dummy firmware is burned into the external storage device (such as Flash memory), the dummy firmware is loaded into the internal memory of the computer by the central processing unit of the computer.

[0074] In addition, it also includes: determining the actual occupied space of the binary file of the firmware to be debugged; determining the proposed occupied space of the binary file of the firmware to be debugged according to the actual occupied space; filling the binary file of the firmware to be debugged in the form of 0xFF per byte until the actual occupied space of the binary file of the firmware to be debugged changes to the proposed occupied space.

[0075] According to the actual occupied space, the proposed occupied space of the binary file of the firmware to be debugged is determined, including: rounding up according to the size of the actual occupied space to obtain the size of the proposed occupied space of the binary file of the firmware to be debugged.

[0076] When compiling the binary file of the firmware to be debugged, data padding processing is performed on the end of the binary file.

[0077] Specifically: the size of the binary file of the firmware to be debugged can be designed to be rounded up to MB (megabyte).

[0078] At present, the size of computer firmware is generally several hundred KB (kilobyte) to several MB (megabyte), and the most common U-Boot, UEFI-BIOS firmware size is about 4MB, rounded up to MB, which can ensure that the dummy firmware checks the memory address unchanged, and can cope with the possibility of increasing the size of the firmware to be debugged.

[0079] For example, the effective binary size of the firmware to be debugged is 1.2MB, and the binary size after padding is rounded up to 2MB. Even if more functions and codes are added to the firmware to be debugged in the subsequent debugging process, there are 0.8MB of space for expansion. To a large extent, it ensures that the judgment logic in the dummy firmware code does not need to be changed.

[0080] Each byte of the content of the padding data can be 0xFF, and after the content of the general external storage device Flash is erased, the data content is only 0xFF (determined by the Flash storage unit based on the floating gate transistor technology, that is, 0xFF in the Flash storage represents the default data). In addition, when the padding data is 0xFF, it will not be considered as a valid instruction by the CPU and will not be executed as expected.

[0081] Step S13, the to-be-debugged firmware is loaded to the internal memory through the JTAG debugging interface.

[0082] The to-be-debugged firmware can be loaded to the internal memory of the computer based on the JTAG debugging interface.

[0083] Step S14, the dummy firmware checks whether the to-be-debugged firmware is loaded.

[0084] Specifically, the last 16 bytes of the burn address in the binary file of the to-be-debugged firmware are all set to 0x00; the dummy firmware checks whether the last 16 bytes in the internal memory of the computer are all 0xFF; if yes, the loading is completed, and if no, the loading is not completed.

[0085] The last 16 bytes of the burn address in the binary file of the to-be-debugged firmware can be written as 0x00, and then the internal memory is read repeatedly to check whether the value is 0xFF.

[0086] It should be particularly emphasized that the 0xFF filled in the binary file of the to-be-debugged firmware is invalid data space in the binary file, and does not replace the original data in the binary file padding.

[0087] Specifically, the dummy firmware can be run, and the running code of the dummy firmware is responsible for the operation of setting 0x00 once, and after the dummy firmware sets the memory to 0x00, it starts to repeatedly check whether the last 16 bytes are 0xFF (0xFF exists only after the JTAG burn memory is completed).

[0088] The internal memory is set to 0x00 first, which is to distinguish from the 0xFF filled by the debugging firmware. At the same time, the maximum size of an effective instruction of the current mainstream processor architecture is 15 bytes for the x86 architecture, and the size of an instruction of other instruction sets such as ARM, MIPS, RISC-V, etc. is generally below 8 bytes. Therefore, the 16-byte content of 0xFF can indicate that this memory is the last padding value, rather than the executable instruction of the to-be-debugged firmware itself.

[0089] Further comprising: if the to-be-debugged firmware is not loaded, the dummy firmware rechecks whether the to-be-debugged firmware is loaded again; if the to-be-debugged firmware is loaded, the dummy firmware jumps to the to-be-debugged firmware and controls the to-be-debugged firmware to run.

[0090] In conclusion, the present application provides a computer firmware rapid debugging method, which comprises: using a dummy firmware to replace a to-be-debugged firmware, and burning the dummy firmware into an external storage of the computer to which the to-be-debugged firmware belongs, wherein the binary size of the dummy firmware is less than a preset size threshold; after the computer is powered on, controlling a central processing unit of the computer to load the dummy firmware from the external storage into an internal storage of the computer; loading the to-be-debugged firmware into the internal storage through a JTAG debugging interface; and checking by the dummy firmware whether the to-be-debugged firmware is loaded. In the prior art, after each code modification, the whole set of firmware needs to be burned into the external storage medium again, and the erasing and writing speed of the external storage medium such as EEPROM and Flash Memory is slow, which is very wasteful of valuable research and development debugging time. After each code modification, the whole set of firmware needs to be burned into the external storage medium again, and the erasing and writing times of the storage particles currently used in the external storage medium such as EEPROM and Flash Memory are limited in life, and the erasing and writing times of a better particle TLC (three-layer storage unit) are about 1000, and the erasing and writing times of a more conventional QLC (four-layer storage unit) are only about 150. Excessive repeated erasing and writing in debugging may cause the storage particles to consume their service life, thereby causing unstable problems in firmware operation and introducing more research and development debugging time and labor consumption. In the ordinary debugging mode, even a small code modification needs to recompile the whole set of firmware, which greatly hinders the rapid verification of debugging ideas and the rapid iteration of firmware code. The present application introduces a dummy firmware with a small binary file and a small burning time to replace the original debugging firmware, which is quickly burned into the external storage medium such as EEPROM and Flash Memory, and jumps to the original debugging firmware loaded into a fixed memory address through a JTAG debugging interface during execution, so that the time for replacing the debugging firmware during firmware development is greatly shortened, and the debugging efficiency is improved. The method provided by the present application only needs to burn the dummy firmware into the external storage medium such as EEPROM and Flash Memory once during debugging, and can be used for unlimited times of firmware development and debugging, which greatly reduces the consumption of the service life of the external storage medium. In the case of only modifying a small function point in the firmware debugging, the method provided by the present application can modify the operation in the dummy firmware, so as to quickly verify the effect of the debugging idea without modifying the debugging firmware.

[0091] Based on the same inventive concept, the present application provides a computer firmware rapid debugging device, the device comprising:

[0092] a dummy module, configured to replace the to-be-debugged firmware with a dummy firmware, and to burn the dummy firmware into external storage of the to-be-debugged computer, wherein the binary size of the dummy firmware is less than a preset size threshold;

[0093] a first loading module, configured to, after the to-be-debugged computer is powered on, control a central processing unit of the computer to load the dummy firmware from the external storage into internal storage of the computer;

[0094] a second loading module, configured to load the to-be-debugged firmware into the internal storage through a JTAG debugging interface;

[0095] a checking running module, configured to check whether the to-be-debugged firmware is loaded completely by the dummy firmware.

[0096] Based on the same inventive concept, the present application further provides an electronic device, comprising:

[0097] a processor;

[0098] a memory for storing processor-executable instructions;

[0099] wherein the processor is configured to execute to implement a computer firmware rapid debugging method as provided in the foregoing.

[0100] Based on the same inventive concept, the present application further provides a non-transitory computer readable storage medium, when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to implement a computer firmware rapid debugging method as provided in the foregoing.

[0101] Since the electronic device introduced in the embodiment is the electronic device used to implement the method of processing information in the embodiment, based on the method of processing information introduced in the embodiment, those skilled in the art can understand the specific implementation of the electronic device and its various forms, so the electronic device how to implement the method in the embodiment will not be introduced in detail. As long as the electronic device used to implement the method of processing information in the embodiment is implemented by those skilled in the art, it belongs to the scope of the present application.

[0102] Those skilled in the art will appreciate that embodiments of the present application can be devised for a variety of applications. It is intended that the present application be limited only by the scope of the appended claims, and it is intended that various modifications and alterations made by those skilled in the art be considered as within the scope of the present application. The embodiments of the present application will be described with reference to the attached drawings, wherein:

[0103] The present application is described in reference to the drawings using a flowchart and / or a block diagram of the method, apparatus (system) and computer program product according to embodiments of the application. It will be understood that each block of the flowchart and / or block diagram, and combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing device or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks.

[0104] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks.

[0105] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks.

[0106] While the preferred embodiments of the application have been described, additional variations and modifications can be made to the embodiments by those skilled in the art once they learn of the basic inventive concepts. Therefore, the appended claims are intended to cover all such modifications and variations as fall within the scope of the present application.

[0107] Obviously, many modifications and variations of the present application are possible in light of the above teachings. It is, therefore, to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A method for rapid debugging of computer firmware, characterized in that, The method includes: A dummy firmware is used to replace the firmware to be debugged, and the dummy firmware is burned to the external storage of the computer of the firmware to be debugged, wherein the binary size of the dummy firmware is less than a preset size threshold, including: burning the dummy firmware to the external storage of the computer of the firmware to be debugged based on the JTAG debugging interface. After the computer is powered on, the central processing unit that controls the computer loads the dummy firmware from the external storage into the computer's internal memory; The firmware to be debugged is loaded into the internal memory via the JTAG debugging interface; The dummy firmware checks whether the firmware to be debugged has been loaded successfully. Also includes: If the firmware to be debugged has not been fully loaded, the dummy firmware will recheck whether the firmware to be debugged has been fully loaded. If the firmware to be debugged is loaded, the dummy firmware will switch to the firmware to be debugged and control the firmware to be debugged to run.

2. The method for rapid debugging of computer firmware as described in claim 1, characterized in that, Also includes: Determine the actual space occupied by the binary file of the firmware to be debugged; Based on the actual space occupied, determine the intended space occupied by the binary file of the firmware to be debugged; The binary file of the firmware to be debugged is padded with 0xFF per byte until the actual space occupied by the binary file of the firmware to be debugged is changed to the intended space occupied.

3. The method for rapid debugging of computer firmware as described in claim 2, characterized in that, Based on the actual space occupied, the intended space occupied by the binary file of the firmware to be debugged is determined, including: The proposed size of the binary file of the firmware to be debugged is obtained by rounding up the actual space occupied.

4. A method for rapid debugging of computer firmware as described in any one of claims 2 or 3, characterized in that, The dummy firmware checks whether the firmware to be debugged has been loaded successfully, including: Set the last 16 bytes of the burning address in the binary file of the firmware to be debugged to 0x00; The dummy firmware checks in the computer's internal memory whether the last 16 bytes are all 0xFF; If both are true, then loading is complete; otherwise, loading is incomplete.

5. The method for rapid debugging of computer firmware as described in claim 1, characterized in that, Burning the dummy firmware to the external storage of the computer containing the firmware to be debugged also includes: The dummy firmware is burned to the external storage of the computer whose firmware is to be debugged, using Serial Peripheral Interface, Inter Integrated Circuit, Universal Asynchronous Receiver / Transmitter, or USB.

6. A rapid debugging device for computer firmware, characterized in that, The apparatus used in a rapid debugging method for computer firmware according to any one of claims 1-5 comprises: A replacement module is used to replace the firmware to be debugged with dummy firmware and to burn the dummy firmware to the external storage of the computer of the firmware to be debugged, wherein the binary size of the dummy firmware is less than a preset size threshold. The first loading module is used to control the computer's central processing unit to load the dummy firmware from the external storage to the computer's internal memory after the computer is powered on. The second loading module is used to load the firmware to be debugged into the internal memory through the JTAG debugging interface; The check module is used by the dummy firmware to check whether the firmware to be debugged has been loaded successfully.

7. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute a method for rapid debugging of computer firmware as described in any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform a computer firmware rapid debugging method as described in any one of claims 1 to 5.

Images