Firmware upgrade method, storage device and computer program product

Abstract

The embodiment of the application discloses a firmware upgrade method, a storage device and a computer program product. The firmware upgrade method comprises the following steps: after confirming that a firmware upgrade trigger command issued by a host is received, entering a firmware receiving preparation state; in response to a first write command issued by the host, judging whether a preset first logical block address specially used for identifying a firmware receiving request is carried in the first write command; if yes, performing a firmware receiving initialization operation, and entering a firmware data transmission state; otherwise, exiting a firmware upgrade state, and performing a write operation. The application can solve the problem that the firmware upgrade mode of the existing storage device is interrupted or blocked in the normal write operation in the firmware upgrade process in the host environment supporting only general read and write commands, and the continuity of the host service is affected.

Description

Technical Field

[0001] This application relates to the field of storage device technology, and in particular to a firmware upgrade method, a storage device, and a computer program product. Background Technology

[0002] Firmware upgrades for storage devices typically employ specific protocol standards. For example, embedded multi-media cards (eMMC) use Field Firmware Update (FFU) for firmware upgrades, requiring the host to fully support the dedicated command set and timing requirements defined by the eMMC protocol. In practical applications, not all host environments can meet this requirement. For instance, in scenarios where Windows connects to eMMC via a USB bridge, the USB bridge usually only supports standard read / write commands (such as SCSI READ / WRITE) and cannot issue the dedicated FFU commands defined by the eMMC protocol, making traditional firmware upgrades impossible.

[0003] To address the aforementioned issues, a generic read / write command sequence can be used to trigger the storage device into upgrade mode. This method involves issuing a set of read / write commands arranged in a predetermined order, causing the storage device to enter upgrade mode upon recognizing the command sequence, and then transmitting firmware data via write commands to achieve the upgrade. However, during the upgrade process, the storage device typically needs to ignore or block other write commands issued by the host, leading to interruptions in normal operations. This interruption is particularly problematic when the upgrade process is lengthy, severely impacting user experience and system availability. Summary of the Invention

[0004] This application provides a firmware upgrade method, a storage device, and a computer program product to solve the problem that in existing storage device firmware upgrade methods, normal write operations are interrupted or blocked during the firmware upgrade process in a host environment that only supports general read and write commands, affecting the continuity of host services.

[0005] In a first aspect, embodiments of this application provide a firmware upgrade method applied to a storage device that communicates with a host device that only supports standard read / write commands via the eMMC protocol. The firmware upgrade method includes: After confirming receipt of the firmware upgrade trigger command from the host, it enters the firmware receiving preparation state; In response to the first write command issued by the host, determine whether the first write command carries a preset first logical block address specifically used to identify the firmware receiving request; If so, then perform firmware receive initialization operation and enter firmware data transmission state; Otherwise, exit firmware upgrade mode and perform write operation.

[0006] By implementing the embodiments of this application, a preset first logical block address is set in the first write command to identify the firmware receiving request. This can accurately distinguish between upgrade request write commands and ordinary write commands. When a non-upgrade request write command is received, the storage device can exit the firmware upgrade state and perform the write operation normally, ensuring the continuity of host services and the availability of the storage device.

[0007] In at least one possible implementation, the following is included before the firmware receive initialization operation: Read the data content of the first write command, determine whether the data content is a preset firmware receive request, if yes, continue to execute the firmware receive initialization operation, otherwise, exit the firmware upgrade state and execute the write operation.

[0008] By implementing the embodiments of this application, data content verification is added on the basis of LBA address verification to form a dual confirmation mechanism, which further reduces the probability of accidentally triggering the upgrade process due to accidental address matching. Even if the preset LBA address is used by the host for ordinary data writing in extreme cases, the upgrade mode can be avoided by identifying the data content, thereby improving the security and reliability of the firmware upgrade process.

[0009] In at least one possible implementation, after entering the firmware data transmission state, the method includes: In response to receiving a second write command from the host, determine whether the second write command carries a preset second logical block address dedicated to identifying the firmware upgrade data address range; If so, then receive the firmware upgrade data carried in the second write command; Otherwise, perform the write operation directly.

[0010] By implementing the embodiments of this application, a dedicated address range is set for firmware upgrade data, enabling the storage device to accurately distinguish between firmware upgrade data packets and ordinary user write commands during the data transmission phase. This achieves physical isolation between upgrade data and user data, while ensuring that ordinary write commands issued by the host during the upgrade process can receive normal responses.

[0011] In at least one possible implementation, prior to receiving the firmware upgrade data carried in the second write command, the method further includes: Check whether the second logical block address carried in the second write command matches the expected logical block address order in the firmware upgrade data address range. If yes, continue to execute the operation of receiving the firmware upgrade data carried in the second write command; otherwise, exit the firmware upgrade state.

[0012] By implementing the embodiments of this application, the LBA address of the firmware data packet can be sequentially verified, and transmission errors can be detected and the upgrade process can be exited, thus ensuring the data integrity of the firmware upgrade.

[0013] In at least one possible implementation, the confirmation of receiving the firmware upgrade command from the host specifically includes: In response to receiving multiple consecutive first read commands from the host, the system enters the firmware upgrade trigger state and checks whether each of the multiple consecutive first read commands carries a third logical block address that is matched in an orderly manner with the preset set of third logical block addresses that serve as dedicated firmware upgrade trigger identifiers. If so, confirm receipt of the firmware upgrade command from the host; otherwise, directly perform the read operation.

[0014] By implementing the embodiments of this application, the address sequence of multiple consecutive read commands is used as the upgrade trigger condition, clearly distinguishing the upgrade trigger from the normal read operation. The upgrade process will only be triggered when the host issues a read command address sequence in a specific order, effectively avoiding the risk of the upgrade process being triggered by normal read operation.

[0015] In at least one possible implementation, after checking whether the consecutive first read commands all carry third logical block addresses that are ordered to match the third logical block address set as a dedicated firmware upgrade trigger identifier, the method further includes: If a first read command fails to match the preset third logical block address (which serves as the trigger for a dedicated firmware upgrade), the process rolls back to the previous first read command and continues the check operation until all first read commands fail to match in an orderly manner.

[0016] By implementing the embodiments of this application, the upgrade triggering robustness and fault tolerance are improved by rolling back to the matching level corresponding to the address through the address rollback mechanism instead of terminating directly.

[0017] In at least one possible implementation, the method further includes: In the firmware receive preparation state and firmware data transmission state, in response to receiving all read commands issued by the host, a read operation is directly executed; and / or In the firmware upgrade triggered state, in response to receiving all write commands from the host, the firmware upgrade triggered state is exited and the write operation is executed directly.

[0018] By implementing the embodiments of this application, the parallel execution of the upgrade process and normal read / write is achieved through the interlocking mechanism based on different states and command types. This ensures the integrity of the firmware upgrade process and guarantees that normal read / write commands issued by the host during the upgrade process can be processed in a timely manner.

[0019] In at least one possible implementation, a state machine is used to control entry into the firmware upgrade trigger state, firmware reception preparation state, firmware data transmission state, and exit from the firmware upgrade state.

[0020] By implementing the embodiments of this application, the upgrade process is managed through a state machine, making the state transitions at each stage clear and controllable. This facilitates the implementation of address rollback, interlocking mechanisms, and exception handling, ensuring that the upgrade process can accurately respond to the expected command types at different stages. At the same time, it simplifies firmware logic design and improves the maintainability and reliability of the system.

[0021] Secondly, embodiments of this application provide a storage device including a controller and a memory, the memory being coupled to the controller, the memory being used to store computer program code, the computer program code including computer instructions, and the controller reading the computer instructions from the memory to cause the controller to perform steps in the firmware upgrade method as described in any embodiment of the first aspect.

[0022] Thirdly, a computer program product comprising computer program code that, when run on a computer, causes the computer to perform the steps described in any embodiment of the first aspect.

[0023] The beneficial effects of this application are: This application embodiment enables the storage device to accurately distinguish between upgrade request write commands and ordinary write commands in a host environment that only supports general read and write commands by setting a preset first logical block address in the first write command specifically for identifying firmware receiving requests. This avoids upgrade process abnormalities or upgrade failures caused by misjudgment. At the same time, when a write command that is not an upgrade request is received, the storage device can exit the firmware upgrade state and perform the write operation normally, thereby ensuring that the upgrade process will not block or interrupt the normal write commands issued by the host, thus guaranteeing the continuity of host services and the availability of the storage device. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of the architecture of the host and storage device provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the firmware upgrade method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the firmware data transmission method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the firmware upgrade triggering method provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the storage device provided in the embodiments of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0028] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0029] In the field of embedded storage, embedded multi-media cards (eMMC), as a storage solution integrating NAND flash memory and a controller, are widely used in various electronic devices such as smartphones, tablets, and industrial control equipment. eMMC devices comply with the eMMC protocol standard and communicate with the host through a standard MMC interface.

[0030] According to the eMMC protocol standard, eMMC devices support multiple operating modes and data transmission methods. Field Firmware Update (FFU) is a crucial function defined in the eMMC protocol, used to update and repair internal firmware after device deployment. As specified in the protocol, implementing the FFU function requires the host to use a specific dedicated write command (such as CMD25 with specific parameters), carrying a specific logical address in the command parameters to identify the current operation as a firmware upgrade to the eMMC device. Upon receiving this dedicated command, the eMMC device enters firmware upgrade mode, writes subsequently received data to the firmware storage area, and completes the firmware replacement and upgrade.

[0031] However, the aforementioned firmware upgrade method based on dedicated protocol commands places explicit requirements on the host environment: the host must fully support the command set and timing requirements defined by the eMMC protocol. In practical applications, not all host environments can meet this requirement. For example, in scenarios where Windows, USB bridges, and other devices connect to eMMC devices via USB interfaces, the USB bridge typically only implements basic SCSI (Small Computer System Interface) protocol conversion and only supports general read / write commands (such as SCSI READ / WRITE commands), but cannot issue the dedicated FFU commands defined by the eMMC protocol.

[0032] To address the aforementioned host environment limitations, the industry has developed trigger-based upgrade schemes based on generic read / write command sequences. The core idea of ​​this approach is to issue a set of generic read / write commands arranged in a predetermined order, causing the storage device to proactively enter upgrade mode upon recognizing the command sequence, thereby avoiding reliance on proprietary protocol commands. However, in implementing this application, the inventors discovered that to prevent accidental triggering of firmware upgrade mode in non-standard protocol hardware environments, a set of command sequences is typically required for matching, data transmission, and firmware replacement. This involves the interaction of multiple read / write commands. During the upgrade process, the storage device often needs to block or ignore other commands issued by the host, leading to normal business interruption and an inability to maintain host business continuity during the upgrade.

[0033] Please see Figure 1 , Figure 1An architecture diagram of the host and storage devices is provided for embodiments of this application.

[0034] The host can be any electronic device that needs to access the storage device, such as a personal computer, server, tablet, smartphone, or embedded system development board. In some application scenarios, the host may not fully support the proprietary protocols followed by the storage device. For example, when the storage device is an eMMC device, the host may only support general read and write operations (such as the READ / WRITE commands under the SCSI protocol) and cannot issue the proprietary FFU commands defined by the eMMC protocol. Typical scenarios include: a Windows operating system connecting to the eMMC device via a USB bridge, where the USB bridge performs the conversion from the USB protocol to the SCSI protocol and only supports basic read and write commands; or the debugging tools of the embedded system only implement simple read and write functions and do not fully implement the eMMC protocol stack. In these scenarios, the host can still upgrade the firmware of the storage device using the firmware upgrade method provided in the embodiments of this application.

[0035] It should be noted that, Figure 1 The system architecture shown is merely an exemplary implementation of an embodiment of this application and is not intended to limit the scope of protection of this application. In other embodiments, the host and storage device can be integrated into the same physical device, for example, the main control chip inside a smartphone acts as the host and the eMMC chip acts as the storage device. Those skilled in the art can adjust the system architecture according to actual application scenarios, and all such adjustments fall within the scope of protection of this application.

[0036] Please see Figure 2 This application provides a firmware upgrade method for storage devices that communicate with standard read / write commands via a host that only supports the eMMC protocol. The firmware upgrade method includes the following steps: Step S110: After confirming that the firmware upgrade trigger command sent by the host has been received, enter the firmware receiving preparation state; The firmware upgrade trigger command can be implemented in various ways, such as through a set of preset read command sequences or other custom command combinations. This embodiment does not impose specific limitations on this, as long as it can trigger the storage device to enter the firmware reception preparation state.

[0037] Step S120: In response to the first write command issued by the host, determine whether the first write command carries a preset first logical block address specifically used to identify the firmware receiving request; Storage devices are pre-configured with one or more preset Logical Block Addresses (LBAs). These preset addresses are not used for ordinary user data storage, but rather serve as control channels for the upgrade process. For example, a manufacturer can define the first logical block address as 0x8000 in the firmware. When the storage device is in the firmware receive preparation state, it monitors the write commands issued by the host in real time, extracts the LBA address field from the command, and determines whether the address is equal to the preset first logical block address.

[0038] If so, in step S130, the firmware receive initialization operation is performed, and the firmware data transmission state is entered; When the host sends a write command to the preset LBA address, the storage device recognizes the write command as a firmware upgrade request. At this time, it initiates the subsequent operations of the firmware upgrade process, such as preparing to receive firmware data cache, initializing data packet sequence counter, etc., and switches the state to firmware data transmission state.

[0039] Step S140, otherwise, exit firmware upgrade state and perform write operation.

[0040] If the storage device receives a write command to a normal LBA address (such as 0x1000) while in the firmware receive preparation state, it will recognize the command as a normal user write operation, write the data to the corresponding location of the NAND flash memory and update the FTL table entry, and exit the firmware upgrade state to wait for the next upgrade trigger.

[0041] Through the above steps, this embodiment achieves accurate differentiation between upgrade requests and ordinary write commands by using write commands with preset LBA addresses in an environment that only supports general read / write commands, avoiding upgrade process anomalies caused by misjudgment. Simultaneously, upon receiving a write command that is not an upgrade request, the storage device can exit the firmware upgrade state and execute the write operation normally, ensuring that the upgrade process does not block or interrupt normal read / write commands issued by the host, thus guaranteeing the continuity of host services and the availability of the storage device. This method relies only on standard read / write commands and LBA address recognition, requiring no modification to the host-side protocol stack, and is characterized by its simplicity and strong compatibility.

[0042] In at least one possible implementation, the following steps are included before step S130: Step S121: Read the data content of the first write command, determine whether the data content is a preset firmware receiving request, if yes, continue to execute the firmware receiving initialization operation, otherwise, exit the firmware upgrade state and execute the write operation.

[0043] In implementing the embodiments of this application, if the logical block address of the first write command matches a preset first logical block address, but its data content is not a preset firmware receiving request (e.g., the preset data is 0x0, but the actual data is 0x1), the storage device determines that the write command is a normal data write operation. In this case, if the storage device maintains the firmware receiving preparation state unchanged, the following problems will occur: the state machine will remain in the state of waiting for an upgrade request for a long time, while the host has not actually initiated an upgrade; subsequent read and write commands may be misjudged or blocked, affecting normal business operations; the data carried by the write command is ordinary user data, and if it is not written to the NAND flash memory in a timely manner, it will cause data loss or write delay.

[0044] Therefore, the storage device needs to interrupt the current firmware upgrade process, exit the firmware upgrade state, and treat the write command as a standard write operation, writing the data to the corresponding logical address of the NAND flash memory and updating the FTL table entry. This ensures both the integrity of user data and timely writing, while also freeing up state machine resources, enabling the device to respond to subsequent normal upgrade processes or continue processing other read and write commands.

[0045] Please see Figure 3 In at least one possible implementation, the following step is included after step S130: Step S131: In response to receiving a second write command from the host, determine whether the second write command carries a preset second logical block address dedicated to identifying the firmware upgrade data address range; Step S132: If yes, then receive the firmware upgrade data carried in the second write command; Step S133, otherwise, perform the write operation directly.

[0046] In implementing the embodiments of this application, after the storage device enters the firmware data transmission state, the storage device monitors the write commands issued by the host in real time. When a second write command is received from the host, the storage device first determines whether the logical block address carried in the second write command belongs to a preset second logical block address specifically used to identify the address range of firmware upgrade data. This second logical block address is usually an address range. For example, the manufacturer may preset the address range 0x9000 to 0x9FFF in the firmware as a dedicated address range for firmware upgrade data, used to isolate it from the address range of ordinary user data.

[0047] If the logical block address of the second write command falls within the preset address range, the storage device determines that the write command is a firmware upgrade data packet, and then receives the firmware upgrade data carried in the write command and stores it in the upgrade cache.

[0048] If the logical block address of the second write command does not belong to the preset address range, the storage device recognizes the write command as a normal user write command, directly executes the write operation, writes the data carried by the command to the corresponding logical address of the NAND flash memory, and updates the FTL table entry. During this process, the storage device maintains the current firmware data transmission state and continues to wait for subsequent firmware upgrade data packets. Through the above method, this implementation achieves isolation processing of upgrade data and normal user data during the firmware upgrade data transmission phase, ensuring both reliable reception of firmware upgrade data and normal response to normal write commands issued by the host during the upgrade process, without affecting business continuity.

[0049] In at least one possible implementation, the following steps are included before step S132: Step S1311: Check whether the second logical block address carried in the second write command matches the expected logical block address order in the firmware upgrade data address range. If yes, continue to execute the operation of receiving the firmware upgrade data carried in the second write command; otherwise, exit the firmware upgrade state.

[0050] In implementing this embodiment, during firmware data transmission, the storage device checks whether the second logical block address carried in the second write command matches the expected logical block address order within the firmware upgrade data address range. For example, the first data packet corresponds to address 0x9000, the second data packet corresponds to address 0x9001, and so on. If the logical block address of the currently received second write command matches the expected address, the receiving operation continues; if there is an address jump, duplication, or out-of-order mismatch, a transmission error is determined, the firmware upgrade state is immediately exited, and the received cached data is cleared, waiting for the host to re-initiate the upgrade process. This method avoids the risk of firmware corruption due to out-of-order or lost data packets.

[0051] Please see Figure 4 In at least one possible implementation, step S110 specifically includes the following steps: Step S111: In response to receiving multiple consecutive first read commands from the host, enter the firmware upgrade trigger state and check whether the multiple consecutive first read commands all carry third logical block addresses that are matched in an orderly manner with the preset set of third logical block addresses that serve as dedicated firmware upgrade trigger identifiers. Step S112: If yes, confirm receipt of the firmware upgrade command from the host; otherwise, directly perform the read operation.

[0052] In implementing this embodiment, the storage device is pre-configured with a set of third logical block addresses serving as dedicated firmware upgrade trigger identifiers. These addresses are arranged in a preset order, such as LBA_A, LBA_B, and LBA_C. When the storage device receives multiple consecutive first read commands from the host, it enters a firmware upgrade trigger state and checks whether each of the consecutive first read commands carries logical block addresses that match the third logical block address set in an ordered manner. If the logical block addresses of the consecutive first read commands are completely consistent with the preset order, the device confirms receipt of the firmware upgrade trigger command from the host and enters a firmware reception preparation state. If a mismatch occurs during the matching process, the device directly performs a read operation and returns the data at the corresponding address to the host. Furthermore, when a partial match occurs followed by a mismatch, the storage device supports rolling back to the matching level corresponding to the previously matched first read command and continues to wait for subsequent commands. Through this method, this implementation achieves secure firmware upgrade triggering using only standard read commands, while ensuring that normal read operations in non-upgrade trigger scenarios are not affected.

[0053] In at least one possible implementation, the following steps are included after step S111: Step S1111: If a first read command fails to match the preset third logical block address (which serves as a dedicated firmware upgrade trigger identifier) ​​in an orderly manner, roll back to the previous first read command and continue to perform the check operation until all first read commands fail to match in an orderly manner.

[0054] In implementing the embodiments of this application, the storage device identifies a first read command with a logical address of A, which successfully matches the current matching level (pointing to A). The matching level is then updated to point to the next expected address, B. Next, a second read command is received with a logical address of B, which also successfully matches the current matching level (pointing to B). The matching level is updated to point to the next expected address, C. At this point, the matching level is 2 (indicating that two commands have been successfully matched, and the next expected address is C). However, if the logical address of the next received read command is not C, for example, if the logical address of the third received read command is A, not the expected C, the storage device adjusts the matching level to the matching level corresponding to the already matched address A, i.e., it falls back to matching level 1.

[0055] Through the aforementioned fallback mechanism, the storage device can tolerate a certain degree of command out-of-order or duplicate commands. For example, in a real-world environment, when commands are resent due to bus interference or host driver malfunctions, there is still a chance to continue entering firmware upgrade mode. This enhances fault tolerance for abnormal situations and ensures the reliability of firmware upgrade triggering.

[0056] In at least one possible implementation, the firmware upgrade method includes the following steps: In step S150, during the firmware reception preparation state and firmware data transmission state, in response to receiving all read commands issued by the host, the read operation is executed directly.

[0057] Implementing the embodiments of this application, in the firmware reception preparation state and firmware data transmission state, the storage device directly executes a read operation in response to receiving any read command from the host. Specifically, the storage device reads data from the NAND flash memory according to the logical block address in the read command and returns it to the host, while maintaining its current state and continuing to wait for subsequent commands in the upgrade process. This ensures that the host's normal read operation on the storage device is not affected in the firmware reception preparation state and firmware transmission state.

[0058] In at least one possible implementation, the firmware upgrade method includes the following steps: In step S160, in the firmware upgrade triggered state, in response to receiving all write commands from the host, the firmware upgrade triggered state is exited and the write operation is executed directly.

[0059] In implementing the embodiments of this application, when a firmware upgrade is triggered, the storage device, in response to receiving any write command from the host, exits the firmware upgrade triggered state and treats the write command as a normal write operation. Specifically, the storage device writes the data carried by the write command to the corresponding logical address of the NAND flash memory and updates the FTL table entry. The firmware upgrade triggered state is the stage where the storage device confirms the host's upgrade intention by matching the read command sequence. The appearance of a write command at this stage indicates that the host's behavior has deviated from the preset upgrade trigger sequence. Therefore, it is necessary to exit the firmware upgrade triggered state and process the write command normally to ensure the timely writing of user data and release state machine resources to respond to subsequent normal upgrade processes or other business commands.

[0060] In at least one possible implementation, the storage device controls the entry into the firmware upgrade trigger state, firmware reception preparation state, firmware data transmission state, and exit firmware upgrade state via a state machine.

[0061] By way of example, the following describes in detail the process of a storage device performing a firmware upgrade according to an embodiment of this application.

[0062] When implementing the embodiments of this application, a typical application scenario in which a Windows operating system host establishes communication with an eMMC storage device through a USB bridge chip is used as an example to describe the execution process of the firmware upgrade system in detail. In this scenario, the USB bridge chip only supports the general read / write commands (READ / WRITE) of the SCSI protocol and cannot issue the FFU-specific firmware upgrade commands defined by the eMMC protocol, which is the core applicable scenario of the system in this application. The upgrade system includes a host and an eMMC storage device. The host is equipped with a processor, a communication interface, and an upgrade control program. The storage device is equipped with a controller and a NAND flash memory chip. The controller has a built-in state machine (firmware upgrade trigger state, firmware reception preparation state, and firmware data transmission state) and command matching logic. The two interact with each other through the USB bridge chip to realize the interaction of general read / write commands and data.

[0063] When the host needs to upgrade the firmware of the eMMC storage device, it first organizes a command sequence according to predefined rules and issues it sequentially. This command sequence includes three stages of commands: Phase 1 commands: Multiple first read commands, arranged in a predetermined order, each carrying a preset logical address (e.g., first address A, second address B, third address C). These first read commands are used to initiate an upgrade confirmation handshake to the storage device.

[0064] Second-stage command: First write command, carrying the preset first logical block address, whose data content is a firmware upgrade request (for example, using a specific value 0x0 to represent FFU Request).

[0065] The third-stage command is the second write command, which carries the preset address of the second logical block and contains the firmware data to be upgraded.

[0066] During the process of receiving a sequence of commands, the storage device manages the upgrade process through an internal state machine. The state machine includes a firmware upgrade trigger state, a firmware reception preparation state, and a firmware data transmission state, which correspond to the three stages of command processing, respectively.

[0067] When a firmware upgrade is triggered, the storage device matches multiple first read commands in a predetermined order and maintains a matching level to record successfully matched read commands and the expected logical address of the next command. The matching level is updated accordingly for each successfully matched read command.

[0068] If the received first read command logical address matches the expected address corresponding to the current matching level, the matching continues to the next command. If the received first read command logical address does not match the expected address, but the address has already been matched (e.g., A and B have been matched, and then A is received again), the matching level is rolled back to the level corresponding to the already matched address, and the device continues to wait for subsequent commands. When all first read commands are successfully matched in a predetermined order, the storage device switches its state machine from the firmware upgrade triggered state to the firmware receive ready state. If a write command or a read command that is not a first read command is received, the current matching process is terminated, the firmware upgrade triggered state is exited, and read / write operations are performed normally.

[0069] Once the state machine enters the firmware receive preparation state, the eMMC storage device waits to receive the second-stage command from the host. After the host completes the first-stage command, it then sends the second-stage command (first write command, address D, content is an upgrade request).

[0070] When an eMMC storage device receives the first write command in the acknowledged state, it first checks whether its logical address is the expected address D. If the address matches, it further parses its data content. If the data content is a valid firmware upgrade request (e.g., a value of 0x0), it confirms the upgrade intent and switches the state machine from the firmware receive preparation state to the firmware data transmission state.

[0071] If the first write command received matches the logical address but its data content is not the expected upgrade request (e.g., a value of 0x1), it indicates that this is not a firmware upgrade operation but a normal data write operation. In this case, the eMMC storage device interrupts the firmware upgrade process and treats the write command as a normal data write command: it writes the data to the NAND flash memory and updates the corresponding FTL table entry to ensure that the host can correctly access the data later. If other read or write commands (not second-stage commands) are received during the firmware receive preparation state, the storage device directly executes the corresponding read or write operation. In this way, the storage device can recognize the upgrade intent while maintaining compatibility with normal read and write operations.

[0072] Once the state machine enters the firmware data transmission state, the eMMC storage device prepares to receive the third-stage command from the host. After the host completes the second-stage command, it then sends the third-stage command (the second write command, which carries the address of the second logical block dedicated to identifying the firmware upgrade data address range, and contains the firmware data).

[0073] When an eMMC storage device receives a second write command during firmware data transmission, it determines whether the logical block address of the write command belongs to the preset firmware upgrade data address range (0x9000 to 0x9FFF). If it does, it further checks whether the logical block address matches the expected data packet order. For example, the first data packet corresponds to address 0x9000, the second data packet corresponds to address 0x9001, and so on. If the address matches the expected order, the device receives the firmware upgrade data carried in the write command and stores it in the upgrade buffer, while updating the expected address to the address of the next data packet. If the address does not match the expected order (e.g., address jumps, duplications, or out-of-order delivery), a transmission error is determined, the upgrade process is interrupted, the state machine exits the firmware data receiving state, the received buffered data is cleared, and the device waits for the host to re-initiate the upgrade process.

[0074] If the logical block address of the received write command does not fall within the firmware upgrade data address range, the storage device recognizes the write command as a regular user write command, directly executes the write operation, writes the data to the corresponding logical address of the NAND flash memory, and updates the FTL table entry. If an error occurs during data reception (e.g., data verification failure, transmission timeout, or command interruption), it indicates an abnormal firmware data transmission, exits the firmware data reception state, terminates the current upgrade process, and waits for the host to re-initiate the upgrade; if data reception is successful and verification passes, the eMMC storage device performs firmware replacement operations, including writing the new firmware to the specified storage area and updating the firmware boot pointer.

[0075] After the replacement is complete, the state machine clears all firmware upgrade states and waits for the next upgrade or normal read / write operation.

[0076] In this way, the host can trigger and complete the firmware upgrade of the storage device using only general read and write commands, without relying on dedicated protocol commands. This enables reliable upgrades of the storage device even in host environments that only support general read and write commands (such as Windows connected to eMMC via a USB bridge), significantly improving the system's applicability and compatibility. Simultaneously, the storage device's internal state machine management and rollback mechanism, as well as the interlocking processing at each stage, ensure the robustness and stability of the upgrade process, preventing device state suspension or data corruption due to command transmission anomalies or misoperations, and enabling parallel execution of firmware upgrades and normal read and write operations.

[0077] Please see Figure 5This application embodiment also provides a storage device, which is connected to a host via a USB bridge and includes a controller 100 and a memory 200. The memory 200 is coupled to the controller 100 and is used to store computer program code, which includes computer instructions. When the controller 100 reads the computer instructions from the memory 200, the controller 100 performs the steps in the firmware upgrade method in any of the above embodiments.

[0078] This application also provides a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform a method as described in any of the possible implementations of the first or second aspect.

[0079] This application also provides a computer program that, when the computer program code is run on a computer, causes the computer to perform a method of any possible implementation of any of the foregoing embodiments.

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

[0081] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A firmware upgrade method, applied to a storage device that communicates with a host device using standard read / write commands that only support the eMMC protocol, characterized in that, The firmware upgrade method includes: After confirming receipt of the firmware upgrade trigger command from the host, it enters the firmware receiving preparation state; In response to the first write command issued by the host, determine whether the first write command carries a preset first logical block address specifically used to identify the firmware receiving request; If so, then perform firmware receive initialization operation and enter firmware data transmission state; Otherwise, exit firmware upgrade mode and perform write operation.

2. The firmware upgrade method according to claim 1, characterized in that, The process also includes the following steps before performing the firmware receive initialization operation: Read the data content of the first write command, determine whether the data content is a preset firmware receive request, if yes, continue to execute the firmware receive initialization operation, otherwise, exit the firmware upgrade state and execute the write operation.

3. The firmware upgrade method according to claim 1 or 2, characterized in that, After entering the firmware data transmission state, the method includes: In response to receiving a second write command from the host, determine whether the second write command carries a preset second logical block address dedicated to identifying the firmware upgrade data address range; If so, then receive the firmware upgrade data carried in the second write command; Otherwise, perform the write operation directly.

4. The firmware upgrade method according to claim 3, characterized in that, Before receiving the firmware upgrade data carried in the second write command, the procedure also includes: Check whether the second logical block address carried in the second write command matches the expected logical block address order in the firmware upgrade data address range. If yes, continue to execute the operation of receiving the firmware upgrade data carried in the second write command; otherwise, exit the firmware upgrade state.

5. The firmware upgrade method according to claim 4, characterized in that, The confirmation that the firmware upgrade command issued by the host has been received specifically includes: In response to receiving multiple consecutive first read commands from the host, the system enters the firmware upgrade trigger state and checks whether each of the multiple consecutive first read commands carries a third logical block address that is matched in an orderly manner with the preset set of third logical block addresses that serve as dedicated firmware upgrade trigger identifiers. If so, confirm receipt of the firmware upgrade command from the host; otherwise, directly perform the read operation.

6. The firmware upgrade method according to claim 5, characterized in that, After checking whether the consecutive first read commands all carry third logical block addresses that match the preset set of third logical block addresses used as dedicated firmware upgrade trigger identifiers, the process further includes: If a first read command fails to match the preset third logical block address (which serves as the trigger for a dedicated firmware upgrade), the process rolls back to the previous first read command and continues the check operation until all first read commands fail to match in an orderly manner.

7. The firmware upgrade method according to claim 6, characterized in that, The method further includes: In the firmware receive preparation state and firmware data transmission state, in response to receiving all read commands issued by the host, a read operation is directly executed; and / or In the firmware upgrade triggered state, in response to receiving all write commands from the host, the firmware upgrade triggered state is exited and the write operation is executed directly.

8. The firmware upgrade method according to claim 5, characterized in that, The state machine controls the entry into the firmware upgrade trigger state, firmware reception preparation state, firmware data transmission state, and exit from the firmware upgrade state.

9. A storage device, characterized in that, It includes a controller and a memory coupled to the controller. The memory is used to store computer program code, which includes computer instructions. When the controller reads the computer instructions from the memory, the controller performs the steps in the firmware upgrade method as described in any one of claims 1-8.

10. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to perform the steps as described in any one of claims 1-8.

Images