Method and apparatus for saving firmware debug information when a storage device is abnormally powered down

Abstract

The present disclosure relates to a method, device, equipment and medium for saving firmware live in abnormal power-off, wherein the method comprises: detecting abnormal power-off, a control core in a plurality of processor cores detecting a power-off completion flag after a predetermined time of detecting abnormal power-off, if the power-off completion flag does not exist, the control core sending an interrupt to the plurality of processor cores, each of the plurality of processor cores generating a live sub-block based on the interrupt to obtain a plurality of live sub-blocks, and the control core storing part or all of the plurality of live sub-blocks to a target area of a persistent storage medium space based on a sorting result of sorting the plurality of live sub-blocks according to the possibility of abnormal occurrence. By using the above technical solution, when the equipment has power-off abnormality, the key information of the firmware live can be saved, so that the problem can be quickly located according to the saved live data, and the debugging efficiency is greatly improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, device and medium for on-site processing of firmware preservation during abnormal power loss. Background Technology

[0002] Figure 1 A block diagram of a solid-state storage device (SSD) is shown. The SSD 102 is coupled to a host computer to provide storage capabilities. The host computer and the SSD 102 can be coupled in various ways, including but not limited to connections via 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), NVMe (NVM Express), Ethernet, Fibre Channel, and wireless communication networks. The host computer can be an information processing device capable of communicating with the storage device via the above methods, such as a personal computer, tablet computer, server, laptop computer, network switch, router, cellular phone, or personal digital assistant. Storage device 102 includes interface 103, control unit 104, one or more NVM chips 105, and DRAM (Dynamic Random Access Memory) 110.

[0003] NAND flash memory, phase change memory, FeRAM (Ferroelectric RAM), MRAM (Magnetic Random Access Memory), and RRAM (Resistive Random Access Memory) are common types of NVM.

[0004] Interface 103 is compatible with exchanging data with the host via methods such as SATA, IDE, USB, PCIe, NVMe, SAS, Ethernet, and Fibre Channel.

[0005] The control unit 104 is used to control data transfer between the interface 103, the NVM chip 105, and the DRAM 110. It is also used for memory management, host logical address to flash physical address mapping, erase leveling, bad block management, etc. The control unit 104 can be implemented in various ways, including software, hardware, firmware, or a combination thereof. For example, the control unit 104 can be in the form of an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a combination thereof. The control unit 104 may also include a processor or controller, in which software executes to manipulate the hardware of the control unit 104 to process I / O (Input / Output) commands. The control unit 104 can also be coupled to the DRAM 110 and can access the data in the DRAM 110. FTL tables and / or cached I / O command data can be stored in the DRAM.

[0006] The control unit 104 includes a flash interface controller (or media interface controller, flash channel controller), which is coupled to the NVM chip 105 and issues commands to the NVM chip 105 in accordance with the interface protocol of the NVM chip 105 to operate the NVM chip 105, and receives the command execution results output from the NVM chip 105. Known NVM chip interface protocols include "Toggle", "ONFI", etc.

[0007] Typically, when a storage device experiences an external power outage, it needs to save the currently cached I / O data and various metadata used by the firmware (such as FTL tables) to the NVM chip. For this purpose, components such as capacitors are usually used as backup power to provide the storage device with a brief period of internal power. However, this time is often very short, and the amount of data that can be saved is limited. Therefore, the firmware needs a relatively complex abnormal power failure handling process to achieve the goal of saving all the necessary data within a short period.

[0008] However, the complex abnormal power-down handling process leads to a higher firmware failure rate. To detect and resolve these firmware failures, it is necessary to analyze the firmware's operational status at the time of the failure. However, during an abnormal power-down, the backup power supply can only provide power for a very short time, which limits the methods for investigating firmware failures, such as online debugging. Therefore, the firmware needs to save its state within a very short time, or retain as much critical content as possible, so that it can be accessed externally for debugging upon the next power-up. Summary of the Invention

[0009] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a method, apparatus, device, and medium for saving firmware in the field during abnormal power loss.

[0010] This disclosure provides a method for saving firmware state during abnormal power loss, applied to a storage device, comprising: detecting an abnormal power loss; after a predetermined time following the detection of the abnormal power loss, a control core among multiple processor cores detects a power loss completion flag; if the power loss completion flag does not exist, the control core sends an interrupt to the multiple processor cores; each of the multiple processor cores obtains a corresponding data sub-block based on the interrupt to generate a state sub-block, resulting in multiple state sub-blocks; the control core stores part or all of the multiple state sub-blocks to a target area of ​​a persistent storage medium space based on a sorting result of the multiple state sub-blocks according to the probability of the abnormality occurring.

[0011] This disclosure also provides a firmware field storage device for abnormal power loss, applied to a storage device. The device includes: a detection module for detecting abnormal power loss; a sending module for a control core among multiple processor cores to detect a power loss completion flag after a predetermined time has elapsed since the abnormal power loss was detected, and if the power loss completion flag is not present, the control core sends an interrupt to the multiple processor cores; a generation module for each of the multiple processor cores to generate a field sub-block based on the corresponding data sub-block obtained from the interrupt, resulting in multiple field sub-blocks; and a storage module for the control core to store part or all of the multiple field sub-blocks to a target area of ​​a persistent storage medium space based on a sorting result of the multiple field sub-blocks according to the probability of the abnormality occurring.

[0012] This disclosure also provides an electronic device, the electronic device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the executable instructions to implement the firmware saving method for abnormal power failure provided in this disclosure.

[0013] This disclosure also provides a computer-readable storage medium storing a computer program for executing the firmware saving method for abnormal power loss as provided in this disclosure.

[0014] This disclosure also provides a computer program product, including a computer program, wherein the computer program is executed by a processor as described in this disclosure, a method for saving firmware state during abnormal power loss.

[0015] The technical solution provided in this disclosure has the following advantages compared with the prior art: The firmware state-of-the-art solution for abnormal power loss provided in this disclosure detects an abnormal power loss. After a predetermined time has elapsed since the detection of the abnormal power loss, the control core among multiple processor cores checks for a power loss completion flag. If the power loss completion flag is absent, the control core sends an interrupt to the multiple processor cores. Each processor core then obtains its corresponding data sub-block based on the interrupt and generates a state sub-block. The control core then stores part or all of the state sub-blocks in a target area of ​​the persistent storage medium space based on a sorting result according to the probability of the abnormality. Using this technical solution, when a power loss occurs, key information in the firmware state can be preserved, allowing for rapid problem location based on the saved state data, greatly improving debugging efficiency. Attached Figure Description

[0016] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote 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 This is a schematic diagram of a solid-state storage device; Figure 2 A structural block diagram of a Koyota storage device provided in an embodiment of this disclosure; Figure 3 A flowchart illustrating a method for saving firmware in case of abnormal power failure, provided in an embodiment of this disclosure; Figure 4 Example diagram of firmware being divided into field sub-blocks according to embodiments of this disclosure; Figure 5 Example diagram of the field sub-block structure provided in the embodiments of this disclosure; Figure 6 A flowchart illustrating the firmware on-site saving process provided in this embodiment of the disclosure; Figure 7 This is a schematic diagram of a field device for saving firmware during abnormal power loss, provided as an embodiment of the present disclosure. Detailed Implementation

[0018] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0020] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based 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". Definitions of other terms will be given in the description below.

[0021] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0022] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0023] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0024] Based on the aforementioned background technology description, Figure 2 This is a block diagram representing a typical storage device using embodiments of the present disclosure. Figure 2 Too Figure 1 Detailed block diagram of control component 104.

[0025] The control unit 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 that runs on that 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 firmware execution. The software running in the embedded device is commonly referred to as firmware.

[0026] The control unit also includes cache / shared memory. The shared memory can be used by the processor core.

[0027] The control unit also includes SRAM, which is mainly used as a cache to store I / O data. In this application, it is also used to store the field sub-blocks generated by each processor core.

[0028] The processor cores can communicate with each other. This can be done through inter-core queues (not shown) or shared memory.

[0029] The processor cores are divided into tasks. One core is selected as the control core.

[0030] Typically, firmware running on a single 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 viewed as different pieces of firmware that can run concurrently. For example, a logic module is a process, thread, or coroutine.

[0031] Firmware context: For subsequent debugging purposes, the firmware context that the processor core / logic module needs to save includes various state information during abnormal power loss, mainly including: register state, core independent memory area data, inter-core shared fast memory area data, inter-core shared slow memory area data, stack information, SQ / CQ queue, Admin queue, memory management information, memory information, other processor state information, hardware accelerator state information, cache contents, inter-core communication queue, inter-core shared memory, etc.

[0032] Memory information: This mainly includes the memory usage of the application, including the stack, code segment, data segment, and heap.

[0033] Register state: contains the values ​​of the processor core's architecture registers when the program crashes, such as the program pointer and stack pointer.

[0034] Stack information: including the stack pointer and function call stack information, which helps to locate the function call chain when the program crashes.

[0035] Memory management information: This information pertains to the program's memory allocation and usage, and can help in detecting issues such as memory leaks.

[0036] Other processor and operating system status information: In addition to memory information, there are some key program running statuses.

[0037] The firmware context primarily resides in the registers within the processor core, the memory corresponding to the processor core, and also includes the contents of inter-core queues, SQCQ, and / or AdminQ defined by the NVMe protocol. The state of the flash channel controller can also serve as the firmware context. The flash channel controller is used to operate NAND flash memory.

[0038] Externally connected to the control unit are backup power supplies, DRAM, and multiple NAND flash memory modules.

[0039] The backup power supply provides brief power during abnormal power outages, enabling control components to execute procedures to handle such outages. Its power supply duration is 10-20 ms.

[0040] NAND flash memory is a "persistent storage medium." Its storage space is divided into two parts: one part stores user data (related to I / O commands), and the other part stores system data. A portion of the system data storage space is reserved as the "persistent storage medium space" for the storage field sub-blocks of this invention. This space is further divided into multiple areas. The field sub-block is to be written to one or more of these areas.

[0041] The main function of a backup power supply is to write user data cached in SRAM or DRAM to NAND flash memory during an abnormal power outage. Storing field sub-blocks is an additional requirement for it. Therefore: (1) The backup power supply is unreliable for storing field sub-blocks, so it is necessary to optimize the process of storing field sub-blocks, including multi-core collaborative work, avoiding affecting the normal abnormal power outage process, and prioritizing the storage of more important field sub-blocks; (2) The backup power supply is used to store not only field sub-blocks, but also other data.

[0042] Each processor core generates several context subblocks. These are further divided into context subblocks that can only be generated by the processor core itself, and context subblocks that can be generated by any processor core. For the processor core's internal registers and its own dedicated memory, this information is known only to the processor core, and these context subblocks can only be generated by the core itself. However, for content such as SQ / CQ, any processor core can access and generate the corresponding context subblocks.

[0043] The method for saving firmware context during abnormal power failure proposed in this disclosure involves detecting an abnormal power failure. After a predetermined time following the detection of the abnormal power failure, the control core among multiple processor cores checks for a power failure completion flag. If the flag is absent, the control core sends an interrupt to the multiple processor cores. Each processor core retrieves its corresponding data sub-block based on the interrupt, generating a context sub-block. The control core then stores part or all of the context sub-blocks in a target area of ​​persistent storage medium based on a sorting result according to the probability of the abnormality. This technical solution enables the saving of critical context in a very short time in the event of a failed abnormal power failure process, and allows for external access and context restoration for maximum debugging after the next power-on, thereby significantly improving debugging efficiency.

[0044] Figure 3 This is a flowchart illustrating a method for saving firmware state during abnormal power loss, provided by an embodiment of this disclosure. Figure 3 As shown, this method is applied to a storage device and includes: Step 201: An abnormal power outage was detected.

[0045] Step 202: After a predetermined time has elapsed since the abnormal power failure was detected, the control core among the multiple processor cores checks the power failure completion flag. If the power failure completion flag is not present, the control core sends an interrupt to the multiple processor cores.

[0046] Specifically, the storage device is connected to the host. Normally, the user shuts down the host via buttons or the operating system. During the shutdown process, the host notifies the storage device to power down, and the host provides sufficient power to the storage device during this time, allowing it enough time to complete the power-down process.

[0047] In this embodiment of the disclosure, abnormal power failure refers to an event in which the storage device loses power because the user does not perform a normal power-off operation using the power button or other similar means.

[0048] In some embodiments, a preset time longer than the average duration is set, wherein the average duration is determined based on multiple historical durations during which the storage device completes a power outage process.

[0049] Specifically, if the preset time is slightly longer than normal (such as the average duration of the power-down completion flag), each processor core can complete the abnormal power-down process. Thus, by checking the power-down completion flag after the preset time, if it is not present, it indicates that one or more logic modules have a problem. Only then is it meaningful to save the firmware state.

[0050] It should be noted that the preset time can also be set according to the actual application needs. For example, a timer with a fixed time can be set to check the power-off completion flag when the timer expires. The power-off completion flag is used to indicate that the power-off is complete.

[0051] In this embodiment, the firmware includes multiple logical modules running on multiple processor cores. Each logical module's own abnormal power-down handling process includes multiple power-down steps. In response to detecting an abnormal power-down, each logical module executes its own abnormal power-down handling process and records the completed power-down step numbers during the execution of its own abnormal power-down handling process. After multiple logical modules have completed their own abnormal power-down handling processes, a power-down completion flag is generated. Thus, each logical module in the firmware divides the power-down handling process into multiple sub-steps, records the completed sub-step numbers in real time, analyzes the probability of each logical module experiencing an anomaly based on the completed sub-step numbers of each logical module and the logical dependencies between sub-steps, and sorts the logical modules according to the probability of an anomaly. Subsequently, the on-site data of logical modules with a higher probability of an anomaly can be saved first, further ensuring the efficiency and effectiveness of subsequent debugging.

[0052] If the power-down completion flag is not detected (i.e., the flag does not exist), the firmware needs to be saved in the current state. In other words, when an abnormal power-down begins, the firmware starts a timer with a fixed duration. At the end of the timer, it checks the power-down completion flag; if the flag is not present, the firmware saves the current state. It should be noted that the abnormal power-down handling procedures for each logic module continue to run.

[0053] The firmware state saving process can be initiated by the control core sending an interrupt to multiple processor cores (including the control core) to notify them to save the firmware state. Depending on the application requirements, one of the processor cores can be designated as the control core, and the remaining processor cores can perform corresponding operations based on the interrupts sent by the control core.

[0054] Step 103: Each of the multiple processor cores obtains the corresponding data sub-block based on the interrupt and generates a field sub-block, resulting in multiple field sub-blocks.

[0055] Step 104: Based on the sorting results of multiple field sub-blocks according to the probability of anomaly occurrence, the control kernel stores part or all of the multiple field sub-blocks into the target area of ​​the persistent storage medium space.

[0056] In this embodiment, after receiving an interrupt, each processor core packages its corresponding data sub-block into a corresponding context sub-block and writes a completion marker when the context sub-block packaging is complete. After the control core generates its own context sub-block, it exits the interrupt. Each core not acting as the control core, after generating its own context sub-block, also assists in handling any incomplete packaging from data sub-blocks to context sub-blocks. After exiting the interrupt, the control core sorts the context sub-blocks according to the probability of an exception and stores some or all of the context sub-blocks in the target area of ​​the persistent storage medium.

[0057] The firmware includes multiple logical modules running on multiple processor cores. The power-down completion flags include one or more logical power-down completion flags generated by these logical modules. The likelihood of anomalies occurring in one or more of these logical modules is determined based on these generated logical power-down completion flags; or, the likelihood of anomalies occurring in one or more of these logical modules is determined based on historical anomaly occurrences in these logical modules. In other words, if the abnormal power-down handling process progresses slower than expected, there is a greater probability of a problem, and therefore, the firmware state needs to be saved first; or, based on experience or historical data, which logical modules are more likely to fail during abnormal power-downs can be identified.

[0058] In some embodiments, the abnormal power-down handling process of each logical module in the firmware is sorted according to its current progress, and the abnormal probability of each logical module in the firmware is sorted according to the sorting result; and / or, the abnormal probability of each logical module in the firmware is sorted according to the firmware context content processed by each logical module. That is, the order of the probability of anomalies is related to the logical module in a certain order. For example, if the abnormal power-down handling process is progressing slowly, it is more likely to have a problem, so the context sub-block corresponding to that logical module is placed first; the order of the probability of anomalies is also related to the firmware context content in a certain order. For example, register status and stack information are placed first, followed by memory information.

[0059] In some embodiments, in response to the detection of an abnormal power failure, each processing core processes its own abnormal power failure handling process in parallel. In response to an interrupt, multiple processor cores pause their own abnormal power failure handling process, generate multiple field sub-blocks, and then resume processing their own abnormal power failure handling process.

[0060] Specifically, the firmware includes multiple logical modules running on multiple processor cores. Each logical module's own abnormal power-down handling process includes multiple power-down steps. In response to the detection of an abnormal power-down, each logical module executes its own abnormal power-down handling process and records the number of the completed power-down step during the execution of its own abnormal power-down handling process. After multiple logical modules have completed their own abnormal power-down handling processes, a power-down completion flag is generated.

[0061] In some embodiments, the firmware context includes multiple logical modules, each of which is divided into one or more data sub-blocks, and context sub-blocks are generated based on the data sub-blocks.

[0062] In some embodiments, the logic module includes one or more of the following: in-core register state, independent memory area data of the core, inter-core shared fast memory, inter-core shared slow memory, stack information, SQ or CQ queue, Admin queue, memory management information, memory information, other processor state information, hardware accelerator state information, cache contents, inter-core communication queue, and inter-core shared memory.

[0063] In some embodiments, such as Figure 4 and Figure 5 As shown, each site sub-block contains: The magic number is used to identify new sub-blocks in the scene; Number, the number of the firmware packaged into field sub-blocks; Size of the field sub-block; A data subblock descriptor is used to describe information about the data subblocks contained in a field subblock, including: multiple data subblock descriptor entries, each data subblock descriptor entry corresponding to one of the data subblocks; Each data sub-block descriptor entry contains: the type of the data sub-block, which describes the logical module from which the data sub-block comes, including one or more of the following: in-core register status, in-core independent memory area data, inter-core shared fast memory, inter-core shared slow memory, stack information, SQ or CQ queue, Admin queue, memory management information, memory information, other processor status information, hardware accelerator status information, cache contents, inter-core communication queue, and inter-core shared memory; The log area includes: the number of valid log entries, indicating the number of valid log entries; the total number of log entries, indicating the total number of log entries, including valid and blank entries; the size of each log entry, with each log entry being the same size; and the log entry area, which stores all log entries in an equal-sized manner. The data sub-block area is used to store multiple data sub-blocks, each of which corresponds to one of the data sub-block descriptor entries.

[0064] In optional implementations, the field sub-block may include more or less content. For example, a field sub-block may include multiple data sub-block descriptors and corresponding data sub-blocks. Each data sub-block descriptor corresponds one-to-one with a data sub-block. The data sub-block descriptor is used to record metadata of the corresponding data sub-block, such as the type of firmware field recorded in the data sub-block. Optionally, the data sub-block descriptors have a specified size and are stored contiguously; the data sub-blocks also have a specified size and are stored contiguously. This facilitates the retrieval of a specific data sub-block within the field sub-block.

[0065] In some embodiments, when the control core determines that the power-down is not complete, it determines the probability of an anomaly occurring in each of the multiple logic modules based on the power-down step numbers that have been completed by each of the multiple logic modules, and sorts them according to the probability of an anomaly occurring to obtain a sorting result.

[0066] In some embodiments, after the control core detects a predetermined time of abnormal power failure, it does not send interrupts to multiple processor cores or save the firmware state based on the existence of a power failure completion flag, thus eliminating the need to initiate the abnormal power failure handling process.

[0067] In some embodiments, multiple processor cores each obtain corresponding data sub-blocks based on interrupts and generate multiple context sub-blocks, including: after each processor core receives an interrupt, it packages its own corresponding data sub-block into the corresponding context sub-block and adds marking information; after the control core generates its own corresponding context sub-block, it exits the interrupt handling process; after other processor cores that are not the control core generate their own corresponding context sub-blocks, they generate context sub-blocks including marking information from other data sub-blocks according to the sorting result, and then exit the interrupt handling process.

[0068] Specifically, upon receiving an interrupt, each processor core packages its own registers, internal independent memory areas, and other data sub-blocks into a corresponding context sub-block, and writes a completion flag when the context sub-block is completed. Except for the control core, after each processor core completes its own context sub-block, it takes the remaining uncompleted context sub-blocks, sorts them according to the order, and saves the most important ones (those that are still in the order of priority). It also writes a completion flag when the context sub-block is completed, until all context sub-blocks are completed, at which point it exits the interrupt. The control core, after completing its own context sub-block (including writing the completion flag), directly exits the interrupt.

[0069] In this embodiment of the disclosure, a target area can be determined in advance in the persistent storage medium space, and each field sub-block can be stored in the target area in order of its abnormal probability sorting result, such as from the abnormal probability in descending order.

[0070] In this embodiment, a fixed-size contiguous space in the persistent storage medium is obtained. This fixed-size contiguous space is divided into multiple fixed-size regions, and a target region is determined from these regions. The target region is used to record the context sub-blocks written to the persistent storage medium. A target sequence number corresponding to the target region is obtained, and this target sequence number is stored in a target location within the persistent storage medium when the abnormal power-down process is completed. This allows the storage device to retrieve the target sequence number from the target location upon the next power-on, thereby finding the saved firmware context.

[0071] Specifically, the firmware selects a continuous space of a fixed size from the persistent storage medium, divides this space into multiple regions of fixed size, selects an empty region, and records the sequence number of the selected region into the target sequence number as the 'dirty region sequence number'. When the abnormal power failure process is completed normally, the 'dirty region sequence number' will be saved to the target location in the persistent storage medium.

[0072] It's important to understand that during abnormal power loss handling, the backup power supply cannot always guarantee that the target sequence number will be written to the target location. Therefore, when the storage device powers on, it searches for the previously saved firmware context in various ways. One such method is to read the 'dirty region sequence number' at the target location to obtain the saved firmware context. If the 'dirty region sequence number' is not successfully saved, the firmware context can be identified by traversing each region of a fixed-size contiguous space in the persistent storage medium, recording the location of the target data block in each region, and searching for data matching the characteristics of the target data block.

[0073] In this embodiment of the disclosure, the control core stores part or all of the multiple field sub-blocks into a target area of ​​the persistent storage medium space based on the sorting result of sorting multiple field sub-blocks according to the probability of anomaly occurrence. This includes: dividing each field sub-block into small data blocks of a fixed size, adding descriptive information to each small data block to obtain target data blocks, and storing all target data blocks into the target area sequentially according to the sorting result; wherein, after each target data block is stored, a power failure completion flag is detected, and the operation of storing part or all of the multiple field sub-blocks into the target area of ​​the persistent storage medium space is terminated when the power failure completion flag is determined to be complete, and the storage operation of storing part or all of the multiple field sub-blocks into the target area of ​​the persistent storage medium space continues when the power failure completion flag is determined to be incomplete.

[0074] Specifically, after exiting the interrupt, the control core processes multiple field sub-blocks serially according to the sorting results: it divides the previously selected target area into multiple fixed-size sub-regions, and each sub-region into multiple fixed-size blocks; it waits for the field sub-blocks to be saved to the buffer; it divides the field sub-blocks into fixed-size small data blocks, adds a descriptive message to each small data block, the descriptive message including the data block's identifier and sequence number, and the size of 'small data block + data description' is equal to the size of the previously fixed-size sub-region; it stores all 'small data blocks + data description' sequentially into the previously selected area; after each small data block is stored, it checks the power-off completion flag, and if the power-off has been completed, it terminates the process, no longer saves the remaining small data blocks, and no longer processes the remaining field sub-blocks.

[0075] In this application, in order to save key content in the shortest time, the firmware is first divided according to logical relationships. Then, the divided logical modules are further divided into data sub-blocks with limited data size. The necessary information is then added to the data sub-blocks, packaged into numbered field sub-blocks, and placed in a buffer. After that, each field sub-block is stored in the persistent storage medium in descending order of importance. In this way, even if the internal power supply of the storage device is interrupted prematurely, the most important parts can be preserved for subsequent investigation and analysis.

[0076] It should be noted that if a context subblock contains multiple data subblocks, they can be stored sequentially according to their importance, such as placing the most important registers first. This way, even if the context subblock is not completely saved, important debugging information can still be recovered from one or more successfully saved data subblocks as much as possible.

[0077] Figure 6 A flowchart illustrating the firmware on-site saving process provided in this embodiment of the disclosure.

[0078] 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.

[0079] Step 4.2: Determine if the timer has reached its set time. If not, continue with step 4.2. If yes, proceed to step 4.3.

[0080] Step 4.3: Determine whether the power-down process has been completed. Specifically, the control core among multiple processor cores detects the power-down completion flag. If the power-down completion flag is not present, it means that the power-down process has not been completed, and proceed to step 4.4.

[0081] Step 4.4: The control core selects an empty region from the persistent storage medium storage space and stores the region number in the 'dirty region number'. Specifically, the control core obtains a fixed-size contiguous space in the persistent storage medium space, divides the fixed-size contiguous space into multiple fixed-size regions, determines the target region from the multiple fixed-size regions, obtains the target number corresponding to the target region as the 'dirty region number', and stores the target number in the target location of the persistent storage medium space when the abnormal power failure process is completed.

[0082] Step 4.5: The control cores in multiple processor cores sort the field sub-blocks according to their importance. Specifically, when the control core determines that the power failure is not complete, it determines the probability of anomalies occurring in each of the multiple logic modules based on the power failure step numbers that have been completed by each of the multiple logic modules, sorts them according to the probability of anomalies occurring, obtains the sorting results, and sorts the multiple field sub-blocks according to their importance based on the sorting results.

[0083] Step 4.6 The control core issues interrupts to multiple processor cores (including itself).

[0084] In response to the interrupt, each processor core executes a portion of steps 4.7 through 4.12.

[0085] Step 4.7 Each processor core packages its own registers, independent internal storage, and other data sub-blocks into the corresponding context sub-blocks. Specifically, after receiving an interrupt, each processor core packages its own data sub-blocks into the corresponding context sub-blocks and adds marking information. Step 4.8 Determine whether the processor core executing the current processing flow is itself the control core; if not, proceed to step 4.9.

[0086] Step 4.9: Determine if there are any unfinished sub-blocks in the field; if not, proceed to step 4.10 to exit the interruption; if there are unfinished sub-blocks in the field, proceed to step 4.11.

[0087] Step 4.11: Process the top-ranked field sub-blocks. Other processor cores, not acting as the control core, generate their own corresponding field sub-blocks and then generate field sub-blocks including tag information for the other data sub-blocks according to the ranking. After generating the field sub-blocks, these processor cores return to step 4.9 to determine if there are any more field sub-blocks to be generated.

[0088] In step 4.8, if the processor core is the control core, it executes step 4.12 to exit the interrupt process. Specifically, after the control core generates its corresponding context subblock, it exits the interrupt handling process and continues executing steps 4.13-4.17. Steps 4.13-4.17 are executed by the control core; other processor cores do not execute these steps.

[0089] Step 4.13: The control core determines whether there are any unsaved state sub-blocks to persistent storage. If so, proceed to step 4.14. Otherwise, the abnormal power failure handling process ends. Optionally, if there are no unsaved state sub-blocks to persistent storage, the target sequence number is written to the target location, or the target sequence number is written to the target location via step 4.20.

[0090] Step 4.14: The control core determines whether the unsaved, top-ranked context sub-blocks have been completed. If not, it continues with step 4.14 to wait for the top-ranked context sub-blocks to appear; if so, it proceeds to step 4.15. It's important to understand that in step 4.14, the control core repeatedly executes step 4.14 to wait for the top-ranked context sub-blocks to appear. During this time, other processor cores may be executing step 4.11, generating context sub-blocks. After waiting for the top-ranked context sub-blocks to appear in step 4.14, the control core proceeds to step 4.15 and subsequent steps to write the top-ranked context sub-blocks to the persistent storage medium. It's also important to understand that there can be multiple top-ranked context sub-blocks. The control core does not need to wait for all top-ranked context sub-blocks to complete in step 4.14; instead, it writes these context sub-blocks to the persistent storage medium as soon as they appear, through steps 4.15 and subsequent steps.

[0091] Step 4.15: The control core divides the context subblock into smaller data blocks; Step 4.16: Add descriptive information to the smaller data blocks and save them to the area corresponding to the 'dirty region number'; Step 4.17: Determine if there are any unsaved smaller data blocks; if yes, execute step 4.16; if no, execute step 4.13. It's important to understand that returning to step 4.13 is necessary because other processor cores outside the control core may still be executing step 4.11 and generating further context subblocks. Returning to step 4.13 allows for the processing of these newly generated context subblocks.

[0092] In addition, after step 4.1, there is step 4.18 where each logic module starts the abnormal power failure process; step 4.19 where the control core determines whether the power failure process is completed normally; if so, step 4.20 is executed to save the 'dirty region number' to the persistent storage medium.

[0093] Understandably, the failure to complete the power-down process within the specified time is used as the condition for triggering firmware state saving. During the firmware state saving process, the firmware continues the power-down process normally. The state saving action does not affect the normal operation of the firmware logic. Once the power-down process is completed normally, the firmware state saving action will stop, and the permanent storage medium space used can be reclaimed and reused, further improving the flexibility of saving firmware state for abnormal power-downs.

[0094] The firmware state preservation scheme for abnormal power loss provided in this embodiment detects an abnormal power loss. After a predetermined time following the detection of the abnormal power loss, the control core among multiple processor cores checks for a power loss completion flag. If the power loss completion flag is absent, the control core sends an interrupt to the multiple processor cores. Each processor core then retrieves its corresponding data sub-block based on the interrupt and generates state sub-blocks. The control core then stores some or all of these state sub-blocks in a target area of ​​persistent storage medium based on a sorting result according to the probability of the abnormality. Using this technical solution, when a device experiences a power loss anomaly, key information in the firmware state can be preserved. This allows for rapid problem localization based on the saved state data, significantly improving debugging efficiency.

[0095] It is also understandable that after an abnormal power outage and subsequent power-on, the firmware can identify whether the previous power outage process ended normally. If the previous power outage ended normally, the firmware reads the 'dirty region number' from the target location on the permanent storage medium. If the number is a valid region number, it means that some or all of the field sub-block data may have been written to that region. The firmware erases that region, and after erasure, the region can continue to be used during operation. If the previous power outage did not end normally, the host will detect that the storage device is lost or that the storage device is in an abnormal mode. At this time, for the purpose of debugging the storage device, the field sub-block data can be read to restore the abnormal situation.

[0096] In some embodiments, after an abnormal power failure, the method further includes: when the storage device is detected to be powered on, if it is identified that the abnormal power failure process did not end normally during the previous power failure of the storage device, querying from a fixed-size continuous space to obtain the firmware context saved during the previous power failure of the storage device, and setting a target index corresponding to the firmware context so that the host can read the firmware context based on the target index.

[0097] Therefore, this application enables the preservation of critical firmware information for debugging within a short period of time after an abnormal power outage of the storage device. Furthermore, even if the firmware information is not fully preserved, debugging and analysis can still be performed. This ensures that key firmware information is retained during power outages, allowing for rapid problem localization based on the saved data, significantly improving the efficiency of storage device debugging.

[0098] Figure 7 This is a schematic diagram of a field device for saving firmware during abnormal power loss, provided as an embodiment of this disclosure. This device can be implemented by software and / or hardware and is generally integrated into an electronic device. Figure 7 As shown, the device includes: The detection module 401 is used to detect abnormal power outages.

[0099] The sending module 402 is used to detect a power-down completion flag after a predetermined time has elapsed since the control core of the multiple processor cores detected the abnormal power-down. If the power-down completion flag does not exist, the control core sends an interrupt to the multiple processor cores.

[0100] The generation module 403 is used for each of the multiple processor cores to obtain a corresponding data sub-block based on the interrupt and generate a multiple field sub-block.

[0101] Storage module 404 is used by the control core to store part or all of the multiple field sub-blocks to a target area of ​​the persistent storage medium space based on the sorting result of the multiple field sub-blocks according to the probability of an anomaly occurring.

[0102] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0103] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0104] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0105] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0106] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0107] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0108] Although the subject matter has been described using language specific to structural features and / or methodological logic, 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. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for saving firmware in a field during abnormal power loss, characterized in that, Used in storage devices, including: An abnormal power outage was detected; After a predetermined time has elapsed since the abnormal power failure was detected, the control core among the multiple processor cores checks the power failure completion flag. If the power failure completion flag is not present, it indicates that the power failure process has not been completed, and the control core sends an interrupt to the multiple processor cores. Each of the multiple processor cores obtains a corresponding data sub-block based on the interrupt and generates a context sub-block, resulting in multiple context sub-blocks; wherein, after receiving an interrupt, each processor core packages its own corresponding data sub-block into the corresponding context sub-block; The control core sorts the multiple field sub-blocks according to the probability of anomalies occurring in each of the multiple logic modules, and stores some or all of the multiple field sub-blocks to the target area of ​​the persistent storage medium space according to the sorting result.

2. The method according to claim 1, characterized in that, The method further includes: A preset time longer than the average duration is set, wherein the average duration is determined based on multiple historical durations during which the storage device completes a power outage process.

3. The method according to claim 1, characterized in that, The firmware includes multiple logical modules running on the multiple processor cores; The power-down completion flag includes one or more power-down completion flags generated by the plurality of logic modules; The probability of an anomaly occurring in one or more of the multiple logic modules is determined based on one of the power-down completion flags generated by the multiple logic modules; or, The probability of one or more anomalies occurring in the multiple logic modules is determined based on the historical anomaly occurrence data of one or more of the multiple logic modules.

4. The method according to claim 3, characterized in that, The firmware is sorted according to the current process progress of abnormal power failure handling for each logical module, and the abnormal probability ranking of each logical module in the firmware is set according to the process progress ranking result; and / or, The probability of anomalies for each logical module in the firmware is set according to the firmware field content processed by each logical module in the firmware.

5. The method according to claim 1, characterized in that, In response to the detection of the abnormal power failure, each of the processor cores processes its own abnormal power failure handling process in parallel. In response to the interrupt, the multiple processor cores pause their own abnormal power failure handling process, generate the multiple field sub-blocks, and then resume their own abnormal power failure handling process.

6. The method according to claim 1, Its features are, The firmware includes multiple logical modules running on the multiple processor cores, and each logical module's own abnormal power-down processing flow includes multiple power-down steps. The method further includes, in response to detecting the abnormal power failure, each of the logic modules executes its own abnormal power failure handling process, and records the power failure step number that has been completed in the execution of its own abnormal power failure handling process; The power failure completion flag is generated after all the multiple logic modules have completed their own abnormal power failure handling processes.

7. The method according to claim 1, characterized in that, The firmware environment includes multiple logical modules; Each of the aforementioned logical modules is divided into one or more data sub-blocks; The field sub-block is generated based on the data sub-block.

8. The method according to claim 7, characterized in that, The logic module includes one or more of the following: in-core register status, independent memory area data of the core, inter-core shared fast memory, inter-core shared slow memory, stack information, SQ or CQ queue, Admin queue, memory management information, memory information, other status information of the processor, status information of the hardware accelerator, cache contents, inter-core communication queue, and inter-core shared memory.

9. The method according to claim 7, characterized in that, Each of the aforementioned field sub-blocks includes: A data subblock descriptor, used to describe information about the data subblocks contained in the field subblock, includes: multiple data subblock descriptor entries, each corresponding to one of the data subblocks; wherein, each data subblock descriptor entry includes: the type of the data subblock, used to describe the logical module from which the data subblock originates, the logical module including one or more of the following: in-core register status, in-core independent memory area data, inter-core shared fast memory, inter-core shared slow memory, stack information, SQ or CQ queue, Admin queue, memory management information, memory information, other processor status information, hardware accelerator status information, cache contents, inter-core communication queue, and inter-core shared memory; The data sub-block area is used to store multiple data sub-blocks, each of which corresponds to one of the data sub-block descriptor entries.

10. The method according to claim 6, characterized in that, The method further includes: When the control core determines that the power outage is not complete, it determines the probability of an anomaly occurring in each of the multiple logic modules based on the power outage step numbers that have been completed by each of the multiple logic modules. The anomalies are sorted according to their probability of occurrence to obtain the sorting result.

11. The method according to claim 10, characterized in that, After a predetermined time has elapsed since the abnormal power failure was detected, the control core neither sends an interrupt to the plurality of processor cores nor saves the firmware state, based on the presence of the power failure completion flag.

12. The method according to claim 1, characterized in that, Each of the multiple processor cores obtains a corresponding data sub-block based on the interrupt and generates a context sub-block, resulting in multiple context sub-blocks, including: After receiving the interrupt, each processor core packages its corresponding data sub-block into the corresponding field sub-block and adds marking information. After the control core generates its corresponding field sub-block, it exits the interrupt handling process. After generating its own corresponding field sub-block, other processor cores that are not the control core generate field sub-blocks including tag information from other data sub-blocks according to the sorting result, and then exit the interrupt handling process.

13. The method according to claim 12, characterized in that, After each processor core exits its interrupt handling process, it continues to execute its own abnormal power failure handling process.

14. The method according to claim 1, characterized in that, The method further includes: Obtain a fixed-size contiguous space in the persistent storage medium space; The fixed-size continuous space is divided into multiple fixed-size regions. The target region is determined from the multiple fixed-size regions, and the target sequence number corresponding to the target region is obtained. When the abnormal power failure handling process is completed, the target sequence number is stored in the target location of the persistent storage medium space.

15. The method according to claim 1, characterized in that, The control core stores part or all of the multiple field sub-blocks to a target area of ​​the persistent storage medium space based on the sorting result of the multiple field sub-blocks according to the probability of anomaly occurrence, including: Each of the aforementioned field sub-blocks is divided into small data blocks of fixed size, and descriptive information is added to each small data block to obtain the target data block; All target data blocks are stored sequentially in the target area according to the sorting result; wherein, after each target data block is stored, the power-down completion flag is detected, and if the power-down completion flag indicates that the power-down is complete, the operation of storing part or all of the multiple field sub-blocks in the target area of ​​the persistent storage medium space is terminated; and if the power-down completion flag indicates that the power-down is not complete, the operation of storing part or all of the multiple field sub-blocks in the target area of ​​the persistent storage medium space continues.

16. The method according to any one of claims 1-15, characterized in that, The method further includes: When the storage device is powered on, if it is detected that the abnormal power failure handling process of the storage device did not end normally during the previous power failure, the firmware state saved by the storage device during the previous power failure is obtained from a fixed-size continuous space. Set the target index corresponding to the firmware context so that the host can read the firmware context based on the target index.

17. A field device for saving firmware during abnormal power loss, characterized in that, Used in storage devices, including: The detection module is used to detect abnormal power outages; The sending module is used to detect a power-down completion flag after a predetermined time has elapsed since the control core of multiple processor cores detects an abnormal power-down. If the power-down completion flag does not exist, it means that the power-down process has not been completed, and the control core sends an interrupt to the multiple processor cores. A generation module is used for each of the multiple processor cores to generate a context sub-block based on the corresponding data sub-block obtained from the interrupt, resulting in multiple context sub-blocks; wherein, after receiving the interrupt, each processor core packages its own corresponding data sub-block into the corresponding context sub-block; The storage module is used by the control core to sort the multiple field sub-blocks according to the probability of each of the multiple logic modules' anomalies, and to store part or all of the multiple field sub-blocks to a target area of ​​the persistent storage medium space according to the sorting result.

18. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the firmware field saving method for abnormal power failure as described in any one of claims 1-16.

19. A computer-readable storage medium, characterized in that, The storage medium stores a program for executing the firmware preservation method for abnormal power loss as described in any one of claims 1-16.

Images