Method and device for storing firmware debugging information during abnormal power failure of storage equipment
By detecting abnormal power failure in solid-state storage devices and generating and sorting field sub-blocks, the problem of saving firmware field in a very short time is solved, and effective debugging is achieved during the next power-on, which improves debugging efficiency.
Patent Information
- Application Number
- CN202411819194.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-11
- Publication Date
- 2025-04-04
- Estimated Expiration
- 2044-12-11
AI Technical Summary
When solid-state storage devices face abnormal power outages of external power supply, it is difficult for the prior art to effectively save the firmware site in a very short time, resulting in low fault debugging efficiency.
By detecting abnormal power outage, the control cores in multiple processor cores detect the power outage completion flag after a predetermined time. If it does not exist, an interrupt is sent. Each processor core generates field sub-blocks and sorts and stores these sub-blocks to a persistent storage medium according to the possibility of abnormal occurrence.
In the event of an abnormal power outage process failure, the key firmware field information can be saved in a very short time, so as to effectively debug the next power-on and improve debugging efficiency.
Smart Images

Figure CN119759624A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computer technology, and in particular to a method, device, equipment and medium for on-site processing of saving firmware for abnormal power failure. Background Art
[0002] Figure 1 The block diagram of the solid-state storage device is shown. The solid-state storage device 102 is coupled to the host to provide storage capacity for the host. The host and the solid-state storage device 102 can be coupled in a variety of ways, including but not limited to connecting the host and the solid-state storage device 102 through, for example, SATA (Serial Advanced Technology Attachment), SCSI (Small Computer System Interface), SAS (Serial Attached SCSI), IDE (Integrated Drive Electronics), USB (Universal Serial Bus), PCIE (Peripheral Component Interconnect Express, PCIE, high-speed peripheral component interconnect), NVMe (NVM Express, high-speed non-volatile storage), Ethernet, Fiber Channel, wireless communication network, etc. The host can be an information processing device that can communicate with the storage device in the above manner, such as a personal computer, a tablet computer, a server, a portable computer, a network switch, a router, a cellular phone, a personal digital assistant, etc. The storage device 102 includes an interface 103 , a control component 104 , one or more NVM chips 105 , and a DRAM (Dynamic Random Access Memory) 110 .
[0003] NAND flash memory, phase change memory, FeRAM (Ferroelectric RAM), MRAM (Magnetic Random Access Memory), RRAM (Resistive Random Access Memory), etc. are common NVMs.
[0004] The interface 103 may be adapted to exchange data with the host via, for example, SATA, IDE, USB, PCIE, NVMe, SAS, Ethernet, Fibre Channel, etc.
[0005] The control component 104 is used to control data transmission between the interface 103, the NVM chip 105 and the DRAM 110, and is also used for storage management, host logical address to flash physical address mapping, erase leveling, bad block management, etc. The control component 104 can be implemented in a variety of ways such as software, hardware, firmware or a combination thereof. For example, the control component 104 can be in the form of FPGA (Field Programmable gate array), ASIC (Application Specific Integrated Circuit) or a combination thereof. The control component 104 can also include a processor or a controller, and software is executed in the processor or controller to manipulate the hardware of the control component 104 to process IO (Input / Output) commands. The control component 104 can also be coupled to the DRAM 110 and can access the data of the DRAM 110. The data of the FTL table and / or cached IO commands can be stored in the DRAM.
[0006] The control component 104 includes a flash memory interface controller (or medium interface controller, flash memory channel controller), which is coupled to the NVM chip 105 and issues commands to the NVM chip 105 in a manner that complies with the interface protocol of the NVM chip 105 to operate the NVM chip 105, and receives command execution results output from the NVM chip 105. Known NVM chip interface protocols include "Toggle", "ONFI" and the like.
[0007] Usually, when a storage device faces an abnormal power failure due to external power supply, it needs to save the currently cached IO data, various metadata used by the firmware (such as FTL table), etc. to the NVM chip. To this end, capacitors and other components are usually used as backup power supplies to provide a short internal power supply time for the storage device. However, this time is often very short and the amount of data that can be saved is limited. Therefore, the firmware is required to have a more complex abnormal power failure processing process to achieve the purpose of saving all the data that needs to be saved in a short time.
[0008] However, the complex abnormal power-off processing process leads to a higher firmware failure rate. In order to discover and solve these firmware failures, it is necessary to analyze the firmware operation when it occurs. However, when an abnormal power failure occurs, the backup power supply can only supply power for a short time, which limits the methods of investigating firmware failures, such as online debugging. Therefore, the firmware needs to save its own firmware scene in a very short time, or try to retain key content so that it can be obtained externally at the next power-on for debugging. Summary of the invention
[0009] In order to solve the above technical problem or at least partially solve the above technical problem, the present disclosure provides a method, device, equipment and medium for saving firmware in an abnormal power failure.
[0010] The disclosed embodiments provide a method for preserving firmware on-site during abnormal power failure, which is applied to a storage device, and includes: detecting an abnormal power failure; a control core among a plurality of processor cores detecting a power failure completion flag after a predetermined time after the abnormal power failure is detected, and if the power failure completion flag does not exist, the control core sending an interrupt to the plurality of processor cores; the plurality of processor cores each acquire a corresponding data sub-block based on the interrupt to generate a field sub-block, thereby obtaining a plurality of field sub-blocks; the control core stores part or all of the plurality of field sub-blocks to a target area of a persistent storage medium space based on a sorting result of sorting the plurality of field sub-blocks according to the likelihood of occurrence of the abnormality.
[0011] The disclosed embodiment also provides a device for saving firmware on-site during abnormal power failure, which is applied to a storage device, and the device includes: a detection module, which is used to detect an abnormal power failure; a sending module, which is used for a control core among multiple processor cores to detect a power failure completion flag after a predetermined time after the abnormal power failure is detected, and if the power failure completion flag does not exist, the control core sends an interrupt to the multiple processor cores; a generation module, which is used for each of the multiple processor cores to obtain a corresponding data sub-block based on the interrupt to generate a field sub-block, so as to obtain a plurality of field sub-blocks; and a storage module, which is used for the control core to store part or all of the plurality of field sub-blocks to a target area of a persistent storage medium space based on a sorting result of the plurality of field sub-blocks sorted according to the probability of the occurrence of the abnormality.
[0012] An embodiment of the present disclosure also provides an electronic device, comprising: a processor; a memory for storing executable instructions of the processor; the processor is used to read the executable instructions from the memory and execute the executable instructions to implement the on-site method for saving firmware for abnormal power failure as provided in an embodiment of the present disclosure.
[0013] The embodiment of the present disclosure further provides a computer-readable storage medium, wherein the storage medium stores a computer program, wherein the computer program is used to execute the on-site method for saving firmware for abnormal power failure provided by the embodiment of the present disclosure.
[0014] The embodiment of the present disclosure further provides a computer program product, including a computer program, wherein the computer program is executed by a processor as the on-site method for saving firmware for abnormal power failure provided by the embodiment of the present disclosure.
[0015] The technical solution provided by the embodiment of the present disclosure has the following advantages over the prior art: the solution for preserving firmware on-site during abnormal power failure provided by the embodiment of the present disclosure detects abnormal power failure, and the control core among the multiple processor cores detects the power failure completion flag after a predetermined time after the abnormal power failure is detected. If the power failure completion flag does not exist, the control core sends an interrupt to the multiple processor cores, and the multiple processor cores each obtain the corresponding data sub-block based on the interrupt to generate a field sub-block, thereby obtaining multiple field sub-blocks. The control core stores part or all of the multiple field sub-blocks to the target area of the persistent storage medium space based on the sorting result of sorting the multiple field sub-blocks according to the probability of abnormal occurrence. By adopting the above technical solution, when the device has a power failure exception, the key information of the firmware field can be retained, so that the problem can be quickly located based on the saved field data, greatly improving the debugging efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.
[0017] Figure 1 is a schematic diagram of a solid-state storage device;
[0018] Figure 2 A structural block diagram of a Gaoyaotai storage device provided in an embodiment of the present disclosure;
[0019] Figure 3 A flowchart of a method for saving firmware on-site during abnormal power failure provided by an embodiment of the present disclosure;
[0020] Figure 4 An example diagram of dividing the firmware scene into scene sub-blocks provided by an embodiment of the present disclosure;
[0021] Figure 5 An example diagram of a field sub-block structure provided for an embodiment of the present disclosure;
[0022] Figure 6 An example diagram of the process of firmware on-site storage provided by the embodiment of the present disclosure;
[0023] Figure 7 A schematic diagram of the structure of a field device for storing firmware during abnormal power failure provided by an embodiment of the present disclosure. DETAILED DESCRIPTION
[0024] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.
[0025] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.
[0026] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.
[0027] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.
[0028] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".
[0029] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.
[0030] Based on the description of the aforementioned background technology, Figure 2 A block diagram representing a typical storage device to which embodiments of the present disclosure may be applied. Figure 2 Too Figure 1 Detailed block diagram of the control component 104.
[0031] The control component includes multiple processor cores (e.g., processor cores 0-3). Each processor core has its own memory (e.g., memory 0-3) for storing the firmware running on the corresponding processor core. The firmware running on each processor core is different. The processor core's own storage device also stores data generated or used during the firmware running. Software running in an embedded device is usually called firmware.
[0032] The control unit also includes a cache / shared memory. The shared memory can be used by the processor core.
[0033] The control component also includes SRAM, which is mainly used as a cache to store IO data, and in this application is also used to store the field sub-blocks generated by each processor core.
[0034] The processor cores can communicate with each other through an inter-core queue (not shown) or a shared memory.
[0035] Multiple processor cores have tasks divided, and one of the cores is selected as the control core.
[0036] Typically, the firmware running on one processor core is called a logic module. For example, the control core is logic module 0. However, some processor cores run multiple logic modules. These logic modules can be considered as different firmware that can run concurrently. For example, a logic module is a process, thread, or coroutine.
[0037] Firmware site: For the purpose of subsequent debugging, the firmware site that the processor core / logic module needs to save includes various status information during abnormal power failure, mainly including: register status, core independent storage area data, inter-core shared fast storage area data, inter-core shared slow storage area data, stack information, SQ / CQ queue, Admin queue, memory management information, memory information, other status information of the processor, status information of hardware accelerator, cache content, inter-core communication queue, inter-core shared memory, etc.
[0038] Memory information: mainly includes the memory usage of the application, including the stack, code segment, data segment, and heap.
[0039] Register status: Contains the values of the architecture registers of the processor core when the program crashes, such as the program pointer, stack pointer, etc.
[0040] Stack information: includes stack pointer and function call stack information, which helps locate the function call chain when the program crashes.
[0041] Memory management information: This information involves the memory allocation and usage of the program, which helps to check for problems such as memory leaks.
[0042] Other processor and operating system status information: In addition to memory information, there are some key program running status.
[0043] The firmware scene mainly exists in the registers inside the processor core, the memory corresponding to the processor core, and also includes the contents of the inter-core queue, SQCQ and / or AdminQ defined by the NVMe protocol. The state of the flash channel controller can also be used as the firmware scene. The flash channel controller is used to operate NAND flash memory.
[0044] The outside of the control unit is connected to a backup power supply, DRAM, and multiple NAND flash memories.
[0045] The backup power supply is used to provide short-term power when power is off abnormally, so that the control components can execute the processing flow of handling abnormal power off. Its power supply time is 10-20ms.
[0046] NAND flash memory is a "persistent storage medium". The storage space it provides is divided into two parts, one part stores user data (related to IO commands). The other part stores system data. In the space storing system data, a space is reserved as the "persistent storage medium space" for storing the on-site sub-blocks of the present invention. This is divided into multiple areas. The on-site sub-blocks are to be written into one or some of the areas.
[0047] The main function of the backup power supply is to write the user data cached in the memory SRAM or DRAM to the NAND flash memory when the power is off abnormally. The storage of the on-site sub-block is an additional requirement for it, so: (1) The backup power supply is unreliable for saving the on-site sub-block, so it is necessary to optimize the process of saving the on-site sub-block, including multi-core collaborative work to avoid affecting the normal abnormal power-off processing process, and giving priority to saving more important on-site sub-blocks; (2) The backup power supply is used to save not only the on-site sub-blocks, but also other data.
[0048] Each processor core generates several on-site sub-blocks. These are divided into on-site sub-blocks that can only be generated by the processor core itself and on-site sub-blocks that can be generated by any processor core. For the internal registers of the processor core and its own exclusive memory, only the processor core itself knows this information, and this part of the on-site sub-block can only be generated by itself. However, any processor core can obtain and generate the corresponding on-site sub-blocks for contents such as SQ / CQ.
[0049] The method for saving firmware scene in abnormal power failure proposed in the embodiment of the present disclosure detects abnormal power failure; the control core in multiple processor cores detects the power failure completion flag after a predetermined time after the abnormal power failure is detected, and if the power failure completion flag does not exist, the control core sends an interrupt to the multiple processor cores; the multiple processor cores each obtain the corresponding data sub-block based on the interrupt to generate a scene sub-block, and obtain multiple scene sub-blocks; the control core stores part or all of the multiple scene sub-blocks to the target area of the persistent storage medium space based on the sorting result of sorting the multiple scene sub-blocks according to the possibility of abnormal occurrence. The above technical solution can save the key scene in a very short time in the event of failure of the abnormal power failure process, and can be externally obtained after the next power-on, and the scene can be restored for maximum debugging, thereby greatly improving the debugging efficiency.
[0050] Figure 3The present invention provides a flowchart of a method for saving firmware on-site during abnormal power failure, which is provided in an embodiment of the present invention. Figure 3 As shown, the method is applied to a storage device, comprising:
[0051] Step 201: Detect abnormal power failure.
[0052] Step 202: After a predetermined time after detecting abnormal power failure, a control core among the multiple processor cores detects a power failure completion flag. If the power failure completion flag does not exist, the control core sends an interrupt to the multiple processor cores.
[0053] Specifically, the storage device is connected to the host. Under normal circumstances, the user shuts down the host by pressing a button or operating the system. During the shutdown process, the host notifies the storage device to power off. The host provides sufficient power for the storage device during the power-off period, so that the storage device has enough time to execute the power-off process.
[0054] In the embodiment of the present disclosure, abnormal power failure refers to an event in which the storage device loses power due to the user not performing a normal shutdown operation by pressing a shutdown button or the like.
[0055] In some embodiments, a preset time greater than an average duration is set, wherein the average duration is determined based on a plurality of historical durations for the storage device to complete power-off processing.
[0056] Specifically, when the preset time is slightly longer than the normal situation (such as the average duration of the power-off completion mark), each processor core can complete the abnormal power-off process. Therefore, the power-off completion mark is checked at the preset time. If it does not exist, it means that one or some logic modules have problems. Only then does it make sense to save the firmware scene.
[0057] It should be noted that the preset time can also be set according to actual application needs, such as setting a timer with a fixed time, and checking the power-off completion flag when the timer expires. The power-off completion flag is used to indicate that the power-off is completed.
[0058] In the disclosed embodiment, the firmware includes multiple logic modules running on multiple processor cores, and the abnormal power-off processing flow of each logic module includes multiple power-off steps. In response to detecting an abnormal power-off, each logic module executes its own abnormal power-off processing flow, and records the number of the power-off step that has been executed in the execution of its own abnormal power-off processing flow, and generates a power-off completion flag after multiple logic modules have completed their own abnormal power-off processing flows. Thus, each logic module in the firmware divides the power-off processing flow into multiple sub-steps, records the number of the completed sub-steps in real time, analyzes the possibility of abnormality of each logic module according to the number of the completed sub-steps of each logic module, and the logical dependency relationship between the sub-steps, sorts the logic modules according to the possibility of abnormality, and can subsequently give priority to saving the field data of the logic module with a high probability of abnormality, further ensuring the efficiency and effect of subsequent debugging.
[0059] If the power-off completion mark cannot be detected, that is, the power-off completion mark does not exist, the firmware needs to be started for on-site saving. That is, when the abnormal power-off begins, the firmware will start a fixed-time timer, and check the power-off completion mark when the timer expires. If the power-off completion mark does not exist, the firmware will be started for on-site saving. It should be noted that the abnormal power-off processing flow of each logic module continues to run.
[0060] Among them, to start the firmware scene saving, the control core among the multiple processor cores can send an interrupt to the multiple processor cores (including the control core) to notify the multiple processor cores to save the firmware scene; among them, one of the multiple processor cores can be used as the control core according to the actual application needs, and the remaining processor cores perform corresponding operations based on the interrupt sent by the control core.
[0061] Step 103: Multiple processor cores each acquire a corresponding data sub-block based on the interrupt to generate a field sub-block, thereby obtaining multiple field sub-blocks.
[0062] Step 104 : The control core stores part or all of the multiple on-site sub-blocks into a target area of the persistent storage medium space based on a result of sorting the multiple on-site sub-blocks according to the probability of occurrence of an exception.
[0063] In the embodiment of the present disclosure, after receiving an interrupt, each processor core packs the data sub-block corresponding to each processor core into the corresponding on-site sub-block, and writes completion mark information when the on-site sub-block packing is completed. After the control core generates the on-site sub-block of its core, it exits the interrupt, and after each core of the control core generates the on-site sub-block of its core, it also assists in processing the unfinished packing from the data sub-block to the on-site sub-block. After the control core exits the interrupt, the sorting result of sorting the multiple on-site sub-blocks according to the probability of abnormal occurrence stores part or all of the multiple on-site sub-blocks in the target area of the persistent storage medium space.
[0064] The firmware includes multiple logic blocks running on multiple processor cores, the power-off completion flag includes one or more power-off completion flags generated by the multiple logic blocks, and the possibility of abnormal occurrence of one or more of the multiple logic blocks is judged based on the power-off completion flags generated by the multiple logic blocks; or, the possibility of abnormal occurrence of one or more of the multiple logic blocks is judged based on the historical abnormal occurrence of one or more of the multiple logic blocks. In other words, if the abnormal power-off processing flow progresses slower than expected, there is a greater possibility of problems, and therefore it is necessary to give priority to saving its firmware scene; or, based on experience or historical data, which logic modules are more likely to have problems during abnormal power-off.
[0065] In some embodiments, the abnormal power failure processing of each logic module in the firmware is sorted according to the process progress of the current process, and the abnormal possibility of each logic module in the firmware is set according to the sorting result; and / or, the abnormal possibility of each logic module in the firmware is set according to the firmware field content processed by each logic module in the firmware. In other words, the possibility of abnormality is sorted in an order related to the logic module, for example, if the abnormal power failure processing process progresses slowly, it is more likely to have a problem, and the field sub-block corresponding to the logic module is placed in front; the possibility of abnormality is sorted in an order related to the firmware field content, for example, the register state and stack information are in front, and the memory information is in the back.
[0066] In some embodiments, in response to detecting an abnormal power failure, each processing core processes its own abnormal power failure processing flow in parallel, and multiple processor cores respond to an interrupt, suspend their own abnormal power failure processing flows, generate multiple field sub-blocks, and then resume processing their own abnormal power failure processing flows.
[0067] Specifically, the firmware includes multiple logic modules running on multiple processor cores, and each logic module's own abnormal power-off processing flow includes multiple power-off steps. In response to detecting an abnormal power-off, each logic module executes its own abnormal power-off processing flow, and records the number of the power-off step that has been executed while executing its own abnormal power-off processing flow. After multiple logic modules have completed their own abnormal power-off processing flows, a power-off completion flag is generated.
[0068] In some embodiments, the firmware scene includes multiple logical parts, each logical part is divided into one or more data sub-blocks, and the scene sub-blocks are generated according to the data sub-blocks.
[0069] In some embodiments, the logical portion includes one or more of the state of the registers within the core, the independent storage area data of the core, the fast storage shared between the cores, the slow storage shared between the cores, the stack information, the SQ or CQ queue, the Admin queue, the memory management information, the memory information, the other state information of the processor, the state information of the hardware accelerator, the cache contents, the communication queue between the cores and the shared memory between the cores.
[0070] In some embodiments, Figure 4 and Figure 5 As shown, each on-site sub-block contains:
[0071] Magic number, used to identify the new on-site sub-block;
[0072] Number, the number of the sub-block that the firmware is packaged into on-site;
[0073] The size of the on-site sub-block;
[0074] A data sub-block descriptor, used to describe information of data sub-blocks contained in the scene sub-block, including: a plurality of data sub-block descriptor entries, each data sub-block descriptor entry corresponding to one of the data sub-blocks;
[0075] Each data sub-block descriptor entry includes: a data sub-block type, which is used to describe that the data sub-block comes from a certain target (specific) logical part, and the logical part includes one or more of the following: intra-core register state, intra-core independent storage area data, inter-core shared fast storage, inter-core shared slow storage, stack information, SQ or CQ queue, Admin queue, memory management information, memory information, other processor status information, hardware accelerator status information, cache content, inter-core communication queue and inter-core shared memory;
[0076] The log area includes: the number of valid log entries, which indicates the number of valid log entries; the total number of log entries, which indicates the number of log entries, including valid and blank ones; the size of log entries, which is the same for each log entry; and the log entry area, which stores all log entries in equal size.
[0077] The data sub-block area is used to store multiple data sub-blocks, each data sub-block corresponds to one of the data sub-block descriptor entries.
[0078] In an optional implementation, the field sub-block includes more or less content. For example, the field sub-block includes multiple data sub-block descriptors and corresponding multiple data sub-blocks. The data sub-block descriptors correspond to the data sub-blocks one by one. The data sub-block descriptors are used to record the metadata of the corresponding data sub-blocks, for example, the type of firmware field recorded in the data sub-block. Optionally, the data sub-block descriptors have a specified size and are stored continuously; and the data sub-blocks also have a specified size and are stored continuously. This facilitates the acquisition of specified data sub-blocks in the field sub-block.
[0079] In some embodiments, when the control core determines that the power off is not completed, it determines the possibility of abnormal occurrence of each of the multiple logic modules according to the power off step numbers that have been completed by each of the multiple logic modules, and sorts them according to the possibility of abnormal occurrence to obtain a sorting result.
[0080] In some embodiments, after a predetermined time after detecting an abnormal power failure, the control core does not send interrupts to multiple processor cores and does not save the firmware scene based on the existence of a power failure completion flag, thereby eliminating the need to start an abnormal power failure processing flow.
[0081] In some embodiments, multiple processor cores each generate multiple on-site sub-blocks based on the corresponding data sub-blocks obtained from the interrupt, including: after each processor core receives the interrupt, it packs its own corresponding data sub-block into the corresponding on-site sub-block and adds marking information; after the control core generates its own corresponding on-site sub-block, it exits the interrupt processing process; after other processor cores that are not the control core generate their own corresponding on-site sub-blocks, they generate on-site sub-blocks including marking information from other data sub-blocks according to the sorting results, and exit the interrupt processing process.
[0082] Specifically, after receiving an interrupt, each processor core packs its own registers, independent storage areas in the core, and other data sub-blocks into the corresponding on-site sub-blocks, and writes a completion mark when the on-site sub-block is completed. Except for the control core, after each processor core completes its own on-site sub-block, it saves the remaining on-site sub-blocks that are ranked first (that is, the remaining most important) according to the sorting results, and writes a completion mark when the on-site sub-block is completed, until all on-site sub-blocks are completed and the interrupt is exited. After completing its own on-site sub-block (including writing the completion mark), the control core directly exits the interrupt.
[0083] In the disclosed embodiment, a target area may be determined in advance in a persistent storage medium space, and each on-site sub-block may be stored in the target area in order according to the abnormality probability ranking results of each on-site sub-block, for example, from the highest abnormality probability to the lowest.
[0084] In the disclosed embodiment, a fixed-size continuous space in a persistent storage medium space is obtained, and the fixed-size continuous space is divided into a plurality of fixed-size regions, and a target region is determined from the plurality of fixed-size regions. The target region is used to record the on-site sub-blocks written into the persistent storage medium space. A target sequence number corresponding to the target region is obtained, and the target sequence number is stored in a target position of the persistent storage medium space when the abnormal power-off process is completed, so that the target sequence number can be obtained from the target position when the storage device is powered on next time, and the saved firmware scene can be found.
[0085] Specifically, the firmware selects a continuous space of a fixed size from the persistent storage medium space, divides the space into multiple fixed-size areas, selects an empty area from it, and records the serial number of the selected area to the target serial number as the 'dirty area serial number'. When the abnormal power-off process is completed normally, the 'dirty area serial number' will be saved to the target location of the persistent storage medium.
[0086] It should be understood that during the abnormal power failure processing, the backup power supply cannot always ensure that the target serial number is written to the target location. Therefore, when the storage device is powered on, it searches for the previously saved firmware scene in a variety of ways. Reading the 'dirty area serial number' at the target location to obtain the saved firmware scene is one of the ways. If the 'dirty area serial number' is not successfully saved, it can be identified whether the firmware scene is stored in the area by traversing each area of the fixed-size continuous space of the persistent storage medium space. In each area, the location of the target data block should be recorded to find out whether there is data that meets the characteristics of the target data block, so as to identify whether the area stores the firmware scene.
[0087] In an embodiment of the present disclosure, a control core stores part or all of a plurality of on-site sub-blocks to a target area of a persistent storage medium space based on a sorting result of sorting a plurality of on-site sub-blocks according to the probability of occurrence of an exception, including: dividing each on-site sub-block into small data blocks of a fixed size, and adding description information to each small data block to obtain a target data block, and storing all target data blocks in sequence to the target area according to the sorting result; wherein, after each target data block is stored, a power-off completion flag is detected, and when it is determined based on the power-off completion flag that the power-off is completed, the operation of storing part or all of the plurality of on-site sub-blocks to the target area of the persistent storage medium space is terminated, and when it is determined based on the power-off completion flag that the power-off is not completed, the storage operation of storing part or all of the plurality of on-site sub-blocks to the target area of the persistent storage medium space is continued.
[0088] Specifically, after exiting the interrupt, the control core processes multiple on-site sub-blocks in series according to the sorting result: divides the aforementioned selected target area into multiple sub-areas of fixed size, and each sub-area is divided into multiple blocks of fixed size; waits for the on-site sub-blocks to be saved in the buffer; divides the on-site sub-blocks into small data blocks of fixed size, and adds a description information to each small data block, the description information includes the identifier and sequence number of the data block, and the size of the 'small data block + data description' is equal to the size of the aforementioned sub-area of fixed size; stores all 'small data blocks + data description' one by one in order into the aforementioned selected area; after storing each small data block, the power-off completion flag will be checked, and if the power-off has been completed, the process will be terminated, and the remaining small data blocks will no longer be saved, and the remaining other on-site sub-blocks will no longer be processed.
[0089] In this application, in order to save key content in the shortest time, the firmware scene is first divided according to logical relationships, and then the divided logical parts are divided into data sub-blocks in the form of limiting data size; the data sub-blocks are then supplemented with necessary information, packaged into numbered scene sub-blocks, and placed in a buffer. After that, each scene sub-block is stored in a persistent storage medium in order from high to low importance. In this way, even if the short-term internal power supply of the storage device ends prematurely, the most important part can be retained as much as possible for subsequent investigation and analysis.
[0090] It should be noted that if there are multiple data sub-blocks in a certain live sub-block, they can also be stored from front to back according to the importance, such as the most important register is placed first, etc. In this way, even if the live sub-block is not saved completely, important debugging information can be restored as much as possible from one or more successfully saved data sub-blocks.
[0091] Figure 6 This is an example diagram of the process of saving firmware on-site according to an embodiment of the present disclosure.
[0092] Step 4.1: After detecting an abnormal power failure, start the timer. The time period can be set according to the average time it takes for each processor core to complete the abnormal power failure process, and the timer can be set according to the time period.
[0093] Step 4.2: Determine whether the timer has reached the timing time; if not, continue to step 4.2; if yes, proceed to step 4.3.
[0094] Step 4.3, determine whether the power-off process has been completed. Specifically, the control core in the multiple processor cores detects the power-off completion flag. If the power-off completion flag does not exist, it means that the power-off process has not been completed, and execute step 4.4.
[0095] Step 4.4, the control core selects an empty area from the persistent medium storage space, and stores the area serial number in the 'dirty area serial number'. Specifically, the control core obtains a fixed-size continuous space in the persistent storage medium space, divides the fixed-size continuous space into multiple fixed-size areas, determines the target area from the multiple fixed-size areas, and obtains the target serial number corresponding to the target area as the 'dirty area serial number', and stores the target serial number to the target position of the persistent storage medium space when the abnormal power-off process is completed.
[0096] Step 4.5, the control core in the multiple processor cores sorts the on-site sub-blocks according to their importance. Specifically, when the control core determines that the power-off is not completed, it determines the possibility of abnormal occurrence of each of the multiple logic modules according to the power-off step numbers that have been completed by each of the multiple logic modules, sorts them according to the possibility of abnormal occurrence, obtains the sorting result, and sorts the multiple on-site sub-blocks according to the importance according to the sorting result.
[0097] Step 4.6 The control core issues interrupts to multiple processor cores (including itself).
[0098] In response to the interrupt, each processor core executes a portion of steps 4.7 to 4.12.
[0099] Step 4.7: Each processor core packs its own registers, independent storage within the core, and other data sub-blocks into the corresponding on-site sub-blocks. Specifically, after receiving an interrupt, each processor core packs its own corresponding data sub-blocks into the corresponding on-site sub-blocks and adds marking information.
[0100] Step 4.8 determines whether the processor core executing the current processing flow is itself a control core; if not, execute step 4.9.
[0101] Step 4.9, determine whether there are any unfinished on-site sub-blocks; if not, execute step 4.10 to exit the interrupt; if there are any unfinished on-site sub-blocks, execute step 4.11.
[0102] Step 4.11, process the top-ranked on-site sub-blocks. After generating their own corresponding on-site sub-blocks, other processor cores that are not control cores generate on-site sub-blocks including tag information for other data sub-blocks according to the ranking results. After generating on-site sub-blocks, these processor cores return to step 4.9 to determine whether there are on-site sub-blocks to be generated.
[0103] In step 4.8, if it is the control core, execute step 4.12 to exit the interruption; specifically, after the control core generates its own corresponding field sub-block, it exits the interruption processing process and continues to execute steps 4.13-4.17. Steps 4.13-4.17 are executed by the control core, and other processor cores do not execute these steps.
[0104] Step 4.13, the control core determines whether there are on-site sub-blocks that have not been saved to the persistent storage medium; if so, execute step 4.14. Otherwise, the abnormal power failure processing flow ends. Optionally, if there are no on-site sub-blocks that have not been saved to the persistent storage medium, the target sequence number is also written to the target location, or the target sequence number is written to the target location through step 4.20.
[0105] Step 4.14, the control core determines whether the top-ranked on-site sub-block that has not been saved is completed; if not, continue to execute step 4.14 to wait for the top-ranked on-site sub-block to appear; if yes, execute step 4.15. It should be understood that in step 4.14, the control core loops through step 4.14 to wait for the top-ranked on-site sub-block to appear. At this time, other processor cores may be executing step 4.11 to generate on-site sub-blocks. After the control core waits for the top-ranked on-site sub-block to appear in step 4.14, it turns to step 4.15 and subsequent steps to write the top-ranked on-site sub-block to the persistent storage medium. It is still necessary to understand that there can be multiple top-ranked on-site sub-blocks, and the control core does not need to wait for all the top-ranked on-site sub-blocks to be completed in step 4.14, but after the top-ranked on-site sub-block appears, it writes these on-site sub-blocks to the persistent storage medium through step 4.15 and subsequent steps.
[0106] Step 4.15, the control core divides the on-site sub-block into small data blocks; Step 4.16 adds description information to the small data blocks and saves them to the area corresponding to the "dirty area sequence number"; Step 4.17 determines whether there are any unsaved small data blocks; if yes, execute step 4.16; if not, execute step 4.13. It should be understood that the reason for returning to step 4.13 here is that other processor cores outside the control core may still be executing step 4.11 and generating further on-site sub-blocks. These newly appeared on-site sub-blocks are processed by returning to step 4.13.
[0107] In addition, after step 4.1, step 4.18 is included in which each logic module starts to process abnormal power-off; step 4.19 is included in which the control core determines whether the power-off process is completed normally; if so, step 4.20 is executed to save the 'dirty region sequence number' to a persistent storage medium.
[0108] It can be understood that the condition of triggering the firmware scene saving is that the power-off processing is not completed within the specified time. During the firmware scene saving, the firmware still continues the power-off processing process normally. The action of saving the scene does not affect the normal logical operation of the firmware. Once the power-off processing process is completed normally, the action of saving the firmware scene will be terminated, and the permanent storage medium space used by it can also be recycled and continued to be used, further improving the flexibility of saving the firmware scene for abnormal power off.
[0109] The embodiment of the present disclosure provides a firmware on-site solution for abnormal power failure. When an abnormal power failure is detected, the control core among multiple processor cores detects the power failure completion flag after a predetermined time after the abnormal power failure is detected. If the power failure completion flag does not exist, the control core sends an interrupt to the multiple processor cores. The multiple processor cores each obtain the corresponding data sub-block based on the interrupt to generate a field sub-block, and obtain multiple field sub-blocks. The control core stores part or all of the multiple field sub-blocks to the target area of the persistent storage medium space based on the sorting result of sorting the multiple field sub-blocks according to the probability of the abnormal occurrence. With the above technical solution, when the device has a power failure exception, the key information of the firmware field can be retained, so that the problem can be quickly located based on the saved field data, greatly improving the debugging efficiency.
[0110] It can also be understood that after powering on again after an abnormal power outage, the firmware can identify whether the last power-off process ended normally; if the last power outage ended normally, the firmware reads the 'dirty area sequence number' from the target location of the permanent storage medium. If the sequence number is a legal area sequence number, it means that part or all of the on-site sub-block data may be written to the area. The firmware erases the area. After the erasure is completed, the area can continue to be used at runtime; if the last power outage did not end normally, the host side will sense that the storage device is lost or the storage device is in an abnormal mode. At this time, in order to debug the storage device, the on-site sub-block data can be read to restore the abnormal scene.
[0111] In some embodiments, after an abnormal power failure, the method further includes: when detecting that the storage device is powered on, if it is identified that the abnormal power failure process did not end normally when the storage device was powered off last time, querying from a fixed-size continuous space to obtain the firmware scene saved when the storage device was powered off last time, and setting a target index corresponding to the firmware scene so that the host can read the firmware scene based on the target index.
[0112] Therefore, the present application realizes that after an abnormal power failure occurs in a storage device, the most critical firmware field information for debugging can be saved in a short time. Moreover, even if the firmware field is not saved completely, debugging and analysis can be performed, so that when a power failure occurs, the key information of the firmware field can be preserved, and the problem can be quickly located based on the saved field data, which greatly improves the efficiency of debugging the storage device.
[0113] Figure 7 The present invention provides a schematic diagram of a device for storing firmware in the event of abnormal power failure. The device can be implemented by software and / or hardware and can generally be integrated into an electronic device. Figure 7 As shown, the device comprises:
[0114] The detection module 401 is used to detect abnormal power failure.
[0115] The sending module 402 is used for a control core among the multiple processor cores to detect a power-off completion flag after a predetermined time after detecting abnormal power-off. If the power-off completion flag does not exist, the control core sends an interrupt to the multiple processor cores.
[0116] The generating module 403 is used for each of the multiple processor cores to generate a local sub-block based on the interruption and obtain the corresponding data sub-block to obtain multiple local sub-blocks.
[0117] The storage module 404 is used for the control core to store part or all of the multiple on-site sub-blocks into a target area of the persistent storage medium space based on the sorting result of the multiple on-site sub-blocks according to the probability of abnormality occurrence.
[0118] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0119] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a unit does not, in some cases, limit the unit itself.
[0120] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.
[0121] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0122] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.
[0123] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.
[0124] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.
Claims
1. A method for saving firmware on-site during abnormal power failure, characterized in that: Applicable to storage devices, including: Abnormal power failure is detected; A control core among the plurality of processor cores detects a power-off completion flag after a predetermined time after detecting abnormal power-off, and if the power-off completion flag does not exist, the control core sends an interrupt to the plurality of processor cores; The multiple processor cores each acquire a corresponding data sub-block based on the interrupt to generate a field sub-block, thereby obtaining multiple field sub-blocks; The control core stores part or all of the multiple on-site sub-blocks in a target area of a persistent storage medium space based on a sorting result of sorting the multiple on-site sub-blocks according to the probability of abnormality occurrence.
2. The method according to claim 1, characterized in that: The method further comprises: A preset time greater than an average duration is set, wherein the average duration is determined based on a plurality of historical durations for the storage device to complete power-off processing.
3. The method according to claim 1, characterized in that: The firmware includes a plurality of logic blocks running on the plurality of processor cores; The power-off completion flag includes a power-off completion flag generated by one or more of the plurality of logic blocks; determining a possibility of an abnormality occurring in one or more of the plurality of logic blocks based on a power-off completion flag generated by one or more of the plurality of logic blocks; or, The possibility of abnormality occurrence of one or more of the plurality of logic blocks is determined based on the historical abnormality occurrence of one or more of the plurality of logic blocks.
4. The method according to claim 3, characterized in that: Sorting the current process of abnormal power failure processing of each logic module in the firmware according to the process progress, and setting the abnormal possibility ranking of each logic module in the firmware according to the sorting result; and / or, The abnormality possibility of each logic module in the firmware is set according to the firmware field content processed by each logic module in the firmware.
5. The method according to claim 1, characterized in that: In response to detecting the abnormal power failure, each of the processor cores processes its own abnormal power failure processing flow in parallel, and the multiple processor cores suspend their own abnormal power failure processing flow in response to the interruption, generate the multiple field sub-blocks, and then resume processing their own abnormal power failure processing flow.
6. The method according to claim 1, It is characterized in that The firmware includes a plurality of logic modules running on the plurality of processor cores, and the abnormal power-off processing flow of each logic module includes a plurality of power-off steps; The method further includes, in response to detecting the abnormal power failure, each of the logic modules executing its own abnormal power failure processing flow, and recording the number of the power failure step that has been executed in executing its own abnormal power failure processing flow; The power-off completion flag is generated after the plurality of logic modules have completed their own abnormal power-off processing procedures.
7. The method according to claim 1, characterized in that: The firmware scene includes multiple logical parts; Each of the logical portions is divided into one or more data sub-blocks; The live sub-block is generated according to the data sub-block.
8. A field device for preserving firmware during abnormal power failure, characterized in that: Applicable to storage devices, including: A detection module, used to detect abnormal power failure; A sending module, used for a control core among the multiple processor cores to detect a power-off completion flag after a predetermined time after detecting abnormal power-off, and if the power-off completion flag does not exist, the control core sends an interrupt to the multiple processor cores; A generating module, configured for each of the plurality of processor cores to generate a field sub-block based on the interruption-acquired corresponding data sub-block, thereby obtaining a plurality of field sub-blocks; A storage module is used for the control core to store part or all of the multiple on-site sub-blocks into a target area of a persistent storage medium space based on a sorting result of sorting the multiple on-site sub-blocks according to the probability of abnormality occurrence.
9. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the executable instructions to implement the on-site method for saving firmware for abnormal power failure described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that: The storage medium stores a program, and the program is used to execute the on-site method for saving firmware during abnormal power failure described in any one of claims 1 to 7.
Citation Information
Patent Citations
Method for data storage during abnormal power down of computer
CN104035893A
Power-down data storage and recovery algorithm prolonging service life of non-volatile memory
CN104317671A
Method and device for data storage, and terminal
CN105512056A
Watchdog timeout restart field capture system, method and device and storage medium
CN114756832A
Method for storing effective debugging information of firmware and obtaining reconstruction error site
CN115220947A
Cited By
Method for firmware context preservation in event of unexpected power loss, and method for firmware context acquisition
WO2026124207A1