Managing firmware control data using application data descriptor mapping

Abstract

This application relates to managing firmware control data stored in a storage device of an electronic device. The electronic device obtains a current data descriptor map (DDM) corresponding to a current version of a firmware program and identifies in the storage device a previous DDM corresponding to a previous version of the firmware program and a previous control data structure. Each of the previous DDM and the current DDM maps a plurality of data descriptors to a plurality of locations in a respective control data structure. The previous control data structure stores a plurality of previous control data items identified by a plurality of previous data descriptors. A current control data structure is automatically generated for the current version of the firmware program based on the previous control data structure, the current DDM and the previous DDM and stores a plurality of current control data items identified by the data descriptors.

Description

[0001] Related applications

[0002] This application is a continuation-to-priority application to U.S. Patent Application No. 18 / 388,779, filed November 10, 2023, entitled “Using Data Descriptor Mapping to Manage Firmware Control Data,” which is incorporated herein by reference in its entirety. Technical Field

[0003] This application generally relates to storage management, including but not limited to methods, systems, and non-transitory computer-readable media for managing firmware control data in storage devices of electronic devices. Background Technology

[0004] Memory is used in computer systems to store instructions and data. Specifically, computer systems rely on non-volatile memory to retain the instructions and data stored on them even when the computer system is disconnected from power. Examples of secondary storage include, but are not limited to, hard disk drives (HDDs) and solid-state drives (SSDs). Most embedded firmware architectures rely on hundreds of non-volatile control data structures at startup for the initialization of firmware and hardware policies and states, as well as the recovery of user configuration capabilities and telemetry logs. These data structures are stored as the raw payload in non-volatile memory and are recovered after a power outage or firmware upgrade or downgrade. For product maintenance and differentiation, we anticipate firmware capabilities being added in subsequent versions for error localization, internal features, and consumer-requested logs / features. These changes may necessitate changes to the structure of the non-volatile files on which the firmware depends. Changes to non-volatile control data structures between versions can lead to incompatibility between firmware versions. Careful attention must be paid to engineering considerations when crossing version designs, modifying non-volatile structures, or interacting with non-volatile structures to ensure that both copies of the firmware can interpret the contents of the original files and handle their differences. Incorrect firmware interpretation or improper handling of fault-free files can, at best, lead to unexpected device behavior or corrupted telemetry logs, and at worst, cause critical hardware, firmware policy, or device failure.

[0005] To mitigate the risk of incompatibility, vendors incur costs associated with engineering design meetings, debugging sessions, and training when considering non-volatile data structures. Furthermore, many vendors utilize substantial validation resources to develop and execute complex compatibility tests that consider hundreds of files and edge cases. Manually versioning control data structure tags is costly and prone to human error. Errors in any mitigation steps prior to release can lead to compatibility omissions. In projects requiring versioning, the probability of incorrect structures being versioned, using the wrong version, or implementing changes without version changes is extremely high. Additionally, most firmware versions have multiple version numbers for different parts of the program (main program, bootloader, API, etc.) and for different internal and external consumers, quickly making it confusing which exact version number the control data applies to. Beyond security compatibility issues, consumers expect all firmware versions to be compatible with each other without problems or special upgrade or downgrade processes. Ultimately, product malfunctions or failures due to version incompatibility will significantly impact end-user revenue (due to version delays and / or downtime), damage the vendor's reputation, and result in lost revenue for the vendor. Managing firmware control data versions stored in storage devices in an accurate and efficient manner would be beneficial. Summary of the Invention

[0006] Various embodiments of this application relate to methods, systems, apparatuses, and non-transitory computer-readable media for managing firmware control data (e.g., different versions of firmware) stored in a storage device of an electronic system. The firmware controlling the electronic device includes control logic and control data, and the control logic reads and writes the control data to maintain the state and operation of the electronic device. In some embodiments, the firmware on the electronic device is updated more than once (e.g., periodically updated throughout the lifecycle of the electronic device). In some scenarios, only the control logic is updated, and in others, both the control logic and the control data are updated. The control data optionally persists across two or more different versions of the control logic. When this occurs, the control logic in a first version of the firmware automatically points to a subset of the control data whose position has changed in the control logic of a second version of the firmware. Specifically, a Data Descriptor Mapping (DDM) is applied for each firmware version to map multiple data descriptors to multiple data locations in the corresponding control data structure. Checkpoints are introduced to automatically compare data descriptors between versions to allow for automatic detection and upgrade / downgrade of control data. In these ways, firmware control data is managed efficiently and accurately based on DDM as the firmware is updated between different versions.

[0007] In one aspect, a method is provided implemented in an electronic device including a storage device. The method includes obtaining a current data descriptor mapping (DDM) corresponding to a current version of firmware, wherein the current DDM maps a plurality of current data descriptors to a plurality of current locations in a current control data structure. The method includes identifying, in the storage device, a previous DDM and a previous control data structure corresponding to a previous version of the firmware. The previous DDM maps a plurality of previous data descriptors to a plurality of previous locations in the previous control data structure, and the previous control data structure stores a plurality of previous control data items identified by the plurality of previous data descriptors. The method further includes automatically generating a current control data structure corresponding to the current version of the firmware based on the previous control data structure, the current DDM, and the previous DDM. The current control data structure stores a plurality of current control data items identified by the plurality of current data descriptors. The method further includes storing the current control data structure in the storage device.

[0008] Some embodiments of this application provide an electronic device comprising one or more processors and a memory storing instructions thereon, the instructions, when executed by the one or more processors, causing the processors to perform any of the methods described above on a storage device (e.g., including one or more SSDs).

[0009] Some embodiments of this application provide a storage device comprising a plurality of storage devices (e.g., one or more SSDs) and a memory storing instructions thereon, the instructions, when executed by the one or more processors, causing the processors to perform any of the methods described above on the storage devices.

[0010] Some embodiments of this application provide a non-transitory computer-readable storage medium storing one or more programs. The one or more programs contain instructions that, when executed by one or more processors, cause the processors to perform any of the methods described above on a storage device (e.g., including one or more SSDs).

[0011] These illustrative embodiments and implementations are not intended to limit or restrict this disclosure, but rather to provide examples to aid in understanding it. Additional embodiments are discussed in the implementation and further descriptions are provided therein. Attached Figure Description

[0012] To better understand the various described implementation schemes, the following diagrams should be used in conjunction with the implementation methods, where similar element symbols refer to corresponding parts throughout the diagrams.

[0013] Figure 1This is a block diagram of an example system module in a typical electronic system according to some embodiments.

[0014] Figure 2 This is a block diagram of a storage system of an example electronic device having one or more memory access queues according to some embodiments.

[0015] Figure 3A This is a schematic diagram of two versions of an example firmware program 300, which stores control data in different locations in two corresponding control data structures according to some embodiments.

[0016] Figure 3B This is a diagram of an example DDM based on some embodiments.

[0017] Figure 4 This is a schematic diagram of two versions of an example firmware program for applications according to some embodiments, where different control data are stored in different locations in two corresponding control data structures.

[0018] Figure 5 This is a schematic diagram of two versions of firmware, representing another instance of different control data stored in different locations within a control data structure according to some embodiments.

[0019] Figure 6 This is a structural diagram of two additional instance control data structures built based on two versions of the DDM corresponding to the firmware, according to some embodiments.

[0020] Figure 7 This is a flowchart of an example method 700 for managing firmware control data in an electronic device according to some embodiments.

[0021] In several views of the diagram, similar component symbols refer to the corresponding parts. Detailed Implementation

[0022] Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. Numerous non-limiting specific details are set forth in the following embodiments to aid in understanding the subject matter presented herein. However, it will be apparent to those skilled in the art that various alternatives may be used without departing from the scope of the claims, and that the subject matter may be practiced without these specific details. For example, it will be apparent to those skilled in the art that the subject matter presented herein can be implemented in many types of electronic systems or devices with data storage capabilities.

[0023] This application relates to methods, systems, apparatus, and non-transitory computer-readable media for managing firmware control data (e.g., different versions of firmware) stored in a storage device of an electronic device. The firmware controlling the electronic device includes control logic and control data, and the control logic reads and writes the control data to maintain the state and operation of the electronic device. In some embodiments, the firmware on the electronic device is updated more than once (e.g., periodically updated throughout the lifecycle of the electronic device). In some scenarios, only the control logic is updated, and in some scenarios, both the control logic and the control data are updated. The control data optionally persists across two or more different versions of the control logic. When this occurs, the control logic in a first version of the firmware automatically points to a subset of the control data whose position has changed in the control logic of a second version of the firmware. Specifically, a data descriptor mapping (DDM) is applied for each firmware version to map multiple data descriptors to multiple data locations in the corresponding control data structure. Checkpoints are introduced to automatically compare data descriptors between versions to allow for automatic detection and upgrade / downgrade of control data.

[0024] In some embodiments, firmware development begins with a linker and compiler. The compiler translates the human-readable logical description of the control logic into machine language and generates storage space for the control data required by the control logic. The linker combines a subset of control logic (which has been translated into machine language) and the control data into a working program. The compiler and linker obtain location information of the control data and the correlation between the subsets of control logic and corresponding subsets of control data, and transmit this information in machine language, while removing portions of intermediate communication data from the final product of the firmware update. In some embodiments, during the process of upgrading the version of the control logic, a large number (e.g., millions) subsets of control data are associated with and linked to the corresponding subsets of control logic. In some embodiments of this application, intermediate communication data of the compiler and linker is maintained as part of the control data and is used to translate firmware control data between two different firmware versions on the electronic device itself when a firmware upgrade or downgrade occurs.

[0025] In some embodiments of this application, the compiler generates a Data Management Module (DDM) to automatically translate control data into unique identifiers or descriptors describing each data segment within the control data. For example, the unique identifier or descriptor of the DDM includes one or more of the following: the name, location, size, and type of each data item in the control data, and the DDM stores the unique identifier or descriptor along with the control data. In some embodiments, any copied or duplicated data (arrays, structure arrays) is recorded only in the DDM. In one instance, the DDM corresponds to 1 megabyte of data and includes a few bytes describing the data. During a firmware update, the DDM of the control data currently stored on the device is compared with the DDM of the control data expected after the firmware update, and differences between the two DDMs are identified, and these differences are used to provide a control data structure for the firmware update.

[0026] Figure 1 This is a block diagram of an example system module 100 in a typical electronic system according to some embodiments. System module 100 in this electronic system includes at least: a processor module 102; a storage module 104 for storing programs, instructions, and data; an input / output (I / O) controller 106; one or more communication interfaces, such as a network interface 108; and one or more communication buses 140 for interconnecting these components. In some embodiments, the I / O controller 106 allows the processor module 102 to communicate with I / O devices (e.g., a keyboard, mouse, or trackpad) via a universal serial bus interface. In some embodiments, the network interface 108 includes one or more interfaces for Wi-Fi, Ethernet, and Bluetooth networks, each allowing the electronic system to exchange data with external sources, such as a server or another electronic system. In some embodiments, the communication bus 140 includes a circuitry (sometimes referred to as a chipset) that interconnects and controls communication between the various system components included in system module 100.

[0027] In some embodiments, storage module 104 includes high-speed random access memory, such as DRAM, static random access memory (SRAM), double data rate (DDR) dynamic random access memory (RAM), or other random access solid-state storage devices. In some embodiments, storage module 104 includes non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory storage devices, or other non-volatile solid-state storage devices. In some embodiments, storage module 104, or alternatively, the non-volatile storage device within storage module 104, includes a non-transitory computer-readable storage medium. In some embodiments, a memory slot is reserved on system module 100 for housing storage module 104. Once inserted into the memory slot, storage module 104 is integrated into system module 100.

[0028] In some embodiments, system module 100 further includes one or more components selected from storage controller 110, SSD 112, hard disk drive (HDD) 114, power management integrated circuit (PMIC) 118, graphics module 120, and audio module 122. Storage controller 110 is configured to control communication between processor module 102 in the electronic system and the memory components including storage module 104. SSD 112 is configured to apply integrated circuit assemblies to store data in the electronic system and, in many embodiments, is based on NAND or NOR memory. HDD 114 is a conventional data storage device for storing and retrieving digital information based on electromechanical disks. Power connector 116 is electrically coupled to receive an external power supply. PMIC 118 is configured to modulate the received external power supply to other desired DC voltage levels, such as 5 V, 3.3 V, or 1.8 V, as needed by various components or circuits within the electronic system (e.g., processor module 102). In some embodiments, the graphics module 120 is configured to generate an output image to be fed to the one or more display devices according to a desired image / video format of the one or more display devices. In some embodiments, the audio module 122 is configured to facilitate the input of audio signals to and output of audio signals from the electronic system under the control of a computer program.

[0029] In some embodiments, system module 100 further includes an SSD 112' directly coupled to I / O controller 106. Instead, SSD 112 is coupled to communication bus 140. In one example, communication bus 140 operates according to Peripheral Component Interconnect High Speed ​​(PCIe or PCI-E), which is a serial extended bus standard for interconnecting processor module 102 to one or more peripheral devices and various system components including components 110 to 122, and for controlling said one or more peripheral devices and various system components.

[0030] Furthermore, those skilled in the art will recognize the use of other non-transitory computer-readable storage media, as new data storage technologies have been developed for storing information in non-transitory computer-readable storage media within storage modules 104, SSDs 112 and 112', and HDD 114. These new non-transitory computer-readable storage media include, but are not limited to, media made of biological materials, nanowires, carbon nanotubes, and individual molecules, even if the corresponding data storage technology is currently under development and not yet commercialized.

[0031] Figure 2 This is a block diagram of a storage system 200 of an example electronic device having one or more memory access queues according to some embodiments. The storage system 200 is coupled to a host device 220 (e.g., ...). Figure 1 The processor module 102 is configured to store instructions and data for extended periods, such as when the electronic device is in sleep, hibernation, or powered off. The host device 220 is configured to access and process the instructions and data stored in the storage system 200 to run the operating system and execute user applications. The storage system 200 further includes a controller 202 and a plurality of storage channels 204 (e.g., channels 204A, 204B, and 204N). Each storage channel 204 includes a plurality of storage units. The controller 202 is configured to execute firmware-level software to bridge the plurality of storage channels 204 to the host device 220.

[0032] Each memory channel 204 includes one or more memory packages (e.g., two memory dies 206). In one example, each memory package (e.g., memory package 206A or 206B) corresponds to a memory die 206. Each memory package includes multiple memory planes 208, and each memory plane 208 further includes multiple memory pages 210. Each memory page 210 includes a set of ordered memory cells, and each memory cell is identified by a corresponding physical address. In some embodiments, the memory system 200 includes multiple superblocks. Each superblock includes multiple memory blocks, each of which further includes multiple memory pages 210. For each superblock, the multiple memory blocks are configured to be written to and read from the memory system in parallel via a memory input / output (I / O) interface. Optionally, each superblock groups memory cells distributed across the multiple memory planes 208, multiple memory channels 204, and multiple memory dies 206. In one example, each superblock contains at least one set of memory pages, each page being distributed across different memory dies 206, having the same die, plane, block, and page names, and accessed via different channels of different memory dies 206. In another example, each superblock contains at least one set of memory blocks, each memory block being distributed across different memory dies 206, containing multiple pages, having the same die, plane, and block names, and accessed via different channels of different memory dies 206. The storage system 200 stores information about the ordered list of superblocks in a cache of the storage system 200. In some embodiments, the cache is managed by a host driver of the host device 220 and is referred to as the Host Management Cache (HMC).

[0033] In some embodiments, the storage system 200 includes single-cell (SLC) NAND flash memory chips, with each cell storing a single data bit. In some embodiments, the storage system 200 includes multi-cell (MLC) NAND flash memory chips, with each cell of the MLC NAND flash memory chip storing two data bits. In one example, each cell of a three-cell (TLC) NAND flash memory chip stores three data bits. In another example, each cell of a four-cell (QLC) NAND flash memory chip stores four data bits. In yet another example, each cell of a five-cell (PLC) NAND flash memory chip stores five data bits. In some embodiments, each cell may store any suitable number of data bits. Compared to non-SLC NAND flash memory chips (e.g., MLC SSDs, TLC SSDs, QLC SSDs, PLCSSDs), SSDs with SLC NAND flash memory chips operate at higher speeds, higher reliability, and longer lifespans; however, they have lower device density and higher prices.

[0034] Each memory channel 204 is coupled to a corresponding channel controller 214 (e.g., controller 214A, 214B, or 214N), which is configured to control internal and external requests for accessing memory cells in the corresponding memory channel 204. In some embodiments, each memory package (e.g., each memory die 206) corresponds to a corresponding queue 216 of memory access requests (e.g., queue 216A, 216B, or 216N). In some embodiments, each memory channel 204 corresponds to a corresponding memory access request queue 216. Additionally, in some embodiments, each memory channel 204 corresponds to different and distinct memory access request queues 216. In some embodiments, a subset (less than all) of the plurality of memory channels 204 corresponds to different memory access request queues 216. In some embodiments, all of the plurality of memory channels 204 of the storage system 200 correspond to a single memory access request queue 216. Each memory access request is optionally received internally from the storage system 200 to manage the corresponding memory channel 204, or externally from a host device 220 to write or read data stored in the corresponding channel 204. Specifically, each memory access request includes one of the following: a system write request received from storage system 200 to write to the corresponding storage channel 204; a system read request received from storage system 200 to read from the corresponding storage channel 204; a host write request originating from host device 220 to write to the corresponding storage channel 204; and a host read request received from host device 220 to read from the corresponding storage channel 204. It should be noted that system read requests (also referred to as background read requests or non-host read requests) and system write requests are dispatched by the storage controller to implement internal memory management functions, including but not limited to garbage collection, wear leveling, read interference mitigation, memory snapshot capture, memory mirroring, caching, and memory spare.

[0035] In some embodiments, in addition to channel controller 214, controller 202 further includes local storage processor 218, host interface controller 222, SRAM buffer 224, and DRAM controller 226. Local storage processor 218 accesses multiple storage channels 204 based on one or more memory access request queues 216. In some embodiments, local storage processor 218 writes to and reads from the multiple storage channels 204 based on storage blocks. Data from one or more storage blocks is jointly written to or read from multiple channels. Data in the same storage block is not written in parallel via more than one operation. Each storage block optionally corresponds to one or more storage pages. In one example, each storage block to be jointly written to or read from the multiple storage channels 204 has a size of 16 KB (e.g., one storage page). In another example, each storage block to be jointly written to or read from the multiple storage channels 204 has a size of 64 KB (e.g., four storage pages). In some embodiments, each page has 16 KB of user data and 2 KB of metadata. Additionally, the number of storage blocks to be jointly accessed and the size of each storage block can be configured for each of the system read, host read, system write, and host write operations.

[0036] In some embodiments, the local storage processor 218 stores data to be written to or read from each of the plurality of storage channels 204 in an SRAM buffer 224 of the controller 202. Alternatively, in some embodiments, the local storage processor 218 stores data to be written to or read from each of the plurality of storage channels 204 in a DRAM buffer 228A included in the storage device 200, for example by means of a DRAM controller 226. Alternatively, in some embodiments, the local storage processor 218 stores data to be written to or read from each of the plurality of storage channels 204 in a DRAM buffer 228B, the DRAM buffer being a component of the processor module 102 (…). Figure 1 The main memory used. The local storage processor 218 of controller 202 accesses the DRAM buffer 228B via host interface controller 222.

[0037] In some embodiments, data in multiple storage channels 204 is grouped into decoded blocks, and each decoded block is called a codeword. For example, each codeword contains n bits, where k bits correspond to user data, and (nk) corresponds to integrity data of the user data, where k and n are positive integers. In some embodiments, storage device 200 includes an integrity engine 230 (e.g., an LDPC engine) and a register 232 containing multiple registers or SRAM cells or flip-flops and coupled to the integrity engine 230. The integrity engine 230 is coupled to the storage channels 204 via a channel controller 214 and an SRAM buffer 224. Specifically, in some embodiments, the integrity engine 230 has a data path connection to the SRAM buffer 224, which is further connected to the channel controller 214 via a data path controlled by a local storage processor 218. The integrity engine 230 is configured to verify the data integrity of each decoded block of storage channel 204.

[0038] Figure 3A This is a schematic diagram of two versions 300P and 300C of an example firmware program 300, which stores control data in different locations of two corresponding control data structures 302P and 302C according to some embodiments. The two versions of firmware 300 include a current version 300C and a previous version 300P. The previous version 300P of firmware 300 includes a firmware control node 304P and a previous control data structure 302P used by the firmware program containing the firmware control node 304P. The firmware control node 304P is associated with a previous DDM 306P. The previous DDM 306P maps multiple previous data descriptors of multiple previous control data items to multiple previous locations in the previous control data structure 302P. The previous control data structure 302P stores multiple previous control data items 308P identified by the multiple previous data descriptors. The current version 300C of firmware 300 includes a firmware control node 304C and a current control data structure 302C used by the firmware program containing the firmware control node 304C. In some embodiments, the electronic device operates on a previous version 300P of firmware 300 and receives a request to update firmware 300 using the current version 300C. A firmware control node 304C is obtained using the current data descriptor mapping (DDM) 306C. The current DDM 306C maps multiple current data descriptors in multiple current control data items 308C to multiple current locations in the current control data structure 302C.

[0039] The current control data structure 302C is not received along with the request to update the firmware 300 and is determined based on the current DDM 306C. Specifically, the current control data structure 302C corresponding to the current version of the firmware 300 is automatically generated based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P. The current control data structure 302C stores multiple current control data items 308C, identified by multiple current data descriptors, in the current DDM 306C. The current control data structure 302C is stored in the storage device of the electronic device. In some embodiments, the electronic device implements the current version 300C of the firmware using the multiple current control data items 308C stored in the current control data structure 302C.

[0040] In some embodiments, both the current version 300C and the previous version 300P of the firmware use a first control data item 308A, which is specifically used in firmware control nodes 304C and 304P. The location of the first control data item 308A differs in the previous control data structure 302P and in the current control data structure 302C. During the process of generating the current control data structure 302C, the electronic device identifies a first data descriptor of the first control data item 308A in both the current DDM 306C and the previous DDM 306P. Based on the current DDM 306C, the first data descriptor corresponds to a first current position 310 in the current control data structure 302C. Based on the previous DDM 306P, the first data descriptor corresponds to a first previous position 312 in the previous control data structure 302P. The first control data item 308A identified by the first data descriptor from the first previous position 312 in the previous control data structure 302P is copied to the first current position 310 in the current control data structure 302C. Referring to FIG3, in some embodiments, the first current position 310 in the current control data structure 302C is represented by a shift 314 in the current DDM 306C, and the shift 314 is measured from the first previous position 312 to the first current position 310 in the current control data structure 302C. In some embodiments not shown, the first current position 310 in the current control data structure 302C is directly represented in the current DDM 306C by a shift measured relative to the start position of the current control data structure 302C, and is determined based on said shift.

[0041] Figure 3BThis is a diagram of an example DDM 306 (e.g., a previous DDM 306P, a current DDM 306C) according to some embodiments. DDM 306 maps multiple data descriptors 320 to multiple positions in a control data structure (e.g., 302P or 302C in FIG. 3) corresponding to a version of firmware 300. DDM 306 includes multiple fields, such as data descriptor 320, position 322, shift 324, reference 326, relative position 328, size 332, and data type 334. Data descriptors 320 are applied to identify control data items 308P or 308C. The position 322 of control data item 308P or 308C is measured relative to the start position of control data structure 302P or 302C. The shift 324 of control data item 308C corresponds to the positional difference of control data item 308C between the previous control data structure 302P and the current control data structure 302C. For control data item 308P or 308C, reference 326 identifies a reference data item within the same control data structure 302P or 302C, and the relative position 328 of control data item 308P or 308C corresponds to the positional difference between the control data item and the reference data item within control data structure 302P or 302C. Content data item 302P or 302C, identified by data descriptor 320, has a size 332 and a data type 334. The position of each content data item 308P or 308C is represented by any one of position 322, shift 324, and relative position 328.

[0042] Figure 4This is a schematic diagram of two versions 300P and 300C of an example firmware program 300, which stores different control data in different locations of two corresponding control data structures 302P and 302C according to some embodiments. The two versions of firmware program 300 include a current version 300C and a previous version 300P. The previous version 300P of firmware program 300 includes a firmware control node 304P and a previous control data structure 302P used by the firmware control node 304P. Firmware control node 304P is associated with a previous DDM 306P. The previous DDM 306P maps multiple previous data descriptors of multiple previous control data items to multiple previous locations in the previous control data structure 302P. The previous control data structure 302P stores multiple previous control data items 308P identified by the multiple previous data descriptors. The current version 300C of firmware program 300 includes a firmware control node 304C and a current control data structure 302C used by the firmware control node 304C. In some embodiments, the electronic device operates on a previous version 300P of firmware 300 and receives a request to update firmware 300 using the current version 300C. A firmware control node 304C is obtained using a current data descriptor mapping (DDM) 306C. The current DDM 306C maps multiple current data descriptors in multiple current control data items 308C to multiple current locations in a current control data structure 302C. The current control data structure 302C corresponding to the current version 300C of firmware 300 is automatically generated based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P. The current control data structure 302C stores multiple current control data items 308C identified by the multiple current data descriptors in the current DDM 306C.

[0043] Furthermore, in some embodiments, the electronic device identifies at least one or more second control data items 308B in the current control data structure 302C. Each second control data item 308B has a relative position 402 relative to a first current position 310 of a first control data item 308A. The current position 404 of one or more second control data items 308B in the current control data structure 302C is represented in the current DDM 306C by the first current position 310 and the relative position 402 of each second control data item 308B, and is determined based on the first current position and the relative position. In some scenarios (e.g., Figure 5 In the current control data structure 302C, the first current position 310 is shifted by referencing the first previous position 312 in the previous control data structure 302P. Alternatively, in some scenarios (e.g., Figure 4In the current control data structure 302C, the first current position 310 has the same position as the first previous position 312 in the previous control data structure 302P, and is not shifted with reference to the first previous position. In some embodiments not shown, the current position 404 of one or more second control data items 308B in the current control data structure 302C is represented in the current DDM 306C by a shift measured relative to the start position of the current control data structure 302C, and is determined based on said shift.

[0044] Figure 5 This is a schematic diagram of two versions 300P and 300C of firmware 300, representing another example of different control data stored in different locations in control data structures 302P and 302C according to some embodiments. For a previous version 300P of firmware 300, firmware control node 304P is associated with a previous DDM 306P. The previous DDM 306P maps multiple previous data descriptors of multiple previous control data items to multiple previous locations in the previous control data structure 302P. The previous control data structure 302P stores multiple previous control data items 308P identified by the multiple previous data descriptors. The current version 300C of firmware 300 includes firmware control node 304C and current control data structure 302C. When an electronic device operates on a previous version 300P of firmware 300, it receives a request to update firmware 300 using the current version 300C. Firmware control node 304C is obtained using the current data descriptor mapping (DDM) 306C. The current DDM 306C maps multiple current data descriptors in multiple current control data items 308C to multiple current locations in the current control data structure 302C. The current control data structure 302C corresponding to the current version 300C of firmware 300 is automatically generated based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P.

[0045] In some embodiments, the electronic device identifies one or more third control data items 308CC and a fourth control data item 308D in a previous control data structure 302P, and determines that one or more third control data items 308CC are not included in the current control data structure 302C and the fourth control data item 308D is included in the current control data structure 302C. Additionally, in some embodiments, the current position 502 of the fourth control data item 308D in the current control data structure 302C is represented by a relative position to a first current position 310 of the first control data item 308A, and is determined based on the first current position. Alternatively, in some embodiments not shown, the current position 502 of the fourth control data item 308D in the current control data structure 302C is represented by a shift measured relative to a previous position of the fourth control data item 308D in the previous control data structure 302P, and is determined based on said shift. Alternatively and in some embodiments not shown, the current position 502 of the fourth control data item 308D in the current control data structure 302C is represented by a shift measured relative to the start position of the current control data structure 302C, and is determined based on said shift.

[0046] Figure 6 This is a structural diagram of two additional instance control data structures 302P and 302C constructed according to some embodiments based on DDM 306P and 306C corresponding to two versions 300P and 300C of firmware 300. As explained above, the electronic device is currently operating on a previous version 300P of firmware 300 and receives a request to update firmware 300 corresponding to the current version 300C. A firmware control node 304P ( Figure 4 The previous version 300P of the firmware 300, including the previous DDM 306P and the previous control data structure 302P, is fully loaded onto the electronic device. The previous DDM 306P maps multiple previous data descriptors of multiple previous control data items to multiple previous locations in the previous control data structure 302P. For the current version 300C of the firmware 300, the firmware control node 304C is obtained through the current data descriptor mapping (DDM) 306C. The current DDM 306C maps multiple current data descriptors of multiple current control data items 308C to multiple current locations in the current control data structure 302C. In response to a request to update the firmware 300, the current control data structure 302C is automatically generated based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P.

[0047] In some embodiments, such as based on data descriptor 320 ( Figure 3BThe current DDM 306C is compared with the previous DDM 306P to determine whether there is at least one common control data item between the previous DDM 306P and the current DDM 306C. Based on the determination that there is at least one common control data item between the previous DDM 306P and the current DDM 306C, the current control data structure 302C is generated at least in part based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P. In other words, in some embodiments, the current DDM 306C is compared with the previous DDM 306P to determine whether there is any change between the previous control data structure 302P and the current control data structure 302C. The current control data structure 302C is automatically generated based on the determination that the previous control data structure 302P and the current control data structure 302C are different from each other. Conversely, in some embodiments, the current DDM 306C is associated with the previous control data structure 302P based on the determination that there is no change between the previous control data structure 302P and the current control data structure 302C. Previously, the control data structure 302P was used directly in the current version 300C of the firmware.

[0048] In some embodiments, firmware 300 includes multiple historical versions loaded prior to the current version 300C. For example, the electronic device searches for the first data descriptor (in...) of the first control data item 308A in multiple historical DDMs corresponding to multiple historical versions of firmware 300. Figure 3A and 6 (In both cases), starting from the latest version, until the first data descriptor is identified in the previous DDM 306P corresponding to the previous version 300P of firmware 300. Additionally, in some embodiments, the previous version 300P is not the latest version among multiple historical versions. Instead, in some embodiments, the previous version 300P is the latest version among multiple historical versions.

[0049] In other words, in some embodiments, the current version 300C and the previous version 300P are two consecutive versions of firmware 300, with the current version 300C immediately following the previous version 300P. At least one of the current content data items 308C is generated based on the previous version 300P immediately preceding the current version 300C (FIG. 3). Alternatively, in some embodiments, the current version 300C and the previous version 300P are not two consecutive versions of firmware 300, and the current version 300C is at least two or more versions following the previous version 300P. At least one of the current content data items 308C (FIG. 3) is generated based on a previous version 300P that is two or more versions earlier than the current version 300C.

[0050] Alternatively, in some embodiments, two subsets of the current content data item 308C (FIG. 3) are generated based on two prior versions 300P earlier than the current version 300C. A first subset of the current content data item 308C (FIG. 3) is generated based on a first prior version 300P of firmware 300, and a second subset of the current content data item 308C (FIG. 3) is generated based on a second prior version 300P of firmware 300. Specifically, two different control data items 308P, identified by two different data descriptors 320, are copied from two previous positions in two previous control data structures 302P corresponding to the two different prior versions 300P of firmware 300 to the current control data structure 302C. More specifically, in some embodiments, a prior DDM 306P contains a first prior DDM corresponding to the first prior version of firmware 300. A second prior DDM and a second prior control data structure corresponding to the second prior version of firmware are identified in the storage device. The current control data structure 302C corresponding to the current version 300C of firmware 300 is generated based on the previous control data structure associated with the first previous version of firmware, the current DDM, the first previous DDM, the second previous DDM, and the second previous control data structure.

[0051] In some embodiments, the previous control data structure 302P includes multiple portions 302P1, 302P2, and 302P3, and the current control data structure 302C includes multiple portions 302C1, 302C2, and 302C3. In some embodiments, the two corresponding portions 302P1 and 302C1 have the same size. For example, portion 302P1 of the previous control data structure 302P reserves some unused space sufficient to accommodate storage of an additional fifth content data item 308E. In some embodiments, the content data item (“Item 2”) is not used in the current version 300C, and the associated memory space is not mapped in the current DDM 306C, while subsequent content data items are not moved and continue to be stored at their original addresses. In some embodiments, the two corresponding portions 302P2 and 302C2 have different sizes. For example, portion 302C2 of the current control data structure 302C is expanded so that new content data items (e.g., "Item 3" and "Item 4") are added to portion 302C2 of the current control data structure 302C. As a result, all content data items 308C stored in portion 302C3 are shifted within the current control data structure 302C.

[0052] In some embodiments, each current position in a subset of multiple current positions of control data item 308 includes a corresponding current offset measured relative to the start position 602C of the current control data structure 302C (e.g., with). Figure 3B(Associated with position 322 in the middle). In some embodiments, each current position in a subset of multiple current positions of control data item 308 includes a corresponding current offset measured relative to the start position of a portion of the current control data structure 302C (e.g., 302C1, 302C2, and 302C3). For example, each of the current control data items 308C in the second portion 302C2 of the current control data structure 302C (e.g., "Item 1", "Item 2", "Item 3", "Item 4", and "Item 5") is represented by its corresponding current offset relative to the start position 602C of the entire structure 302C and the start position 602C2 of the second portion 302C2 of the structure 302C. In some embodiments, each previous position in a subset of multiple previous positions includes a corresponding previous offset measured relative to the start position 602C of the previous control data structure 302P. In some embodiments, each of the subsets of previous positions includes a corresponding previous offset measured relative to the start position of a portion of the previous control data structure 302P (e.g., 302P1, 302P2, and 302P3). For example, each of the previous control data items 308P (e.g., "Item 1", "Item 2") in the second portion 302P2 of the previous control data structure 302P is represented by a corresponding previous offset relative to either the start position 602P of the entire structure 302P or the start position 602P2 of the second portion 302P2 of the structure 302P.

[0053] In some embodiments, the electronic device obtains a fifth control data item 308E (e.g., "Item 6" and "Item 4 Index 3") using the current version 300C of the firmware, and identifies a fifth data descriptor for the fifth control data item 308E in the current DDM 306C. Based on the current DDM 306C, it is determined that the fifth data descriptor corresponds to a fifth current position 604 in the current control data structure 302C, and based on the previous DDM 306P, it is determined that the fifth data descriptor is not in the previous control data structure 302P. The electronic device stores the fifth control data item 308E (e.g., "Item 4 Index 3" and "Item 6") identified by the fifth data descriptor at the fifth current position 604 in the current control data structure 302C. Furthermore, in some embodiments, the electronic device identifies one or more sixth control data items 308F (e.g., "Item 5") located at or near a fifth previous position 606 corresponding to the fifth current position 604. One or more sixth control data items 308F are determined to be contained within both the previous control data structure 302P and the current control data structure 302C. The current position of one or more sixth control data items 308F in the current control data structure is determined based on the fifth current position 604 of the fifth control data item 308E. For example, two control data items, "Item 6" and "Item 4 Index 3", are inserted between two other control data items, "Item 4 Index 2" and "Item 5". The position of control data item "Item 5" is shifted to allow the two control data items "Item 6" and "Item 4 Index 3" to be inserted into the first part of the current control data structure 302C.

[0054] refer to Figure 6 In some embodiments, the previous DDM 306P is compared with the current DDM 306C to identify changes between control data structures 302P and 302C. In the first portions 302P1 and 302C1 between firmware N and firmware N + x, item 2 is removed, "item 4" has another added element (e.g., "item 4 index 3"), and "item 6" is added after "item 4". Due to the previous two changes, "item 5" is shifted down. DDMs 306P and 306C are used to detect these changes and automatically adjust the position of content data item 308C in the current control data structure 302C. In some scenarios, DDMs 306P and 306C are used to detect possible changes in the current control data structure 302C that may affect any structural changes encapsulated after the current control data structure. For example, "item 3" and "item 4" are added to the second portion 302C2 of the current control data structure 302C, causing the second portion 302C2 to expand beyond its reserved space. Additionally, in some embodiments, the third portion 302C3, located after the second portion 302C2, is moved downwards.

[0055] Table 1 is a list of data formats applied to data entries in a DDM file containing DDM 306 according to some embodiments. The DDM file contains multiple columns and multiple rows. The DDM file corresponds to a tree, where each non-leaf node is a structure array and each leaf node is a basic data type (int, uint). This file is built whenever a version of firmware 300 is built and attached to firmware 300. When firmware is sent as an update to an electronic device, the electronic device extracts an older version DDM 306P from an earlier version DDM file of the older version 300P of the firmware, compares the older version DDM 306P with the newer version DDM 306C attached to the firmware, and determines whether there is a change between the two DDMs 306P and 306C. Based on the determination that there is a change from the older version DDM 306P to the newer version DDM 306C, the storage device 200 determines, based on the older version DDM 306P and the newer version DDM 306C, whether the previous control data structure 302P can be converted to the current control data structure 302C.

[0056]

[0057] Table 1. List of examples of data formats for DDM data entries.

[0058] Figure 7This is a flowchart of an example method 700 for managing firmware control data in an electronic device according to some embodiments. The electronic system includes a host device 220 and a storage device 200 coupled to the host device 220. The electronic device obtains (operation 702) a current data descriptor mapping (DDM) corresponding to the current version 300C of firmware 300. The current DDM 306C maps (operation 704) a plurality of current data descriptors to a plurality of current locations in a current control data structure 302C. The electronic device identifies (operation 706) a previous DDM 306P and a previous control data structure 302P corresponding to a previous version 300P of firmware 300 in the storage device. The previous DDM 306P maps (operation 708) a plurality of previous data descriptors to a plurality of previous locations in the previous control data structure 302P, and the previous control data structure 302P stores (operation 710) a plurality of previous control data items 308P identified by the plurality of previous data descriptors. The electronic device automatically generates (operation 712) a current control data structure 302C corresponding to the current version 300C of firmware 300 based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P. The current control data structure 302C stores (operation 714) a plurality of current control data items 308C identified by the plurality of current data descriptors. The electronic device stores (operation 716) the current control data structure 302C in a storage device. In some embodiments, the electronic device implements (operation 718) the current version 300C of firmware 300 on the electronic device using the plurality of current control data items 308C stored in the current control data structure 302C.

[0059] In some embodiments, the electronic device automatically generates the current control data structure 302C by: identifying a first data descriptor for a first control data item 308A in both the current DDM 306C and the previous DDM 306P; determining, based on the current DDM 306C, that the first data descriptor corresponds to a first current position 310 in the current control data structure 302C; determining, based on the previous DDM 306P, that the first data descriptor corresponds to a first previous position 312 in the previous control data structure 302P; and assigning the first control data item 308A identified by the first data descriptor ( Figure 3A The data is copied from a first previous position 312 in the previous control data structure 302P to a first current position 310 in the current control data structure 302C. Furthermore, in some embodiments, the first current position 310 in the current control data structure 302C is represented by a shift from the first previous position 312 in the previous control data structure 302P. In some embodiments, the electronic device identifies one or more second control data items 308B in the current control data structure 302C. Figure 4 Each second control data item 308B has a relative position to a first current position 310 of the first control data item 308A. The electronic device determines the current position of one or more second control data items 308B in the current control data structure 302C based on the first current position 310 and the relative position. In some embodiments, the electronic device identifies one or more third control data items 308CC and fourth control data items 308D in the previous control data structure 302P. Figure 5 The system determines that one or more third control data items 308CC are not included in the current control data structure 302C and the fourth control data item 308D is included in the current control data structure 302C, and determines the current position of the fourth control data item 308D in the current control data structure 302C based on the first current position 310 of the first control data item 308A.

[0060] In some embodiments, the electronic device automatically generates the current control data structure 302C by obtaining the fifth control data item 308E using the current version 300C of firmware 300. Figure 6 The device identifies the fifth data descriptor of the fifth control data item 308E in the current DDM 306C; determines, based on the current DDM 306C, that the fifth data descriptor corresponds to the fifth current position in the current control data structure 302C and determines, based on the previous DDM 306P, that the fifth data descriptor is not in the previous control data structure 302P; and stores the fifth control data item 308E identified by the fifth data descriptor at the fifth current position in the current control data structure 302C. Furthermore, in some embodiments, the electronic device identifies one or more sixth control data items 308F located at or near the fifth previous position corresponding to the fifth current position. Figure 6 The method determines that one or more sixth control data items 308F are included in both the previous control data structure 302P and the current control data structure 302C, and determines the current position of one or more sixth control data items 308F in the current control data structure 302C based on the fifth current position of the fifth control data item 308E.

[0061] In some embodiments, each current position in a subset of multiple current positions includes a corresponding current offset measured relative to the start position 602C or 602C2 of the current control data structure 302C, and each previous position in a subset of multiple previous positions includes a corresponding previous offset measured relative to the start position 602P or 602P2 of the previous control data structure 302P.

[0062] In some embodiments, firmware 300 includes multiple historical versions loaded prior to the current version 300C. The electronic device searches for a first data descriptor for a first control data item 308A in multiple historical DDMs corresponding to multiple historical versions of firmware 300, starting from the latest version and continuing until a first data descriptor is identified in a previous DDM 306P corresponding to a previous version 300P of firmware 300. Additionally, in some embodiments, the previous version 300P is not necessarily the latest version among the multiple historical versions.

[0063] In some embodiments, the electronic device compares the current DDM 306C with the previous DDM 306P to determine whether there is at least one common control data item between the previous DDM 306P and the current DDM 306C. Based on the determination that there is at least one common control data item between the previous DDM 306P and the current DDM 306C, the current control data structure 302C is generated at least in part based on the previous control data structure 302P, the current DDM 306C, and the previous DDM 306P.

[0064] In some embodiments, the prior DDM 306P includes a first prior DDM 306P corresponding to a first prior version of firmware 300. The electronic device identifies a second prior DDM 306P and a second prior control data structure 302P corresponding to a second prior version of firmware 300 in a storage device. A current control data structure 302C corresponding to the current version 300C of firmware 300 is generated based on the prior control data structure 302P associated with the first prior version of firmware 300, the current DDM 306C, the first prior DDM 306P, the second prior DDM 306P, and the second prior control data structure 302P.

[0065] In some embodiments, the electronic device uses two different data descriptors 320 ( Figure 3B The two different control data items 308P identified are copied from two previous positions in two previous control data structures 302P corresponding to two different previous versions 300P of firmware program 300 to the current control data structure 302C, thereby automatically generating the current control data structure 302C.

[0066] In some embodiments, the electronic device compares the current DDM 306C with the previous DDM 306P to determine whether there are any changes between the previous control data structure 302P and the current control data structure 302C. The current control data structure 302C is automatically generated based on the determination that the previous control data structure 302P and the current control data structure 302C are different from each other.

[0067] In some embodiments, the electronic device compares the current DDM 306C with the previous DDM 306P to determine whether there are any changes between the previous control data structure 302P and the current control data structure 302C. The electronic device automatically generates the current control data structure 302C by associating the current DDM 306C with the previous control data structure 302P based on the determination that there are no changes between the previous control data structure 302P and the current control data structure 302C.

[0068] In some embodiments of this application, the compiler generates a DDM 306P or 306C, which is used to automatically translate control data into unique identifiers or descriptors describing each data segment in the control data. For example, the unique identifier or descriptor of the DDM 306P or 306C includes one or more of the following: the name, location, size, and type of each data item in the control data, and the DDM 306P or 306C stores the unique identifier or descriptor along with the control data. In some embodiments, any copied or duplicated data (array, structure array) is recorded only in the DDM 306P or 306C. In one instance, the DDM 306P or 306C corresponds to 1 megabyte of data and includes a few bytes of data description. During a firmware update, the DDM 306P or 306C of the control data currently stored on the device is compared with the DDM 306P or 306C of the control data expected after the firmware update, and the differences between the two DDM 306P and 306C are identified, and the differences are used to provide a control data structure for the firmware update.

[0069] DDM 306P and 306C allow for automatic translation of data structures without human intervention because they contain information about control data applied by the firmware. In some embodiments, new versions of the control data contain new fields, and DDM 306P and 306C support the initial values ​​of those fields. In some embodiments, the control data changes only at specific times (e.g., during firmware updates), and comparisons between DDM 306P and 306C are only needed at those times. The firmware operates normally at all other times without being interrupted by updates to DDM 306P and 306C. In some embodiments, DDM 306P and 306C are automatically generated at build time and are used to detect changes at multiple stages of the firmware release process with minimal human intervention. In some embodiments, DDM 306P and 306C are generated as part of the firmware build process, and therefore, changes to data structure versions are not missed due to human error. If all consumer-facing binaries of the DDM 306P and 306C are retained as part of the release process, the pre-release firmware may optionally be reliably compared and verified against the proposed upgrade target before being released to consumers.

[0070] The DDM 306P and 306C automate firmware upgrades and downgrades. In some cases, consumers request firmware downgrades. However, manual upgrades will not allow downgrades because program code used to transform data in firmware N+x will be written. Firmware N is unaware of future events and therefore cannot contain any rollback conversion code. This is no longer an issue if the DDM 306P or 306C properly identifies and can convert the changes. Since the DDM 306P and 306C are generic in terms of data size and default value descriptions, custom routines for performing conversions between data structure formats are entirely unnecessary. Using generic conversion routines to handle any relevant DDM set saves on custom conversion development, verification, and omission detection.

[0071] Additionally, in some embodiments, DDM 306P and 306C eliminate the need for excessively reserved data structures to accommodate potential minor revision rollovers. DDMs are self-descriptive, and the keys are uniquely hashed over the firmware's lifetime. Any possible translation for upgrades / downgrades between DDM 306P and 306C is possible. There are no compatibility issues between different firmware versions. In some embodiments, DDMs implement the advantages of self-descriptive file formats (such as YAML / JSON / XML) without using large RAM, media footprint, or unbounded ASCII descriptors. This is extremely well-suited for resource-constrained embedded environments (e.g., embedded devices) where low bill of materials (BOM) costs, predictable latency, and minimal firmware complexity are desirable.

[0072] One detection method involves examining the absence of versioned data if a competitor switches from having versioned data to not having versioned data (a strong indicator of potential infringement). The absence of versioned data can be detected by examining the physical payload and header / metadata of files frequently written to media (which are typically written in plain text), or alternatively, by the absence of a declared versioning of the binary released to consumers. Additionally, if a competitor locks its updates based on version numbers, it is not infringing; however, if it suddenly switches from locking the version structure to allowing updates, this can be a strong indication of infringement. Smooth firmware updates observed by consumers accustomed to restrictions or circumvention schemes from electronic device vendors' binary versions are an additional indicator of potential infringement. Corresponding to the foregoing: published product documentation, marketing materials, or field application engineering change updates requesting robust improvements to compatibility-related firmware updates will warrant further evaluation of potential infringement.

[0073] The memory is also used to store instructions and data associated with method 700, and includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state storage devices; and optionally includes non-volatile memory, such as one or more disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory optionally includes one or more storage devices located remotely to one or more processing units. The memory, or alternatively, non-volatile memory within the memory, includes a non-transitory computer-readable storage medium. In some embodiments, the memory or the non-transitory computer-readable storage medium of the memory stores programs, modules, and data structures, subsets, or supersets for implementing method 700.

[0074] Each of the elements identified above may be stored in one or more of the previously mentioned storage devices and corresponds to a set of instructions for performing the functions described above. The modules or programs identified above (e.g., instruction sets) need not be implemented as separate software programs, processes, modules, or data structures, and therefore, in various embodiments, various subsets of these modules may be combined or otherwise rearranged. In some embodiments, the memory optionally stores a subset of the modules and data structures identified above. Furthermore, the memory optionally stores additional modules and data structures not described above.

[0075] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various described embodiments and the appended claims, the singular forms “a” and “described” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. It should be further understood that the terms “comprising” and / or “including”, when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Furthermore, it should be understood that although the terms “first,” “second,” etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another.

[0076] As used herein, depending on the context, the term "if" may optionally be interpreted as meaning "when," "after," "in response to determination," "in response to detection," or "according to determination." Similarly, depending on the context, the phrase "if determination" or "if [the stated condition or event] is detected" may optionally be interpreted as meaning "after determination," "in response to determination," "after detection of [the stated condition or event]," "in response to detection of [the stated condition or event]," or "according to determination of detection of [the stated condition or event]."

[0077] For illustrative purposes, the foregoing description has been described with reference to specific embodiments. However, the illustrative discussion above is not intended to be exhaustive or to limit the claims to the precise form disclosed. Many modifications and variations are possible in light of the foregoing teachings. The embodiments were chosen and described to best explain the operating principles and practical applications, thereby enabling those skilled in the art to understand.

[0078] Although various diagrams depict several logical stages in a specific order, stages independent of order can be reordered and other stages can be combined or decomposed. While some reorderings or other groupings are specifically mentioned, other reorderings or groupings will be obvious to those skilled in the art, and therefore the orderings and groupings presented herein are not an exhaustive list of alternatives. Furthermore, it should be recognized that the stages can be implemented in hardware, firmware, software, or any combination thereof.

Claims

1. A method implemented in an electronic device including a storage device, characterized in that, include: Obtain the current data descriptor mapping (DDM) corresponding to the current version of the firmware program, wherein the current DDM maps multiple current data descriptors to multiple current locations in the current control data structure; The storage device identifies a previous DDM and a previous control data structure corresponding to a previous version of the firmware, wherein the previous DDM maps a plurality of previous data descriptors to a plurality of previous locations in the previous control data structure, and the previous control data structure stores a plurality of previous control data items identified by the plurality of previous data descriptors. Based on the previous control data structure, the current DDM, and the previous DDM, the current control data structure corresponding to the current version of the firmware is automatically generated, wherein the current control data structure stores multiple current control data items identified by the multiple current data descriptors; as well as The current control data structure is stored in the storage device.

2. The method according to claim 1, further comprising: The current version of the firmware is implemented on the electronic device using the plurality of current control data items stored in the current control data structure.

3. The method according to claim 1 or 2, wherein automatically generating the current control data structure further comprises: A first data descriptor is used to identify a first control data item in both the current DDM and the previous DDM; Based on the current DDM, the first data descriptor corresponds to the first current position in the current control data structure; Based on the previous DDM, the first data descriptor corresponds to a first previous position in the previous control data structure; as well as The first control data item, identified by the first data descriptor, is copied from the first previous position in the previous control data structure to the first current position in the current control data structure.

4. The method of claim 3, wherein the first current position in the current control data structure is represented by a shift from the first previous position in the previous control data structure.

5. The method according to claim 3 or 4, further comprising: Identify one or more second control data items in the current control data structure, each second control data item having a relative position to the first current position of the first control data item; as well as The current position of one or more second control data items in the current control data structure is determined based on the first current position and the relative position.

6. The method according to any one of claims 3 to 5, further comprising: Identify one or more third control data items and one fourth control data item in the previously defined control data structure; It is determined that the one or more third control data items are not included in the current control data structure, and the fourth control data item is included in the current control data structure; as well as The current position of the fourth control data item in the current control data structure is determined based on the first current position of the first control data item.

7. The method according to any one of claims 1 to 6, wherein automatically generating the current control data structure further comprises: The fifth control data item is obtained using the current version of the firmware program; Identify the fifth data descriptor of the fifth control data item in the current DDM; Based on the current DDM, it is determined that the fifth data descriptor corresponds to the fifth current position in the current control data structure, and based on the previous DDM, it is determined that the fifth data descriptor is not in the previous control data structure; as well as The fifth control data item, identified by the fifth data descriptor, is stored at the fifth current position in the current control data structure.

8. The method of claim 7, further comprising: Identify one or more sixth control data items located at or near the fifth previous position corresponding to the fifth current position; Determine that the one or more sixth control data items are included in both the previous control data structure and the current control data structure; as well as The current position of one or more sixth control data items in the current control data structure is determined based on the fifth current position of the fifth control data item.

9. The method of any one of claims 1 to 8, wherein each current position in a subset of the plurality of current positions includes a corresponding current offset measured relative to the start position of the current control data structure, and each previous position in a subset of the plurality of previous positions includes a corresponding previous offset measured relative to the start position of the previous control data structure.

10. The method according to any one of claims 1 to 9, wherein the firmware program includes a plurality of historical versions loaded prior to the current version, the method further comprising: Search for a first data descriptor for a first control data item in multiple historical DDMs corresponding to multiple historical versions of the firmware, starting from the latest version and continuing until the first data descriptor is identified in the previous DDM corresponding to the previous version of the firmware.

11. The method of claim 10, wherein the prior version is not the latest version among the plurality of historical versions.

12. The method according to any one of claims 1 to 11, further comprising: Compare the current DDM with the previous DDM to determine whether there is at least one common control data item between the previous DDM and the current DDM; The current control data structure is generated based at least in part on the previous control data structure, the current DDM, and the previous DDM, based on the determination that there is at least one common control data item between the previous DDM and the current DDM.

13. The method of any one of claims 1 to 12, wherein the prior DDM comprises a first prior DDM corresponding to a first prior version of the firmware, the method further comprising: The storage device identifies a second prior DDM and a second prior control data structure corresponding to a second prior version of the firmware program. The current control data structure corresponding to the current version of the firmware is generated based on the previous control data structure associated with the first previous version of the firmware, the current DDM, the first previous DDM, the second previous DDM, and the second previous control data structure.

14. The method according to any one of claims 1 to 13, wherein automatically generating the current control data structure further comprises: Two different control data items, identified by two different data descriptors, are copied from two previous positions in two previous control data structures corresponding to two different previous versions of the firmware to the current control data structure.

15. The method according to any one of claims 1 to 14, further comprising: The current DDM is compared with the previous DDM to determine whether there are any changes between the previous control data structure and the current control data structure, wherein the current control data structure is automatically generated based on the determination that the previous control data structure and the current control data structure are different from each other.

16. The method according to any one of claims 1 to 14, further comprising: The current DDM is compared with the previous DDM to determine whether there are any changes between the previous control data structure and the current control data structure, wherein automatically generating the current control data structure further includes associating the current DDM with the previous control data structure based on the determination that there are no changes between the previous control data structure and the current control data structure.

17. An electronic device, characterized in that, include: One or more processors; Storage device; as well as A memory storing one or more programs for execution by the one or more processors, the one or more programs further comprising instructions for performing the method according to any one of claims 1 to 16.

18. A non-transitory computer-readable storage medium storing one or more programs for execution by one or more processors, the one or more programs further comprising instructions for performing the method according to any one of claims 1 to 16.

Images