Operation method, memory system, system and readable storage medium

Abstract

The embodiment of the invention discloses an operation method, a memory system, a system and a readable storage medium. Wherein the memory system comprises a communication interface configured to: receive an executable file of a set format; the executable file comprises a file header and a plurality of segments of executable codes; each section of executable code in the multiple sections of executable codes comprises code section data and a code section head; the code segment header is configured to indicate a storage location of the code segment data in the memory system.

Description

Operating method, memory system, system and readable storage medium Technical Field

[0001] The present disclosure relates to the field of storage technology, and in particular to an operating method, a memory system, a system, and a readable storage medium. Background Art

[0002] With the development of electronic products, their variety has increased. Users are also placing higher demands on their usage scenarios and functionality, leading to an increasing number of CPUs in these products. Currently, software development for electronic products involves an ever-increasing amount of code and numerous versions. Efficiently and conveniently downloading the required code from a host computer to an electronic product for firmware upgrades has always been a key concern in the development of electronic products.

[0003] Summary of the Invention

[0004] In view of this, the present disclosure provides an operating method of a memory system, a memory system, a system, and a computer-readable storage medium.

[0005] To achieve the above objectives, the technical solution of the present disclosure is implemented as follows:

[0006] In a first aspect, an embodiment of the present disclosure provides a memory system, including:

[0007] A communication interface is configured to: receive an executable file in a set format; the executable file includes: a file header and multiple executable code segments; each of the multiple executable code segments includes code segment data and a code segment header; the code segment header is configured to indicate a storage location of the code segment data in the memory system.

[0008] In the above solution, the code segment header at least includes: length information of the code segment data and first indication information of the storage location.

[0009] In the above solution, the code segment header further includes: an identifier configured to indicate a specific purpose of the code segment data.

[0010] In the above solution, the first indication information includes the address number of the storage area corresponding to the storage location; the storage area includes one or more minimum management units; and the minimum management unit is a storage page or a data slice.

[0011] In the above solution, the identifier is an identifier for distinguishing different firmware slots.

[0012] In the above solution, the file header at least includes: verification information; the verification information is configured to verify whether the multiple segments of executable code are received or sent completely.

[0013] In the above solution, the file header further includes: second indication information; the second indication information is configured to indicate the firmware slot to which each executable code segment in the multiple executable code segments belongs.

[0014] In the above solution, the firmware slots to which the code segment data in the multiple executable code segments belong include one of the following: completely identical, partially identical, and completely different.

[0015] In the above solution, the executable file is a binary BIN format file.

[0016] In the above scheme, the memory system further includes: a memory controller coupled to the communication interface, and configured to: cache the executable file transmitted from the communication interface; parse the executable file to obtain multiple code segment data contained in the executable file and a code segment header corresponding to each code segment data; and write the corresponding code segment data to the corresponding storage location according to each code segment header.

[0017] In the above solution, the memory system further comprises: a storage interface and one or more memory devices; wherein,

[0018] The memory controller is coupled to the storage interface and is further configured to: generate one or more write commands according to each piece of the code segment data and the corresponding code segment header; and send the one or more write commands to the memory device through the storage interface;

[0019] The one or more memory devices are coupled to the storage interface and are configured to: receive the one or more write commands through the storage interface; and in response to the one or more write commands, write each code segment data to a storage location indicated by a code segment header corresponding to a non-volatile storage medium in the memory device.

[0020] In the above solution, the memory device includes a 3D NAND storage medium.

[0021] In the above solution, the memory system is contained in a memory card or an SSD.

[0022] In a second aspect, an embodiment of the present disclosure provides a method for operating a memory system, the method comprising:

[0023] Receiving an executable file in a set format through a communication interface of the memory system; wherein the executable file comprises: a file header and multiple executable code segments; each of the multiple executable code segments comprises code segment data and a code segment header; the code segment header is configured to indicate a storage location of the code segment data in the memory system;

[0024] Run the first processing program; wherein, when the first processing program is run, the following steps are performed:

[0025] Parsing the executable file to obtain multiple code segment data contained in the executable file and a code segment header corresponding to each code segment data;

[0026] According to each code segment header, the corresponding code segment data is written into the corresponding storage location.

[0027] In the above solution, the operation method further includes:

[0028] In response to a startup enable signal, the memory system is started; a second processing program is loaded and run, wherein when the second processing program is run, at least the following steps are performed: loading the first processing program and running the first processing program.

[0029] In a third aspect, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of any of the above methods when executed by a processor.

[0030] In a fourth aspect, an embodiment of the present disclosure provides a system, including:

[0031] The memory system according to any one of the preceding claims;

[0032] and a host coupled to the memory system and configured to control the memory system.

[0033] In the above solution, the memory system is configured as follows:

[0034] Run the first processing program; wherein, when the first processing program is run, the following steps are performed:

[0035] Parsing the executable file to obtain multiple code segment data and a code segment header corresponding to each code segment data segment included in the executable file;

[0036] According to each code segment header, the corresponding code segment data is written into the corresponding storage location.

[0037] In the above scheme, the memory system is further configured to: start the memory system in response to a start enable signal; load and run a second processing program, wherein when the second processing program is running, at least the following steps are performed: load the first processing program and run the first processing program.

[0038] In the above solution, the host is configured to: generate the executable file;

[0039] Converting the executable file to form an executable file in the set format;

[0040] The executable file in the set format is sent to the memory system.

[0041] The embodiments of the present disclosure provide an operating method of a memory system, a memory system, a system and a computer-readable storage medium. The memory system includes a communication interface, which is configured to: receive an executable file in a set format; the executable file includes: a file header and multiple segments of executable code; each segment of the multiple segments of executable code includes code segment data and a code segment header; the code segment header is configured to indicate the storage location of the code segment data in the memory system. The memory system provided by the embodiments of the present disclosure provides a communication interface, which receives an executable file in a set format, and the executable file contains multiple segments of executable code to achieve simultaneous storage of multiple code data segments. Moreover, each code data segment in the executable file corresponds to a code segment header to indicate the corresponding code segment data storage location, which can efficiently and conveniently download the required firmware code from the host computer (host) side to the electronic product side, and can quickly store it in the corresponding location. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In the accompanying drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. Like numerals with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate various embodiments discussed in this document by way of example and not limitation.

[0043] FIG1 illustrates a system block diagram of an exemplary electronic device having a memory system;

[0044] FIG2 shows a schematic structural diagram of a memory controller in a memory system;

[0045] FIG3 is a schematic diagram showing a structure of a memory device in a memory system;

[0046] FIG4 is a schematic diagram showing an interaction process between a download program of a host and a download processing program of an electronic product in a related art;

[0047] FIG5 is a schematic diagram showing an interaction process between a download program of a host and a download processing program of an electronic product in another related art;

[0048] FIG6 shows a schematic structural diagram of a memory system provided by an example of the present disclosure;

[0049] FIG7 shows a schematic diagram of the structure of an executable file provided by an embodiment of the present disclosure;

[0050] FIG8 shows a schematic structural diagram of a code segment header provided by an embodiment of the present disclosure;

[0051] FIG9 is a schematic diagram showing an interaction flow between a download program of a host and a download processing program of an electronic product provided by an embodiment of the present disclosure;

[0052] FIG10 is a schematic diagram showing the interaction flow between a download program of a host and a download processing program of the electronic product when the electronic product provided by an embodiment of the present disclosure can directly operate a memory device in a memory system contained therein;

[0053] FIG11 is a schematic diagram showing the interaction flow between a download program of a host and a download processing program of the electronic product when the electronic product cannot directly operate a memory device in a memory system included therein, according to an embodiment of the present disclosure;

[0054] FIG12 shows another schematic structural diagram of a code segment header provided by an embodiment of the present disclosure;

[0055] FIG13 shows a schematic structural diagram of a memory card provided by an embodiment of the present disclosure;

[0056] FIG14 shows a schematic structural diagram of an SSD provided by an embodiment of the present disclosure;

[0057] FIG15 is a schematic flow chart showing an operating method of a memory system according to an embodiment of the present disclosure;

[0058] FIG16 is a schematic diagram showing the structure of a system provided by the disclosed embodiment;

[0059] FIG17 shows a flowchart of host-side processing in the system shown in FIG16 ;

[0060] FIG. 18 is a flowchart showing the processing on the electronic product side in the system shown in FIG. 16 . DETAILED DESCRIPTION

[0061] The following describes various embodiments of the present disclosure in more detail with reference to the accompanying drawings. Other embodiments that can be used as variations of any disclosed embodiment can be formed by configuring or arranging the elements and features in the embodiments of the present disclosure in different ways. Therefore, the embodiments of the present disclosure are not limited to the embodiments set forth herein. On the contrary, the described embodiments are provided so that the embodiments of the present disclosure are thorough and complete, and the scope of the embodiments of the present disclosure is fully conveyed to those skilled in the art of the technical field to which the embodiments of the present disclosure belong. It should be noted that references to "embodiment", "another embodiment" and the like do not necessarily represent only one embodiment, and different references to any such phrases are not necessarily for the same embodiment. It should be understood that although the terms "first", "second", "third" and the like may be used herein to identify various elements, these elements are not limited by these terms. These terms are used to distinguish one element from another element with the same or similar name. Therefore, without departing from the spirit and scope of the embodiments of the present disclosure, the first element in one embodiment may also be referred to as the second or third element in another embodiment.

[0062] The accompanying drawings are not necessarily drawn to scale, and in some cases, the scale may be exaggerated to clearly illustrate the features of the embodiments. When an element is referred to as being connected or coupled to another element, it should be understood that the former may be directly connected or coupled to the latter, or may be electrically connected or coupled to the latter via one or more intermediate elements therebetween. In addition, it should be understood that when an element is referred to as being "between" two elements, the element may be the only element between the two elements, or one or more intermediate elements may be present.

[0063] The terms used in this article are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure. As used herein, the singular form is intended to include the plural form, unless the context clearly indicates otherwise. Unless otherwise specified or can be clearly understood from the context to be singular, the articles "one" and / or "an" used in the embodiments of the present disclosure and the appended claims should be collectively interpreted as meaning "one or more". It should be further understood that the terms "include", "include", "include" and "include" used in the embodiments of the present disclosure specify the presence of the elements and do not exclude the presence or addition of one or more other elements. The term "and / or" used in the embodiments of the present disclosure includes any and all combinations of one or more associated listed items. Unless otherwise defined, all terms including technology and science used in the embodiments of the present disclosure have the same meaning as those of ordinary skill in the art to which the present disclosure belongs in view of the embodiments of the present disclosure. It should be further understood that, unless the embodiments of the present disclosure are clearly defined, terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the embodiments of the present disclosure and the related art, and should not be interpreted in an idealized or overly formal manner.

[0064] In the following description, many specific details are set forth to provide a thorough understanding of the present disclosure, and the present disclosure can be practiced without some or all of these specific details. In other cases, well-known processing structures and / or processes are not described in detail to avoid unnecessarily obscuring the present disclosure. It should also be understood that in some cases, unless otherwise specified, it will be apparent to those skilled in the relevant art that features or elements described with respect to one embodiment may be used alone or in combination with other features or elements of another embodiment. Hereinafter, various embodiments of the present disclosure are described in detail with reference to the accompanying drawings. The following description focuses on details to facilitate understanding of the embodiments of the present disclosure. Well-known technical details may be omitted to avoid obscuring the features and aspects of the embodiments of the present disclosure.

[0065] The embodiments of the present disclosure are further described in detail below with reference to the accompanying drawings and specific embodiments.

[0066] FIG1 shows a block diagram of a system of an exemplary electronic device with a storage system. In FIG1 , the electronic device may be a mobile phone, a desktop computer, a laptop computer, a tablet computer, a vehicle computer, a game console, a printer, a positioning device, a wearable electronic device, a smart sensor, a virtual reality (VR) device, an augmented reality (AR) device, or any other suitable electronic device having an electronic product therein. As shown in FIG1 , system 100 is a system in an electronic device, which may include a host 108 and a memory system 102, wherein the host 108 may include a processor, such as a central processing unit (CPU) or a system on a chip (SoC), wherein the system on a chip may be, for example, an application processor (AP). The host 108 also includes at least one operating system (OS) that can generally manage and control the functions and operations performed in the host 108. The OS can enable the host 108 coupled to the memory system 102 and a user who needs and uses the memory system 102 to operate mutually. The OS can support functions and operations corresponding to user requests. For example, and not limitation, depending on whether the host 108 is a mobile host, the OS can be categorized as a general-purpose operating system or a mobile operating system. General-purpose operating systems can include personal operating systems and enterprise operating systems. Personal operating systems can be operating systems such as Windows and Chrome that are generally used to support services; enterprise operating systems can be operating systems such as Windows Server, Linux, and Unix that are specifically designed to ensure and support high performance. Mobile operating systems can refer to operating systems that provide services or functions specific to mobility (such as power saving functions). Generally, mobile operating systems can include operating systems such as Android, iOS, and Windows Mobile. In some embodiments, the host 108 can include multiple OSs; accordingly, the host 108 can run multiple operating systems associated with the memory system 102. In other embodiments, the host 108 converts the user's request into one or more commands and transmits the one or more commands to the memory system 102, causing the memory system 102 to perform operations associated with the one or more commands.

[0067] The memory system 102 can operate or perform specific functions or perform various internal operations in response to a request from the host 108. In some embodiments, the memory system 102 can store data accessed by the host 108. The memory system 102 can be used as the primary storage or auxiliary storage of the host 108. The memory system 102 and the host 108 can be electrically connected and communicated according to corresponding protocols. The memory system 102 can be implemented and packaged into different types of terminal electronic products, such as, but not limited to: solid state drive (SSD), multimedia card (MMC), embedded MMC (eMMC), reduced size MMC (RSMMC), micro MMC, secure digital (SD) card, mini SD, micro SD, universal serial bus (USB) storage device, universal flash memory (UFS) device, compact flash (CF) card, smart media (SM) card and memory stick, etc.

[0068] In some embodiments, the memory system 102 may also be configured as part of, for example, a computer, an ultra-mobile PC (UMPC), a workstation, a netbook, a personal digital assistant (PDA), a portable computer, a web tablet, a tablet computer, a wireless phone, a mobile phone, a smart phone, an e-book, a portable multimedia player (PMP), a portable game console, a navigation system, a black box, a digital camera, a digital multimedia broadcasting (DMB) player, a three-dimensional (3D) television, a smart TV, a digital audio recorder, a digital audio player, a digital photo recorder, a digital photo player, a digital video recorder, a digital video player, a storage device configured in a data center, a device capable of transmitting and receiving information in a wireless environment, one of various electronic devices configured in a home network, one of various electronic devices configured in a computer network, one of various electronic devices configured in a telematics network, a radio frequency identification (RFID) device, or one of various components configured in a computing system.

[0069] Returning to FIG. 1 , the memory system 102 may include one or more memory devices 104 and a memory controller 106. The memory controller 106 may respond to requests from the host 108 and thereby control the memory devices 104. For example, the memory controller 106 may read data from the memory devices 104 and transmit the read data to the host 108. The memory controller 106 may also receive data to be stored from the host 108 and store the data to be stored in the memory devices 104. In other words, the memory controller 106 is capable of controlling write (or program) operations, read operations, erase operations, background operations, and the like of the memory devices 104.

[0070] Specifically, as shown in FIG2 , the memory controller 106 may include a front-end interface 201, a back-end interface 202, a processor 203, and a memory 204. The components 201, 202, 203, and 204 in the memory controller 106 may share transmission signals within the memory controller 106 via an internal bus. In some embodiments, the front-end interface 201 may interface the host 108 with the memory system 102 in response to a protocol of the host 108, and the front-end interface 201 may exchange transmission commands and data operations between the host 108 and the memory system 102. The front-end interface 201 may process commands and data sent by the host 108 and may include at least one of the following: a universal serial bus (USB), a multimedia card (MMC), a peripheral component interconnect express (PCI-e or PCIe), a small computer system interface (SCSI), serial SCSI (SAS), serial advanced technology attachment (SATA), parallel advanced technology attachment (PATA), a small computer system interface (SCSI), an enhanced small disk interface (ESDI), and integrated drive electronics (IDE). In some embodiments, the front-end interface 201 may be a component of the memory system 102 used to exchange data with the host 108 , and may be implemented by firmware called a host interface layer (HIL).

[0071] The backend interface 202 may be an interface for commands and data transmitted between the memory controller 106 and the memory device 104, allowing the memory controller 106 to control the memory device 104 in response to a request transmitted from the host 108. The backend interface 202 may generate control signals for controlling the memory device 104. In some embodiments, if the memory device 104 is a NAND flash memory, the backend interface 202 may write data to the memory device 104 or read data from the memory device 104 under the control of the processor 203. The backend interface 202 may process commands and data between the memory controller 106 and the memory device 104, for example, operations of a NAND flash memory interface, and in particular, operations between the memory controller 106 and the memory device 104. According to an embodiment, the backend interface 202 may be implemented as a component for exchanging data with the memory device 104 through firmware referred to as a flash interface layer (FIL).

[0072] The processor 203 may be implemented as a microprocessor or a central processing unit (CPU). The memory system 102 may include one or more processors 203. The processor 203 may control all operations of the memory system 102. By way of example and not limitation, the processor 203 may control programming operations or read operations of the memory device 104 in response to a write request or a read request from the host 108. According to an embodiment, the processor 203 may use or run firmware to control all operations of the memory system 102. In this disclosure, the firmware may be referred to as a Flash Translation Layer (FTL). The FTL may perform operations as an interface between the host 108 and the memory device 104. The host 108 may transmit requests related to write operations and read operations to the memory device 104 via the FTL. For example, when executing an operation requested by the host 108 in the memory device 104, the memory controller 106 uses the processor 203. The processor 203 coupled to the memory device 104 may process instructions or commands related to commands from the host 108. The memory controller 106 may perform foreground operations such as command operations corresponding to commands input from the host 108, for example, a program operation corresponding to a write command, a read operation corresponding to a read command, an erase / discard operation corresponding to an erase / discard command, and a parameter setting operation corresponding to a set parameter command or a set feature command having a set command.

[0073] For another example, the memory controller 106 may perform background operations on the memory device 104 via the processor 203. By way of example and not limitation, these background operations include garbage collection (GC) operations, wear leveling (WL) operations, map cleanup operations, and bad block management operations for checking or searching for bad blocks. The garbage collection operation may include an operation for copying and processing data stored in a memory block in the memory blocks MEMORY BLOCK <0, 1, 2, ...> of the memory device 104 (as shown in FIG. 3 ) to another memory block. The wear leveling operation may include an operation for exchanging and processing stored data between the memory blocks MEMORY BLOCK <0, 1, 2, ...> of the memory device 104. The map cleanup operation may include an operation for storing map data stored in the memory controller 106 in the memory blocks MEMORY BLOCK <0, 1, 2, ...> of the memory device 104. The bad block management operation may include an operation for checking and processing bad blocks in the memory blocks MEMORY BLOCK <0, 1, 2, ...> of the memory device 104. The memory controller 106 may respond to operations for accessing the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104, wherein the operations for accessing the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104 may include foreground operations or background operations performed on the memory blocks MEMORY BLOCK<0, 1, 2, ...> of the memory device 104.

[0074] The memory 204 may be a working memory of the memory controller 106 and is configured to store data for driving the memory controller 106. More specifically, when the memory controller 106 controls the memory device 104 in response to a request from the host 108, the memory 204 may store firmware driven by the processor 203 and data (e.g., metadata) required to drive the firmware.

[0075] The memory 204 may also be a buffer memory of the memory controller 106, configured to temporarily store write data transferred from the host 108 to the memory device 104 and read data transferred from the memory device 104 to the host 108. The memory 204 may include a program memory, a data memory, a write buffer / cache, a read buffer / cache, a data buffer / cache, and a mapping buffer / cache for storing write data and read data. The memory 204 may be implemented using a volatile memory. The memory 204 may be implemented using a static random access memory (SRAM), a dynamic random access memory (DRAM), or both.

[0076] 2 shows that memory 204 is included in memory controller 106, the present disclosure is not limited thereto. In an embodiment, memory 204 may be included outside memory controller 106, and memory controller 106 may input and output data to memory 204 through a separate memory interface (not shown).

[0077] It should be noted that although FIG2 shows that both the front-end interface 201 and the back-end interface 202 are included in the memory controller 106, the present disclosure is not limited thereto. In an embodiment, at least one of the front-end interface 201 and the back-end interface 202 may be included outside the memory controller 106. In other words, the structure of the memory controller 106 is not limited to the structure shown in FIG2 , and the components included therein may also be designed according to actual circumstances.

[0078] The memory device 104 may include a non-volatile memory device that can retain data stored therein even when power is not supplied. The memory device 104 can store data provided from the host 108 through a write operation; the memory device 104 can also provide the stored data to the host 108 through a read operation. In an embodiment of the present disclosure, the memory device 104 may also include any disclosed memory, such as a volatile memory device such as a dynamic random access memory (DRAM) and a static RAM (SRAM), and / or a non-volatile memory device such as a read-only memory (ROM), a mask ROM (MROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a ferroelectric RAM (FRAM), a phase change RAM (PRAM), a magnetoresistive RAM (MRAM), a resistive RAM (RRAM or ReRAM), and a flash memory (e.g., a three-dimensional NAND flash memory).

[0079] As shown in Figure 3, the memory device 104 may include multiple memory blocks MEMORY BLOCK<0, 1, 2, ...>. Each memory block may include multiple pages P<0, 1, 2, 3, 4, ...>. In addition, although not specifically shown in the drawings, each of the pages P<0, 1, 2, 3, 4, ...> may include multiple memory cells. Among them, according to the number of bits that can be stored or represented in a single memory cell, the memory cells are classified into any of different types of memory blocks such as single-level cell (SLC) memory blocks and multi-level cell (MLC) memory blocks. Here, the SLC memory block includes multiple pages implemented by each memory cell storing one bit of data. The SLC memory block can have higher data I / O operation performance and higher durability. The MLC memory block includes multiple pages implemented by each memory cell storing multi-bit data (for example, two or more bits). Compared with the SLC memory block, the MLC memory block can have a larger storage capacity for the same space. In terms of storage capacity, the MLC memory block can be highly integrated. In an embodiment, the memory device 104 may be implemented using MLC memory blocks such as MLC memory blocks, triple-level cell (TLC) memory blocks, quad-level cell (QLC) memory blocks, and combinations thereof. An MLC memory block may include multiple pages implemented by memory cells each capable of storing 2 bits of data. A triple-level cell (TLC) memory block may include multiple pages implemented by memory cells each capable of storing 3 bits of data. A quad-level cell (QLC) memory block may include multiple pages implemented by memory cells each capable of storing 4 bits of data. In other embodiments, the memory device 104 may include memory blocks composed of memory cells each capable of storing 5 or more bits of data.

[0080] In actual use, an electronic product with an integrated memory system 102 requires the coordination of its hardware and software systems to store or retrieve data. The hardware system of an electronic product can include the aforementioned memory system 102, including hardware such as a memory controller (including a processor, memory, front-end interface, and back-end interface), a memory device (such as the memory unit shown in FIG3 ), and other hardware. This hardware provides the material foundation and operating environment for data storage. Generally speaking, an electronic product without any software is called a bare metal device and cannot perform any function. It must be configured with necessary software to function. The collection of various software used by an electronic product is called a software system. Software refers to the sum of all programs and data used to operate, maintain, manage, and utilize the electronic product. Electronic product software can include system software and application software. System software primarily manages the electronic product, maintains the operation of the electronic product and certain functions, and performs services such as program translation and loading. It includes operating systems, programming language programs, and tool software (such as firmware). Application software can refer to programs written specifically to solve specific problems or designed for a specific user application. Here, firmware is a software program in an electronic product that can control specific hardware and provide necessary instructions. For example, the firmware of the FTL in the aforementioned memory system 102 enables the memory controller 106 to control certain operations of the memory system 102, such as logical-to-physical (L2P) mapping, wear leveling, garbage collection, and / or bad block disposal. Another example is the aforementioned HIL firmware, FIL firmware, etc. In some embodiments, this firmware is stored in the electronic product, more specifically, in the non-volatile storage medium of the memory device 104 of the memory system for subsequent use.

[0081] At present, with the development of electronic products integrated with memory systems, the types of electronic products are increasing; users have increasing demands for the functions and application scenarios of electronic products, resulting in an increasing number of central processing unit (CPU) cores integrated in the processors contained in electronic products, wherein the CPU core is the core chip in the middle of the CPU, which is the data processing core and the most important component of the CPU. The CPU core is configured to complete all calculations, receive / store commands, process data and other functions. The increase in the number of CPU cores can process the operation of more firmware in parallel, thereby realizing the increase in the functions and application scenarios of electronic products mentioned above. However, in this case, in the software development of electronic products, the number of codes contained in various firmware is also increasing. Moreover, in the development of a certain project of an electronic product (which can be a function or a software design for a specific scenario), an executable file (which can be presented as a binary BIN file) containing the data required by the firmware is often composed of different small files. In this case, when there are many small files, when the host computer (i.e., the host) downloads the above-mentioned executable files to the electronic product, the download program in the host needs to classify and process these small files. In addition, the excessive number of small files generated during the project development process (each small file may be designed by a different designer) can easily lead to version mismatch issues (the programming language or programming model used by the designers may be different). At the same time, during the project development process, the basic operating programs (the most basic programs required to start the electronic product and jump to the download processing program) and the download processing program in the electronic product may need to be synchronized and modified due to different versions. This can easily lead to synchronization issues and consume a lot of communication time. Currently, there are two solutions to solve the above problems. The first is to place most of the download processing of the executable file on the electronic product side, and the host side is only responsible for the transmission of the executable file through simple commands. This method requires the electronic product to process the executable file and generate the data required by the firmware (FW) in the electronic product. This requires the electronic product to process a large amount of data, resulting in low operating efficiency on the electronic product side and requiring a relatively complex download processing program. The second approach is to place the majority of the executable file download processing on the host side, leveraging the host's operational efficiency to improve download efficiency. In this scenario, since the one or more small files generated by the project are designed to run a certain function in the electronic product—in other words, the one or more small files designed are essentially the running programs in the electronic product to achieve a certain function—the processing operations required to generate the firmware required by the electronic product are determined by the firmware required by the electronic product. If the executable file download processing is placed on the host side, the development of the host's download program and the firmware of the electronic product are tightly coupled.

[0082] For the first solution mentioned above, the specific processing process is shown in Figure 4. It should be noted that CPU0 and CPU1 in Figure 4 are two CPUs in the host computer. Image0 to imagem for different CPUs are the small files included in the aforementioned executable file. Storage area 0 and storage area 1 are simply for convenience to represent two types of storage media (storage media in memory devices, such as NAND storage media, etc.). Specifically, storage area 0 represents a storage medium with address mapping. That is, the electronic product's download processing program must store the code to be stored in the corresponding storage unit based on the logical address of the code to be stored and the mapping relationship between the logical address and the physical address ((physical storage unit or) memory unit 0 to memory unit n)). Storage area 1 represents a storage medium without address mapping. That is, the electronic product's download processing program directly stores the code to be stored in the corresponding storage unit based on the physical address of the code to be stored. Storage area 0 and storage area 1 can be in the same storage medium or in different storage media. The number of storage units in each storage medium in Figure 4 is only an example and is not intended to limit the specific number.

[0083] Based on this, as shown in the download processing relationship in Figure 4, the host only plays a simple transmission role (for example, transmitting image x) to the electronic product, and most of the processing is done on the electronic product side (for example, the download processing program processes image x, generates the code to be stored, and specifies the storage address of the code to be stored). As mentioned above, the storage address can be a logical address or a physical address. The download processing program constructed according to the above download processing relationship reduces the operating efficiency of the electronic product. The code to be stored is related to the firmware required by the electronic product.

[0084] For the second solution, the specific process is shown in Figure 5. It should be noted that Figure 5 is essentially the same as Figure 4, except that the processing of each small file in Figure 5 is performed within the downloader shown in Figure 5. This way, most of the download processing occurs on the host side, creating a strong coupling between the host's downloader and the electronic product's firmware.

[0085] In order to solve the above technical problems, embodiments of the present disclosure provide a memory system that can support simultaneous upgrades of firmware with multiple functions and / or versions, and has good portability of download processing programs for upgrades of different types of memory systems.

[0086] Specifically, as shown in FIG6 , an embodiment of the present disclosure provides a memory system 600, which may include:

[0087] The communication interface 610 is configured to: receive an executable file in a set format; the executable file includes: a file header and multiple executable code segments; each of the multiple executable code segments includes code segment data and a code segment header; the code segment header is configured to indicate the storage location of the code segment data in the memory system 600.

[0088] It should be noted that the role of the communication interface 610 is also the aforementioned front-end interface 201. FIG2 shows that the front-end interface 201 is described inside the memory controller 106. The embodiment of the present disclosure describes the communication interface 610 outside the memory controller 620. This is only for the convenience of describing the division method used in the technical solution of the present disclosure. In fact, regardless of whether the front-end interface 201 described in FIG2 is in the memory controller 106, or the communication interface 610 described in the technical solution of the present disclosure is outside the memory controller 620, the type and function of the front-end interface 201 and the communication interface 610 are similar. In other words, the technical solution of the present disclosure is applicable to structures not limited to the description of the present disclosure. Electronic products or memory systems with similar functions and only different internal structure divisions are also applicable to the technical solution of the present disclosure.

[0089] Here, the setting format is related to the type of the communication interface 610. For example, if the communication interface 610 is an NVMe interface, the setting format may be a format for processing and encapsulating the data to be transmitted according to the vendor-specific command in the NVMe transmission protocol. For another example, if the communication interface 610 is a USB interface, the setting format may be a format for processing and encapsulating the data to be transmitted according to the USB protocol.

[0090] Here, the executable file may be a software program for upgrading the firmware of the memory system 600. As shown in FIG7 , the executable file 700 includes: a file header 720 and multiple executable code segments 710, each of which includes: code segment data 7101 and a code segment header 7102. The code segment data may include code for upgrading the firmware required for the memory system. For example, the firmware may include FTL firmware, system firmware, and the like. The function of the code segment header is to indicate the storage location of the corresponding code segment data in the memory system (specifically, the memory device). That is, the memory controller 620 can obtain the code segment header by parsing the executable file in a set format, and then store the corresponding code segment data in the corresponding location of the memory system 600 according to the storage location indicated by the code segment header. The executable file provided by the embodiment of the present disclosure can simplify the firmware upgrade of the memory system and support the simultaneous upgrade of multiple functions and / or versions of firmware.

[0091] In the memory system 600 provided by the embodiments of the present disclosure, the executable file received via the communication interface 610 includes multiple executable code segments, each of which includes code segment data and a code segment header, allowing for simultaneous upgrades of firmware stored in different locations. In some embodiments, the executable file may be a binary BIN format file, i.e., each executable code segment may also be a binary BIN format file.

[0092] In some embodiments, as shown in FIG8 , the code segment header 7102 may include at least: length information 801 of the code segment data and first indication information 802 of the storage location.

[0093] It should be noted that the length information here is configured to calculate the storage space required for the corresponding code segment data. In some embodiments, a bit is the smallest unit of storage information and can be referred to as a bit. Since the code segment data is a BIN format file, the storage space required for the code segment data can be calculated based on the length information of the code segment data (i.e., it contains multiple bits of data).

[0094] Here, the first indication information may include an address number of a storage area corresponding to the storage location; the storage area may include one or more minimum management units; and the minimum management unit may be a storage page or a data slice.

[0095] It should be noted that, since the first indication information indicates the storage location, it should include the address number of the storage area where the code segment data is to be stored. The storage space occupied by the code segment data calculated based on the length information of the aforementioned code segment data may require one or more minimum management units, so the first indication information should include the address numbers corresponding to one or more of the minimum management units. For example, if the storage space occupied by a certain code segment data contains one minimum management unit, the first indication information includes the address number of the minimum management unit. For another example, if the storage space occupied by a certain code segment data contains 3 minimum management units, the first indication information should include the address numbers of the 3 minimum management units. If these three minimum management units are consecutive, then one possible implementation method of the first indication information can be: address number A-address number C.

[0096] It should be noted that the address code may be a logical address or a physical address corresponding to the one or more minimum management units.

[0097] In some embodiments, if the flash translation layer FTL firmware can be run in the memory system, at this time, the host side can complete the translation of the logical address (LA, Logical Address) provided by the host (or user, Host) to the physical address (PA, Physical Address) of the memory unit of the memory device through the FTL, so as to write a user's logical data to the memory unit corresponding to the physical address of the memory device or read the data stored in the memory unit corresponding to the physical address of the memory device. That is, the host side accesses the physical address of the memory device through the logical address to write data to the memory device or read data from the memory device. Based on this, the address number described in the present disclosure may refer to a logical address. When the address number corresponds to a logical address, the storage area where the code segment data is to be stored corresponds to the memory unit in the storage area 0 in the aforementioned Figures 4 and 5.

[0098] In other embodiments, if the memory system does not have FTL firmware, the address encoding is a physical address. In this case, the host directly stores the code segment data in the storage area to be stored using the provided physical address. In this case, the storage area to be stored corresponds to the memory unit in the storage area 1 in Figure 4 and Figure 5.

[0099] Based on the above description, the non-volatile storage medium in the memory device can be divided into, but not limited to, storage pages or data partitions to form minimum management units.

[0100] Specifically, the storage page may refer to a logical page or a physical page, and the measurement of the storage space occupied by the aforementioned code segment data is calculated in terms of pages, that is, how many logical pages or physical pages are needed to store a code segment data. In some embodiments, if the electronic product can directly operate the memory device in the memory system it contains, the non-volatile storage medium contained in the memory device in the memory system can be divided into minimum management units according to storage pages. Such an electronic product may be a storage device such as the aforementioned SSD, UFS, etc. The storage area of ​​the memory device contained in such an electronic product can also be divided into two types: storage area 0 and storage area 1.

[0101] As for partition, it can be translated as data segmentation or data slicing. In a narrow sense, it can refer to the memory system, the process of dividing a large table into smaller slices, and the divided data blocks will be distributed among multiple servers. In a broad sense, data segmentation pages include data computing slicing, that is, routing requests to different servers for data processing. In the embodiment of the present disclosure, if the electronic product cannot directly operate the memory device of the memory system it contains, the non-volatile storage medium contained in the memory device in the memory system can be divided into the minimum management unit according to the partition. Such electronic products can be embedded electronic products such as mobile phones and tablets. The storage area of ​​the memory device contained in such an electronic product can also be divided into two types: storage area 0 and storage area 1.

[0102] To understand the above description, refer to Figures 9 to 11, wherein Figure 9 shows a flowchart of downloading and download processing of an executable file provided by an embodiment of the present disclosure; Figure 10 shows a flowchart of the interaction between the download program of the host and the download processing program of the electronic product when the electronic product provided by an embodiment of the present disclosure is capable of directly operating the memory system contained therein; and Figure 11 shows a flowchart of the interaction between the download program of the host and the download processing program of the electronic product when the electronic product provided by an embodiment of the present disclosure cannot directly operate the memory system contained therein.

[0103] Specifically, referring to the process shown in FIG9 , based on the technical problems existing in the related art, the embodiment of the present disclosure combines multiple small files through certain prescribed combinations to form an executable file as described in FIG6 through FIG8 . The executable file is then processed by a downloaded program to obtain each code segment contained in the executable file and the storage location corresponding to each code segment. The electronic product only needs to store the code segment data in the corresponding location according to the address number of the storage area corresponding to the transmitted storage location.

[0104] When electronic products store code segment data, the storage process may differ slightly depending on the type of electronic product, as shown in Figures 10 and 11.

[0105] The process shown in FIG10 is a schematic diagram of the code segment data storage process when an electronic product can directly access the memory device in its memory system. That is, the download processing program can directly store the code segment data to be stored based on the received address number. The electronic product shown in FIG10 can be, but is not limited to, a storage device such as an SSD or UFS.

[0106] The process shown in Figure 11 is a schematic diagram of the code segment data storage process when an electronic product cannot directly access the memory device within its memory system. Specifically, the download processing program cannot directly store the code segment data based on the received address code. Instead, it must be transferred through the firmware running in the memory system before the code segment data can be stored. The electronic product shown in Figure 11 can be, but is not limited to, embedded electronic products such as mobile phones and tablets.

[0107] It should be noted that, regardless of the electronic products shown in Figures 10 and 11 above, the code segment data to be stored has two storage methods: one is a storage method with address mapping (the corresponding memory system has FTL firmware); the other is a storage method without address mapping (the corresponding memory system has no FTL firmware).

[0108] It should be noted that regardless of how the non-volatile storage medium in the memory system is divided, the core concept of the embodiments of the present disclosure is how to download the firmware compiled in the host computer to the memory system and store it in the corresponding location. Therefore, the division of the non-volatile storage medium in the memory system is only described in the above two ways.

[0109] In some embodiments, as shown in FIG8 , the code segment header 7102 further includes an identifier 803 configured to indicate a specific usage of the code segment data.

[0110] It should be noted that the identifier may indicate a specific purpose or other description of the corresponding code segment data.

[0111] In one possible implementation mode, the identifier is an identifier for distinguishing different firmware slots.

[0112] That is, the identifier can be the number of a firmware slot to distinguish the code data segment from other code data segments belonging to different firmware slots. A storage device under the NVMe transmission protocol can support several different firmware versions, each of which corresponds to a firmware slot. In other words, the executable file contains multiple code segment data segments, i.e., multiple firmwares. These firmwares can belong to the same version or different versions.

[0113] That is, the firmware slots to which the code segment data in the multiple executable code segments belong include one of the following: completely identical, partially identical, and completely different.

[0114] That is, the memory system provided by the embodiment of the present disclosure can receive an executable file that can simultaneously upgrade firmware of multiple functions within the same version, or can simultaneously upgrade different functions in different versions, which is relatively flexible and simple.

[0115] It should be noted that the positional order of each piece of information (length information, first indication information, identifier, etc.) in the code segment header includes but is not limited to the structure shown in FIG8 . An exemplary structure that can be implemented is shown in FIG12 . The storage unit number in FIG12 is another way of expressing the address number included in the aforementioned first indication information; the current code segment length is the length information of the corresponding code segment data; and the usage identifier is a specific example of identifier 803 in FIG8 .

[0116] In some embodiments, as shown in FIG. 7 , the file header 720 includes at least verification information; the verification information is configured to verify whether the plurality of executable code segments are received or sent completely.

[0117] It should be noted that the verification information is configured to verify whether the multiple executable code segments in the executable file are transmitted or received completely. Specifically, the verification information is compared with verification data calculated based on the multiple executable code segments when the executable file is sent on the host side or received on the electronic product side to determine whether the multiple executable code segments are fully transmitted or received. In other words, the verification information can be calculated based on a verification algorithm when the executable file is generated on the host side, and the generated verification data is encapsulated in the file header to form verification information for subsequent verification. Subsequently, when the executable file is transmitted, whether the verification is performed by the host or the electronic product, the verification information in the file header is compared with the verification data calculated when the transmission is complete to determine whether the multiple executable code segments are fully transmitted. The verification methods used here include but are not limited to: hash check, redundancy cycle check (CRC), MD5 check, etc.

[0118] In some embodiments, the file header 720 further includes: second indication information; the second indication information is configured to indicate the firmware slot to which each executable code segment in the multiple executable code segments belongs.

[0119] It should be noted that the second indication information here may include the firmware slot number corresponding to each of the multiple executable code segments, thereby indicating the firmware slot to which the code segment data in the corresponding executable code belongs. This second indication information functions similarly to the aforementioned identifier for distinguishing firmware slots, except that the second indication information indicates the firmware slot to which each of the multiple executable code segments contained in the entire executable file belongs. The identifier for distinguishing firmware slots only indicates the firmware slot to which the corresponding code segment data belongs.

[0120] It should be noted that the file header 720 may also include version information of the executable file, and the version information is configured to check whether the version of each executable code segment in the multiple executable code segments matches the version between the download program on the host side or the download processing program on the electronic product side. In actual application, the file header 720 may include more content and can be designed according to actual conditions. The content contained in the file header may be different for different electronic products and different firmware upgrades. As for how to identify the content contained in the file header, it is usually necessary to agree on the number of bytes occupied by each content in the file header and the offset of each content in the file header, and then add the corresponding content in sequence, and then identify the corresponding content in sequence.

[0121] It should be noted that the above description only provides a detailed description of the content that an executable file can contain and the functions of each content. However, it should be understood that due to the differences in the design of the download program on the host side and the download processing program on the electronic product side, the content and format of the formatted executable file may not be exactly the same as the content and format of the aforementioned executable file 700 during the transmission process.

[0122] For example, if the download program on the host side generates an executable file 700 on the receiving program compilation platform, it processes the executable file 700 (for example, verifies and parses it) to obtain the multiple segments of executable code, and then encapsulates and transmits each segment of executable code in the format of the vendor-specific command of the NVMe transmission protocol. Then, the executable file received by the electronic product side only contains each segment of code segment data and a code segment header formed in the format of the vendor-specific command (different from the format in Figure 8 or Figure 12). Afterwards, the electronic product parses the received executable file according to the vendor-specific command of the NVMe transmission protocol, and stores each segment of code data in the storage location indicated by the code segment header. At this point, the complexity of the corresponding download processing program on the electronic product side is reduced, and the operating efficiency of the electronic product side is improved.

[0123] For example, if the host's download program receives the executable file 700 generated by the program compilation platform, it simply packages the executable file according to the corresponding transmission protocol and transmits it to the electronic product. In this case, the content and format of the executable file received by the electronic product are consistent with the content and format of the executable file generated by the host. In this case, the host's download program is simple, but the download processing program on the electronic product is more complex.

[0124] In some embodiments, the memory system 600 may further include: a memory controller 620, coupled to the communication interface, and configured to: cache the executable file transmitted from the communication interface; parse the executable file to obtain multiple code segment data contained in the executable file and a code segment header corresponding to each code segment data; and write the corresponding code segment data to the corresponding storage location according to each code segment header.

[0125] It should be noted that the description herein describes a series of operations performed by the memory system after receiving the executable file. Specifically, the memory controller 620 caches the executable file transmitted from the communication interface, then parses the executable file to obtain the multiple code segments contained in the executable file and the code segment header corresponding to each code segment; and then, based on each code segment header, writes the corresponding code segment data to the corresponding storage location.

[0126] The parsing method here is related to the communication interface type, the download program on the host side, and the download processing program on the electronic product side.

[0127] Specifically, as described above, if the download program on the host side processes the executable file (for example, verifies, parses) to obtain the multiple segments of executable code, at this time, the parsing on the electronic product side is only related to the type of communication interface. For example, if the communication interface is an NVMe type interface, the transmitted data packet needs to be encapsulated according to the NVMe transmission protocol. Then, the data packet encapsulated according to the NVMe transmission protocol received on the receiving side (that is, the memory system side) needs to be decapsulated accordingly according to the NVMe transmission protocol to obtain the corresponding required data, that is: the executable file with a set format needs to be decapsulated accordingly according to the NVMe transmission protocol to obtain multiple segments of code segment data and the code segment header corresponding to each code segment data. For another example, if the communication interface 610 is a USB-type interface, the transmitted data packets must be encapsulated according to the USB transmission protocol. Then, when the receiving side (i.e., the memory system side) receives the data packets encapsulated according to the USB transmission protocol, it must be decapsulated according to the USB transmission protocol to obtain the corresponding required data. In this case, the executable file of the set format must be decapsulated according to the USB transmission protocol to obtain multiple code segment data and the code segment header corresponding to each code segment data. If the download program on the host side only packages the executable file, the parsing process on the electronic product side must first decapsulate according to the transmission protocol supported by the communication interface 610 to obtain the executable file. After that, the executable file must be processed (e.g., verified, parsed) to obtain the multiple executable code segments and the code segment header corresponding to each code segment data.

[0128] After obtaining the multiple code segment data and the code segment header corresponding to each code segment data, the memory controller may store each code segment data in the multiple code segment data according to the storage location indicated by the corresponding code segment header.

[0129] More specifically, in some embodiments, the memory system 600 may further include: a storage interface 630 and one or more memory devices 640; wherein,

[0130] The memory controller is coupled to the storage interface and is further configured to: generate one or more write commands according to each piece of the code segment data and the corresponding code segment header; and send the one or more write commands to the memory device through the storage interface;

[0131] The one or more memory devices are coupled to the storage interface and are configured to: receive the one or more write commands through the storage interface; and in response to the one or more write commands, write each code segment data to a storage location indicated by a code segment header corresponding to a non-volatile storage medium in the memory device.

[0132] It should be noted that the above process is the programming process on the electronic product side, that is, the process of writing data to the memory device. Specifically, the memory controller generates one or more write commands based on each piece of code segment data and the corresponding code segment header, and then sends the one or more write commands to the memory device through the storage interface 630. The memory device receives the one or more write commands through the storage interface 630 and, in response to the one or more write commands, writes each piece of code segment data to the storage location indicated by the corresponding code segment header on the non-volatile storage medium of the memory device.

[0133] Here, the writing mentioned is the programming operation of the memory device. In some embodiments, the programming strategy of the programming operation includes but is not limited to step pulse programming (ISPP). The role of the storage interface 630 is also the aforementioned back-end interface 202. Figure 2 shows that the back-end interface is inside the memory controller 106. The embodiment of the present disclosure describes the storage interface 630 outside the memory controller 620. This is only for the convenience of describing the division method adopted in the technical solution of the present disclosure. In fact, whether the back-end interface 202 described in Figure 2 is inside the memory controller 620, or the storage interface 630 described in the technical solution of the present disclosure is outside the memory controller 106, the type and function of the back-end interface 202 and the storage interface 630 are similar. In other words, the structure not limited to the description of the present disclosure is applicable to the technical solution of the present disclosure. The functions of electronic products or memory systems are similar and only the internal structure division is different. The technical solution of the present disclosure is also applicable.

[0134] In some embodiments, the memory device 640 includes 3D NAND storage media.

[0135] In some embodiments, the memory system is contained in a memory card or an SSD.

[0136] Specifically, as shown in Figures 13 and 14, Figure 13 shows a schematic structural diagram of a memory card provided by an embodiment of the present disclosure; Figure 14 shows a schematic structural diagram of an SSD provided by an embodiment of the present disclosure.

[0137] In FIG13 , the memory controller 620 and the single memory device 640 may be integrated into a memory card 1302. The memory card may include a PC card (PCMCIA, Personal Computer Memory Card International Association), a CF card, a Smart Media (SM) card, a memory stick, a multimedia card (MMC, RS-MMC, MMCmicro), an SD card (SD, miniSD, microSD, SDHC), a UFS, etc. The memory card may further include a memory card connector 1304 for coupling the memory card to a host (e.g., the host 108 in FIG1 ).

[0138] In FIG14 , the memory controller 620 and the plurality of memory devices 640 may be integrated into an SSD 1402. The SSD may further include an SSD connector 904 for coupling the SSD to a host (e.g., host 108 in FIG1 ). In some embodiments, the storage capacity and / or operating speed of the SSD is greater than the storage capacity and / or operating speed of a memory card. The SSD may further include an SSD connector 1404 for coupling the SSD to a host (e.g., host 108 in FIG1 ).

[0139] The memory system provided by the embodiments of the present disclosure receives an executable file in a predetermined format via a communication interface. The executable file includes multiple executable code segments, each of which contains code segment data and a code segment header. Each code segment corresponds to a firmware file or a portion of a firmware file. This allows for simultaneous upgrades of multiple firmware files by adding multiple code segments to the same executable file. Furthermore, a host-side download program can be designed to process the executable file, transmitting only the code segment data from the multiple executable code segments to the electronic product, thereby improving the operating efficiency of the electronic product.

[0140] An embodiment of the present disclosure further provides a method for operating a memory system. Specifically, as shown in FIG15 , the operating method may include:

[0141] S1501: Receive an executable file in a set format through the communication interface of the memory system; wherein the executable file includes: a file header and multiple executable code segments; each of the multiple executable code segments includes code segment data and a code segment header; the code segment header is configured to indicate the storage location of the code segment data in the memory system

[0142] S1502: Run a first processing program; wherein, when the first processing program is run, the following steps are performed: parsing the executable file to obtain multiple code segment data contained in the executable file and a code segment header corresponding to each code segment data; writing the corresponding code segment data to the corresponding storage location according to each code segment header.

[0143] It should be noted that the first processing program may refer to the aforementioned download processing program on the electronic product side. That is, it is a processing program that processes the received executable file and stores the multiple code segment data contained in the executable file in corresponding storage locations. The first processing program here may be executed in the memory controller 620, that is, the memory controller 620 stores each of the multiple code segment data in a corresponding storage location through the first processing program.

[0144] Here, the memory system's reception of the executable file may be included in the first processing program or not. In the former case, the electronic product may enter an upgrade mode through certain settings. At this time, the executable file is received only when the first processing program is running. In the latter case, the executable file may be received normally when the electronic product is operating normally, and the executable file is processed only when the first processing program is running. The present disclosure does not limit the timing of receiving the executable file and running the first processing program. The two can run according to the former case or the latter case, depending on the designer's choice.

[0145] In an optional manner, an executable file in a set format is received through the communication interface of the memory system; thereafter, when the first processing program is executed, the following operations may be performed: parsing the executable file to obtain multiple code segment data segments contained in the executable file and a code segment header corresponding to each code segment data segment; and writing the corresponding code segment data to the corresponding storage location according to each code segment header. In addition, while instructing the communication interface to receive the executable file in the set format, the memory in the memory controller is instructed to cache the executable file until the executable file is fully received.

[0146] In some embodiments, the operating method further includes:

[0147] In response to a startup enable signal, the memory system is started; a second processing program is loaded and run, wherein when the second processing program is run, at least the following steps are performed: loading the first processing program and running the first processing program.

[0148] It should be noted that the second processing program here can be the most basic operating program of the memory system, which may include a startup program, an initialization program, etc. The startup enable signal here can refer to a power supply signal, that is, to power on the memory system. The process described here is: after the electronic product is powered on, the second processing program (basic operations such as the startup program and initialization program) is loaded and run. When the second processing program is running, at least the following steps are performed: loading the first processing program, that is, loading the download processing program into the memory of the memory controller for subsequent use.

[0149] It should be noted that, according to the above description, the second processing program can also execute the program to start the communication interface to receive the executable file. The steps executed by the two processing programs in the above operation method have been described in detail in the above memory system, which can be understood by reference and will not be repeated here.

[0150] An embodiment of the present disclosure further provides a system, which may include:

[0151] The memory system according to any one of the preceding claims;

[0152] and a host coupled to the memory system and configured to control the memory system.

[0153] In some embodiments, the memory system is configured to:

[0154] Run the first processing program; wherein, when the first processing program is run, the following steps are performed:

[0155] Parsing the executable file to obtain multiple code segment data and a code segment header corresponding to each code segment data segment included in the executable file;

[0156] According to each code segment header, the corresponding code segment data is written into the corresponding storage location.

[0157] In some embodiments, the memory system is further configured to: start the memory system in response to a start enable signal; load and run a second processing program, wherein when the second processing program is running, at least the following steps are performed: load the first processing program and run the first processing program.

[0158] It should be noted that the system herein may be included in the aforementioned electronic product, and its structure can be seen in the system block diagram shown in FIG1 . Only the structure related to the technical solution of the present disclosure is described here, and the remaining structures can be understood by referring to the above. The configuration of the memory system is the same as the description of the aforementioned memory system operation method at different levels. For the steps involved, reference can be made to the aforementioned memory system operation method, and no further description will be given here.

[0159] In some embodiments, the host is configured to: generate the executable file;

[0160] Converting the executable file to form an executable file in the set format;

[0161] The executable file in the set format is sent to the memory system.

[0162] Among them, generating the executable file may include: combining multiple code segment data and the code segment header corresponding to each code segment data in a set order to generate multiple executable codes; generating a file header; and generating the executable file based on the multiple executable codes and the file header.

[0163] It should be noted that what is described here are some processes on the host side. Among them, the combination of multiple code segment data and the code segment header corresponding to each code segment data in a set order to generate multiple executable codes can be that the program compilation platform contained in the host simply combines multiple small files (that is, multiple code segment data) generated in a project development and the code segment headers corresponding to these small files in a set order to form the executable file, wherein the set order is related to the writing order of the electronic product. For example, if the writing order of the electronic product is sequential writing, the set order can be combined in the order from small to large according to the address code of the storage location of each code segment data. For another example, if the writing order of the electronic product is random writing, the set order can combine the code segment data in any order. The conversion process of the executable file mentioned here to form the executable file of the set format can refer to the processing process of the download program on the host side, that is, it can include but is not limited to: after the download program on the host side receives the executable file 700 formed by the compilation platform, it processes the executable file 700 (for example, verifies, parses) to obtain the multiple segments of executable code, and then encapsulates and transmits each segment of executable code according to the format of the vendor-specific command of the NVMe transmission protocol. Then, the executable file received by the electronic product side only contains each segment of code segment data and the code segment header formed according to the format in the vendor-specific command (different from the format in Figure 8 or Figure 12). Afterwards, the electronic product parses the received executable file according to the vendor-specific command of the NVMe transmission protocol and stores the data of each code segment in the storage location indicated by the code segment header. At this time, the complexity of the download processing program corresponding to the electronic product side is reduced, and the operating efficiency of the electronic product side is improved.

[0164] Embodiments of the present disclosure further provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the aforementioned methods. The aforementioned storage medium includes any medium capable of storing program code, such as a mobile storage device, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0165] In order to understand the technical solutions provided by the embodiments of the present disclosure, an exemplary description is given below with reference to the system shown in FIG16 .

[0166] In FIG16 , system 1600 includes: a host 1610 and a memory system 1620, wherein: the host 1610 includes: a program compilation platform 1601 and a download module (including a download program) 1602; the memory system 1620 includes: a communication interface 610 (connection arrow between the download module 1602 and the download processing program 1603), a memory controller 620, a storage interface 630 (connection arrow between the download processing module 1603 and the storage unit), and a memory device 640, wherein the memory controller 620 includes a download processing module (including a download processing program) 1603; the memory device 640 includes multiple memory units, which are volatile storage media and are divided into multiple minimum management units, each of which corresponds to an address number. It should be noted that the memory system 1620 shown in FIG16 is included in an electronic product that can directly operate the memory device, such as an SSD, UFS, or other storage device.

[0167] Under the structure of FIG. 16 above, as shown in FIG. 17 , the steps performed on the host side may include:

[0168] S1701: The program compilation platform 1601 combines multiple code segment data generated during the development of a project in a set order to form an executable file; the executable file includes: multiple executable code segments and a file header; each executable code segment in the multiple executable code segments includes code segment data and a code segment header; the code segment header is configured to indicate the storage location of the code segment data in the memory system.

[0169] S1702: The program compilation platform 1601 transmits the executable file to the download module 1602;

[0170] S1703: The download module 1602 receives the executable file; verifies and parses the executable file to obtain multiple code segments and a code segment header corresponding to each code segment; and transmits the corresponding code segment data to a storage unit of a memory device in the electronic product according to a set transmission protocol based on the first indication information in each code segment header.

[0171] It should be noted that the setting transmission protocol mentioned here may include but is not limited to the aforementioned NVMe transmission protocol or USB transmission protocol. The processing of the download module in step S1703 is only an example as described above.

[0172] The above steps can be understood as follows: the downloader runs as a host computer program on the host side. The executable file header primarily serves as a logical reference for the downloader: the downloader references the verification information contained in the file header and compares it with the hash (or similar file verification method, including but not limited to MD5) verification data calculated by the downloader itself for the multiple executable code segments contained in the executable file to verify the correctness (or integrity) of the multiple executable code segments in the executable file. The verification information in the file header is generated by the program compilation platform when generating the executable file, using the hash (or similar file verification method, including but not limited to MD5) to verify the multiple executable code segments contained in the executable file. Here, the downloader can also use supplementary information such as the firmware slot in the file header (i.e., the aforementioned second indication information) to facilitate the subsequent placement of each code segment data in the correct firmware slot order. The downloader can also verify that the firmware and downloader versions match based on the version information in the file header. This varies depending on the product and firmware implementation, but typically a fixed byte range is agreed upon, or the number of bytes occupied by the header information is specified at a specific location. The downloader then transmits the final code segment data to the device using a storage protocol such as NVMe's vendor-specific command (which varies depending on the bus used, but can also be a common USB packet format) for use by the downloader running on the device.

[0173] Under the structure of FIG. 16 , as shown in FIG. 18 , the steps performed on the electronic product side may include:

[0174] S1801: The download processing module 1603 receives and caches the multiple code data segments (i.e., executable files in a set format) transmitted according to a set transmission protocol through the communication interface 610; and writes the multiple code data segments into corresponding storage locations in the memory device.

[0175] In actual implementation, the execution flow on the electronic product side can be understood as follows: the download handler runs on the device. The specific processing steps on the device include: after the device is powered on and booted from ROM, the basic program running on the device (such as the initialization program) loads the download handler to a specific device execution address, jumps from ROM, and runs the download handler. The download handler primarily receives each code segment data using methods such as NVMe vendor-specific commands (which vary depending on the bus used for transmission, but can also be common methods such as USB packets) and saves it to the electronic product's persistent storage media (non-volatile storage media) such as NAND pages and partitions.

[0176] In the current firmware upgrade mode, the logic of the download processing program of electronic products becomes simple and universal. It is only necessary to modify the corresponding front-end bus interface and back-end storage operation interface for different devices, and the intermediate logic processing changes and modifications are small.

[0177] The embodiment of the present disclosure provides a firmware upgrade method: on the host side, after the program compilation platform generates multiple segments of firmware code (binary code segment data) required for the operation of each CPU contained in the electronic product, the multiple segments of firmware code are combined to form a final binary file (also known as an executable file) of the electronic product. The final binary file includes a file header and multiple segments of executable code. During the firmware upgrade, the download program on the host side performs a hash check (or CRC, etc.) on the multiple segments of executable code based on the checksum information contained in the file header of the final binary file, and compares the checksum information in the file header with the calculated checksum data to ensure the data integrity of the overall code data and code segment description information. In addition, the file header can also optionally inform the download program of the number of firmware slots owned by the current file and the number of firmware slots actually provided by the electronic product based on the application scenario of the product, such as the multiple firmware slot characteristics of the NVME device. At the same time, the minimum number of management units to be written can be informed based on the different storage media in the memory devices of different electronic products, such as using a page size in NAND as the minimum management unit, or using the number of partitions that the storage medium can be divided into as the minimum management unit. The content in the file header can also optionally inform the downloader which part of the code segment will be updated separately during the download process according to the characteristics of the electronic product monomer or other requirements based on the provided binary file. The downloader also informs the downloader of the address number of one or more minimum management units corresponding to the non-volatile storage medium of the electronic product through the content (length information, first indication information, identifier) ​​in each code segment header, and informs the downloader of the length of the current code segment. The downloader only needs to complete the data write operation based on the identifier of the header, and synchronizes with the end of the current code segment through the relationship between the final binary file size and the end of the current code segment, or through the optional number of minimum management units of the header. The present disclosure provides an embodiment because the downloader and the final binary file are both based on the minimum management unit. In the download processing program of the electronic product, it is only necessary to complete the basic initialization of the system, provide the minimum management unit interface function, link mode driver, and a small number of other tasks that need to be implemented, thereby simplifying the development of the download processing program. And because there is no limit on the number of code segment data, it is more suitable for the needs of different projects.

[0178] The present disclosure provides a widely applicable file format that adds basic information to the final binary file (also known as the executable file), such as adding special identifiers such as the storage unit number, the current code segment length, and the purpose identifier, such as the label of the firewall slot, to the header of each binary segment or other agreed locations; this file format has no restrictions on the length of the final binary file. The advantages are: simplifying the download process and the process of downloading the processing program on the storage device side, improving development efficiency, and reducing communication costs during development; allowing the download program to complete the data writing operation based on the identifier in the header, and synchronize through the relationship between the file size and the end of the current code segment, or through the minimum number of optional code management units in the header. Different firewall slots can be distinguished to meet the different needs of products. There is no size limit on the length of the final binary file, and it can be applied to more scenarios when the format is consistent, while facilitating product and developer code addition and deletion.

[0179] It should be noted that in the several embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0180] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0181] In addition, all functional units in the embodiments of the present disclosure may be integrated into one processing unit, or each unit may be separately used as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0182] Those skilled in the art will appreciate that all or part of the steps of the above-mentioned method embodiments may be implemented by hardware associated with program instructions, and the aforementioned program may be stored in a computer-readable storage medium. When the program is executed, the program executes the steps of the above-mentioned method embodiments. The aforementioned storage medium includes various media that can store program codes, such as mobile storage devices, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0183] Alternatively, if the above-mentioned integrated unit of the present disclosure is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present disclosure is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0184] The above description is intended to be illustrative, and not restrictive.

Claims

1. A memory system, comprising: The communication interface is configured to: receive an executable file in a set format; The executable file includes: a file header and multiple executable code segments; each of the multiple executable code segments includes code segment data and a code segment header; the code segment header is configured to indicate a storage location of the code segment data in the memory system.

2. The memory system according to claim 1, wherein: The code segment header includes at least: length information of the code segment data and first indication information of the storage location.

3. The memory system according to claim 2, wherein: The code segment header also includes an identifier configured to indicate a specific usage of the code segment data.

4. The memory system according to claim 2, wherein: The first indication information includes an address number of a storage area corresponding to the storage location; the storage area includes one or more minimum management units; the minimum management unit is a storage page or a data slice.

5. The memory system according to claim 3, wherein: The identifier is an identifier for distinguishing different firmware slots.

6. The memory system according to claim 1, wherein: The file header at least includes: verification information; the verification information is configured to verify whether the multiple executable code segments are received or sent completely.

7. The memory system according to claim 6, wherein: The file header also includes: second indication information; the second indication information is configured to indicate the firmware slot to which each executable code segment among the multiple executable code segments belongs.

8. The memory system according to claim 5 or 7, wherein: The firmware slot to which the code segment data in the multiple executable code segments belong includes one of the following: completely identical, partially identical, and completely different.

9. The memory system according to claim 1, wherein: The executable file is a binary BIN format file.

10. The memory system according to claim 1, wherein: The memory system also includes: a memory controller coupled to the communication interface and configured to: cache the executable file transmitted from the communication interface; parse the executable file to obtain multiple code segment data contained in the executable file and a code segment header corresponding to each code segment data; and write the corresponding code segment data to the corresponding storage location according to each code segment header.

11. The memory system according to claim 10, wherein: The memory system further comprises: a storage interface and one or more memory devices; wherein, The memory controller is coupled to the storage interface and is further configured to: generate one or more write commands according to each of the code segment data and the corresponding code segment header; and send the one or more write commands to the memory device through the storage interface; The one or more memory devices are coupled to the storage interface and are configured to: receive the one or more write commands through the storage interface; and in response to the one or more write commands, write each code segment data to a storage location indicated by a code segment header corresponding to a non-volatile storage medium in the memory device.

12. The memory system according to claim 11, wherein: The memory device includes a 3D NAND storage medium.

13. The memory system according to claim 1, wherein: The memory system is contained in a memory card or an SSD.

14. A method for operating a memory system, the method comprising: Receiving an executable file of a set format through the communication interface of the memory system; wherein the executable file comprises: a file header and multiple executable code segments; each of the multiple executable code segments comprises code segment data and a code segment header; the code segment header is configured to indicate a storage location of the code segment data in the memory system; Run the first processing program; wherein the first processing program performs the following steps when it is run: Parse the executable file to obtain multiple code segment data and The code segment header corresponding to each code segment data; According to each code segment header, the corresponding code segment data is written into the corresponding storage location.

15. The operating method according to claim 14, wherein: The operation method further includes: In response to a startup enable signal, the memory system is started; a second processing program is loaded and executed, wherein when the second processing program is executed, at least the following steps are executed: the first processing program is loaded and the first processing program is executed.

16. A computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the method according to any one of claims 14 to 15 when executed by a processor.

17. A system comprising: The memory system according to any one of claims 1 to 13; and a host coupled to the memory system and configured to control the memory system.

18. The system of claim 17, wherein: The memory system is configured as follows: Run the first processing program; wherein the first processing program performs the following steps when it is run: Parsing the executable file to obtain multiple code segment data contained in the executable file and a code segment header corresponding to each code segment data; According to each code segment header, the corresponding code segment data is written into the corresponding storage location.

19. The system of claim 18, wherein: The memory system is further configured to: start the memory system in response to a start enable signal; load and run a second processing program, wherein when the second processing program is running, at least the following steps are performed: load the first processing program and run the first processing program.

20. A system according to any one of claims 17 to 19, wherein: The host is configured to: generate the executable file; Converting the executable file to form an executable file in the set format; The formatted executable file is sent to the memory system.

Images