US20160011884A1 - Communicating With An Update Logic Image - Google Patents
Communicating With An Update Logic Image Download PDFInfo
- Publication number
- US20160011884A1 US20160011884A1 US14/859,350 US201514859350A US2016011884A1 US 20160011884 A1 US20160011884 A1 US 20160011884A1 US 201514859350 A US201514859350 A US 201514859350A US 2016011884 A1 US2016011884 A1 US 2016011884A1
- Authority
- US
- United States
- Prior art keywords
- image
- memory
- memory medium
- computer system
- recorded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
- G06F9/4408—Boot device selection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
- G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
- G06F12/0638—Combination of memories, e.g. ROM and RAM such as to permit replacement or supplementing of words in one module by words in another module
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/20—Employing a main memory using a specific memory technology
- G06F2212/205—Hybrid memory, e.g. using both volatile and non-volatile memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/72—Details relating to flash memory management
- G06F2212/7201—Logical to physical mapping or translation of blocks or pages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
Definitions
- the invention relates to selectively updating flash memory, such as portions of code resident in flash memory for use in embedded devices.
- a typical configuration in many embedded devices is to store and run the operating system from the flash memory (or ROM), and store required data in a non-volatile RAM.
- flash memory or ROM
- pervasive embedded devices have a full-fledged operating system, one or more file-systems, along with a bootloader and other data components, resident in flash memory.
- flash memory storage The life of flash memory storage is largely dictated by the number of accesses that occur to flash memory when updating flash memory. Any writes to a flash location are preceded by a corresponding erase. Erasing flash memory is a slow and time consuming process.
- a memory medium for selectively updating, with corresponding replacement images, any combination of images of a plurality of binary images recorded on the memory medium having a plurality of contiguous memory sectors that are erased before being rewritten.
- the memory medium includes one or more binary images recorded on the memory medium.
- the memory medium also includes an update logic image recorded on the memory medium.
- the update logic image includes instructions for execution by a computer system. The instructions, when executed by the computer system, cause the computer system to implement a method. The method includes determining whether an updating operation is to be performed, determining memory addresses of the memory medium at which a corresponding replacement image can be recorded, erasing the determined memory addresses, and writing the corresponding replacement image to the determined memory addresses of the memory medium.
- the one or more binary images include at least one kernel image, at least one file-system image, a boot-loader image, and a scratch area image.
- the boot-loader image and the update logic image are recorded at different ends of a first predetermined portion of the memory medium at the start of the memory medium.
- the scratch area image is recorded directly following the predetermined portion of the memory medium.
- the kernel image and the file system image are recorded at different ends of a second predetermined portion of the memory medium, following the scratch area image.
- a memory medium for selectively updating, with corresponding replacement images, any combination of images of a plurality of binary images recorded on the memory medium having a plurality of contiguous memory sectors that are erased before being rewritten.
- the memory medium includes one or more binary images recorded on the memory medium.
- the memory medium also includes an update logic image recorded on the memory medium.
- the update logic image includes instructions for execution by a computer system.
- the instructions when executed by the computer system, cause the computer system to implement a method that includes determining whether an updating operation is to be performed, determining memory addresses of the memory medium at which a corresponding replacement image can be recorded, erasing the determined memory addresses, writing the corresponding replacement image to the determined memory addresses of the memory medium, and determining whether the size of the replacement image is less than or equal to the size of the selected image. If the size of the replacement image is not less than or equal to the size of the selected image, the method includes determining whether the replacement image can be accommodated by free capacity in the memory medium, determining whether the replacement image can be accommodated by memory addresses of the selected image and any free memory addresses that directly follow the selected image.
- a memory medium for selectively updating, with corresponding replacement images, any combination of images of a plurality of binary images recorded on the memory medium having a plurality of contiguous memory sectors that are erased before being rewritten.
- the memory medium includes one or more binary images recorded on the memory medium.
- the one or more binary images include at least one kernel image, at least one file-system image, a boot-loader image, and a scratch area image.
- the memory medium also includes an update logic image recorded on the memory medium.
- the update logic image includes instructions for execution by a computer system, wherein the instructions, when executed by the computer system, cause the computer system to implement a method.
- the method includes determining whether an updating operation is to be performed, determining memory addresses of the memory medium at which a corresponding replacement image can be recorded, erasing the determined memory addresses, writing the corresponding replacement image to the determined memory addresses of the memory medium, erasing the scratch area image recorded on the memory medium, and writing a replacement scratch area image to replace the scratch area image, after the writing of the replacement image.
- the replacement scratch area image reflects the replacement of the selected image with the replacement image, and the writing of the replacement scratch area image is performed after the selected image is replaced with the corresponding selected image.
- FIG. 1 is a schematic representation of the contents of a flash memory device.
- FIG. 2 is a schematic representation of the communication that occurs between update logic stored in the flash memory of FIG. 1 , and a host program in a host machine operatively connected with the flash memory of FIG. 1 .
- FIG. 3 is an alternative schematic representation of the contents of the flash memory of FIG. 1 , in which multiple file systems are resident.
- FIG. 4 is a schematic representation of the contents of a scratch area of the flash memory of FIG. 3 .
- FIG. 5 is a schematic representation of the sequence of communications between the host program and the update logic of FIG. 2 when the scratch area of FIG. 4 is updated.
- FIGS. 6A and 6B jointly represent a flowchart of the steps that occur when the contents of a flash memory is updated.
- FIG. 7 is a schematic representation of a host machine computer system which executes the host program of FIG. 2 .
- a flash memory such as in an embedded device
- the described technique allows for selective updates of parts of embedded flash memory, which provides advantages in increasing the speed of embedded software development while minimising the number of erases and writes to the flash memory.
- flash memory is used herein to describe a type of non-volatile memory in which is an electrically erasable and programmable read-only memory (EEPROM) having a programmable operation which allows for the erasure of blocks of memory.
- EEPROM electrically erasable and programmable read-only memory
- any reference to a “flash memory” is taken to include any non-volatile storage memory in which (i) data can be written only in unwritten or erased physical memory locations and in which (ii) a zone of contiguous physical memory locations are simultaneously erased.
- flash memory having such characteristics is referred to as “flash memory”.
- a host machine contains the images that are to be updated in the flash memory. For the purposes of the following description, it is assumed that the host machine is to be connected to the embedded device through a serial line. Of course, this general approach is also valid for a network connection, though the initial handshake process will be different.
- the embedded device with which the technique is used preferably has a mechanism for determining when to initiate an update. This may be, for example, a jumper setting in the device, or some signal or other indication provided by the host machine etc.
- the boot-loader gets control of the device. If the boot-loader detects that an update indication (such as a software flag, or some form of hardware indication) is ON, the boot-loader copies the update logic to RAM and branches to the update logic. This procedure is needed as most flash memory chips do not support simultaneous writes and reads—which is required if the update logic writes to the flash memory, while also executing from the flash memory. If the boot-loader senses that the update indication is OFF, the boot-loader boots the system. The kernel flash-disk block driver subsequently mounts a file-system resident in flash memory of the embedded device as the root device.
- an update indication such as a software flag, or some form of hardware indication
- Flash memory is normally organized into banks and further into sectors. Erases can be done only at the granularity of a sector. A flash-write has to follow an erase on the corresponding sector.
- FIG. 1 schematically represents a flash memory 100 used in connection with the techniques described.
- the flash memory 100 comprises N banks 112 , 114 , 116 .
- the boot loader 120 At the start of the flash memory 100 there is a boot loader 120 , followed by the update logic image 130 .
- a scratch area 140 contains the start addresses and sizes of all the flash-resident images (as explained below in further detail, with reference to FIG. 4 ).
- the scratch area 140 is used by the boot-loader 120 to boot the device.
- the scratch area 140 is also used by the kernel flash-disk block driver to determine where the file-system 150 starts.
- the update logic 130 software also needs to use the contents of the scratch area 140 to perform selective updates. From a programming perspective, it is faster (though not necessary) if the scratch area 140 resides in a separate sector from the update logic 130 and the file system 150 . If the scratch area 140 is resident in a partly used sector, the remaining contents have to be buffered while re-programming the scratch area 140 .
- the kernel flash-disk driver emulates a disk in flash memory 100 , so that one or more file-systems can be resident on the flash memory 100 .
- FIG. 2 represents the start protocol, between the host resident program 210 executing on the host machine, and the update logic 130 executing on the flash memory 100 of the embedded device.
- the update logic 130 now knows the serial port to which all reads and writes are to be directed. Now the update logic 130 sends the serial port number (that is, PORT — NUMBER 250 ) back to the host machine (through the serial port that it just detected), completing the three-way handshake. The host resident program 210 subsequently sends commands to the update logic 130 to configure the serial port that it thus detected, and to immediately switch the serial port to the same configuration.
- the serial port number that is, PORT — NUMBER 250
- the start protocol also enables the implementation of a multi-functional program 210 on the host machine.
- certain processor chips used in embedded devices have two boot-modes: (i) a first boot-mode that is used to load the boot-loader 120 and the other images for the first time (code-load), and (ii) a second boot-mode that boots from the top of the flash memory 100 .
- a boot-loader is expected to be resident at the top of the flash memory 100 .
- An example of such a processor chip is the EP7211 produced by Cirrus Logic of Austin, Tex.
- different memory addresses obtain control. The software resident at these different memory addresses emits different start characters. By using different start characters for these different modes, the host resident program 210 executing on the host machine determines the boot mode that is active.
- the start address for the kernel in flash memory 100 is computed as follows. The highest possible word-aligned address that accommodates the kernel in flash memory 100 is obtained. For this, one calculates backwards from the end address of the last flash memory bank 116 . The word-size depends on the flash chip-set used. Certain flash memory chip-sets support “page-write” commands. If the flash memory writes are done using this “page-write” mode, the computed address is the highest possible ‘page-aligned’ address.
- the start address for the file-system image 150 is the first word-aligned (or, “page-aligned”, as noted above) address following the scratch area 140 .
- the kernel 170 and the file-system 150 reside at different ends of the flash memory 100 . This facilitates selective update of the kernel 170 or the file-system 150 for cases in which the replacement image is greater in size than the currently resident kernel 170 or the file-system 150 , without physical relocation of images within the flash memory 100 , and hence eliminates undesirable erases and writes to the flash memory 100 .
- the size of the updated image is thus limited only by the available capacity of the flash memory 100 .
- the kernel 170 is located at the end of the flash memory 100 , and the file-system 150 near the start of the flash memory 100 , rather than the other way around. This relative arrangement facilitates dynamic file-system extension, if the file-system 150 supports such a mechanism.
- a predetermined memory portion at the top of the flash memory 100 can be reserved for the boot-loader 120 and update logic 130 combination.
- An approach similar to that described above in respect of the file-system 150 and kernel 170 ) can be used, wherein the boot-loader 120 and update logic 130 reside at different ends of this reserved memory portion.
- simpler approaches, as later described, can also be used.
- the scratch area 140 has to contain partition information.
- the partition area contains a set of null-terminated tuples.
- Each tuple set [(start bank i, start sector i, start offset i), (end bank i, end sector i, end offset i), NULL] represents the different flash fragments where the corresponding file-system resides, the tuple ordering reflecting the fragment ordering.
- the number of resident file-systems and the index of the root file-system are also part of the partition area.
- FIG. 3 “sect a” represents sector number “a”, and similar abbreviations are used for other sectors. For convenience, the offsets within the sectors are not shown.
- FIG. 4 is a schematic representation of the contents of the scratch area 140 , as represented in FIG. 3 . The core of multiple resident file systems is described in more detail below.
- FIG. 4 schematically indicates the contents of the scratch area 140 for the different images resident in the flash memory 100 , as represented in FIG. 3 .
- the host resident program 210 sends a “W” character to the update logic 130 , indicating that the erased sector is to be replaced by a revised scratch area 140 .
- the host resident program 210 then writes the length of the scratch area data, followed by the actual data representing the contents of the scratch area. This is received by the update logic 130 , and used to write to the scratch area 140 of the flash memory 100 .
- the update logic 130 program performs the following steps:
- the kernel start-address is in the same sector as the end of the resident file-system 150 , special care is taken in updating this sector—the bytes used by the file-system 150 in this sector are temporarily saved before the erase, and then copied back as appropriate to maintain the integrity of the contents of the memory 100 that are not updated.
- the scratch sector erase should not be performed along with step 3 , because if the host program terminates in the middle of the selective update, we would end up effectively losing the file-system image also.
- the update logic 130 program performs the following steps:
- the update logic 130 supports selective updates of a file-system image 150 , without changing or relocating other resident image(s). Further, as an updated image can be bigger or smaller than the original one, image replacement can result in the file-systems becoming fragmented (that is, each file-system could end up occupying non-contiguous areas in the flash memory 100 ). This is because, the update logic 130 would use space available in disjointed (that is, non-contiguous) memory fragments in the flash memory 100 rather than physically move resident images between different memory locations within the flash memory 100 .
- FIG. 3 is a schematic representation of an example of how a portion of the flash memory 100 may be occupied after a few selective updates to the memory 100 in which there are multiple file systems.
- FIGS. 6A and 6B jointly represent a flowchart of steps that occur for a generalized case in which there are multiple file-systems.
- the algorithm for selectively updating a file-system becomes more complex than described above.
- the steps involved are as follows:
- the update logic 130 also supports a “defrag” command (that is, one that defragments the contents of the flash memory 100 ).
- a “defrag” command that is, one that defragments the contents of the flash memory 100 .
- the computer 750 includes the control module 766 , a memory 770 that may include random access memory (RAM) and read-only memory (ROM), input/output (I/O) interfaces 764 , 772 , a video interface 760 , and one or more storage devices generally represented by the storage device 762 .
- the control module 766 is implemented using a central processing unit (CPU) that executes or runs a computer readable software program code that performs a particular function or related set of functions.
- CPU central processing unit
- the software may be stored in a computer readable medium, including the storage device 762 , or downloaded from a remote location via the interface 764 and communications channel 740 from the Internet 720 or another network location or site.
- the computer system 700 includes the computer readable medium having such software or program code recorded such that instructions of the software or the program code can be carried out.
- the program may be supplied to the user encoded on a CD-ROM or a floppy disk (both generally depicted by the storage device 762 ), or alternatively could be read by the user from the network via a modem device connected to the computer 750 .
- the computer system 700 can load the software from other computer readable media. This may include magnetic tape, a ROM or integrated circuit, a magneto-optical disk, a radio or infra-red transmission channel between the computer and another device, a computer readable card such as a PCMCIA card, and the Internet 720 and Intranets including email transmissions and information recorded on Internet sites and the like.
- the foregoing are merely examples of relevant computer readable media. Other computer readable media may be used as appropriate.
- Computer program means, or computer program, in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation or b) reproduction in a different material form.
Abstract
Description
- The invention relates to selectively updating flash memory, such as portions of code resident in flash memory for use in embedded devices.
- A typical configuration in many embedded devices is to store and run the operating system from the flash memory (or ROM), and store required data in a non-volatile RAM. However, many pervasive embedded devices have a full-fledged operating system, one or more file-systems, along with a bootloader and other data components, resident in flash memory.
- The life of flash memory storage is largely dictated by the number of accesses that occur to flash memory when updating flash memory. Any writes to a flash location are preceded by a corresponding erase. Erasing flash memory is a slow and time consuming process.
- During software development and testing, there is a frequent need to update a combination of selected images. Effective flash life time, and speed of development, can be adversely affected if existing images are relocated while performing such selective updates.
- In view of the above, a need clearly exists for improved method of updating code in embedded devices that at least attempts to address one or more of the above limitations.
- According to embodiments of the present invention, a memory medium is provided for selectively updating, with corresponding replacement images, any combination of images of a plurality of binary images recorded on the memory medium having a plurality of contiguous memory sectors that are erased before being rewritten. The memory medium includes one or more binary images recorded on the memory medium. The memory medium also includes an update logic image recorded on the memory medium. The update logic image includes instructions for execution by a computer system. The instructions, when executed by the computer system, cause the computer system to implement a method. The method includes determining whether an updating operation is to be performed, determining memory addresses of the memory medium at which a corresponding replacement image can be recorded, erasing the determined memory addresses, and writing the corresponding replacement image to the determined memory addresses of the memory medium. The one or more binary images include at least one kernel image, at least one file-system image, a boot-loader image, and a scratch area image. The boot-loader image and the update logic image are recorded at different ends of a first predetermined portion of the memory medium at the start of the memory medium. The scratch area image is recorded directly following the predetermined portion of the memory medium. The kernel image and the file system image are recorded at different ends of a second predetermined portion of the memory medium, following the scratch area image.
- According to embodiments of the present invention, a memory medium is provided for selectively updating, with corresponding replacement images, any combination of images of a plurality of binary images recorded on the memory medium having a plurality of contiguous memory sectors that are erased before being rewritten. The memory medium includes one or more binary images recorded on the memory medium. The memory medium also includes an update logic image recorded on the memory medium. The update logic image includes instructions for execution by a computer system. The instructions, when executed by the computer system, cause the computer system to implement a method that includes determining whether an updating operation is to be performed, determining memory addresses of the memory medium at which a corresponding replacement image can be recorded, erasing the determined memory addresses, writing the corresponding replacement image to the determined memory addresses of the memory medium, and determining whether the size of the replacement image is less than or equal to the size of the selected image. If the size of the replacement image is not less than or equal to the size of the selected image, the method includes determining whether the replacement image can be accommodated by free capacity in the memory medium, determining whether the replacement image can be accommodated by memory addresses of the selected image and any free memory addresses that directly follow the selected image. If the size of the replacement image is greater than the size of the corresponding replacement image, the method includes revising the recorded end address of the selected image to take into account any free memory addresses directly following the selected image. If the size of replacement image is greater than the size of the corresponding replacement image, the method includes successively identifying free memory fragments of the memory medium that can each individually accommodate part of the replacement image until the replacement image can be accommodated by the successively identified free fragments in combination, and identifying one or more memory fragments for the replacement image such that portions of the replacement image can be recorded across a minimum number of memory fragments. The memory fragments that do not have the end address of another image directly preceding the respective fragment are used in preference to fragments that do have the end of another image directly preceding the respective fragment.
- According to embodiments of the present invention, a memory medium is provided for selectively updating, with corresponding replacement images, any combination of images of a plurality of binary images recorded on the memory medium having a plurality of contiguous memory sectors that are erased before being rewritten. The memory medium includes one or more binary images recorded on the memory medium. The one or more binary images include at least one kernel image, at least one file-system image, a boot-loader image, and a scratch area image. The memory medium also includes an update logic image recorded on the memory medium. The update logic image includes instructions for execution by a computer system, wherein the instructions, when executed by the computer system, cause the computer system to implement a method. The method includes determining whether an updating operation is to be performed, determining memory addresses of the memory medium at which a corresponding replacement image can be recorded, erasing the determined memory addresses, writing the corresponding replacement image to the determined memory addresses of the memory medium, erasing the scratch area image recorded on the memory medium, and writing a replacement scratch area image to replace the scratch area image, after the writing of the replacement image. The replacement scratch area image reflects the replacement of the selected image with the replacement image, and the writing of the replacement scratch area image is performed after the selected image is replaced with the corresponding selected image.
-
FIG. 1 is a schematic representation of the contents of a flash memory device. -
FIG. 2 is a schematic representation of the communication that occurs between update logic stored in the flash memory ofFIG. 1 , and a host program in a host machine operatively connected with the flash memory ofFIG. 1 . -
FIG. 3 is an alternative schematic representation of the contents of the flash memory ofFIG. 1 , in which multiple file systems are resident. -
FIG. 4 is a schematic representation of the contents of a scratch area of the flash memory ofFIG. 3 . -
FIG. 5 is a schematic representation of the sequence of communications between the host program and the update logic ofFIG. 2 when the scratch area ofFIG. 4 is updated. -
FIGS. 6A and 6B jointly represent a flowchart of the steps that occur when the contents of a flash memory is updated. -
FIG. 7 is a schematic representation of a host machine computer system which executes the host program ofFIG. 2 . - Selectively updating one or more portions of the contents of a flash memory (such as in an embedded device) is described herein. The described technique allows for selective updates of parts of embedded flash memory, which provides advantages in increasing the speed of embedded software development while minimising the number of erases and writes to the flash memory.
- The term “flash memory” is used herein to describe a type of non-volatile memory in which is an electrically erasable and programmable read-only memory (EEPROM) having a programmable operation which allows for the erasure of blocks of memory. Unless there is a clear and express indication to the contrary, any reference to a “flash memory” is taken to include any non-volatile storage memory in which (i) data can be written only in unwritten or erased physical memory locations and in which (ii) a zone of contiguous physical memory locations are simultaneously erased. For ease of reference, storage memory having such characteristics is referred to as “flash memory”.
- This minimisation of erases/writes comes about due to a combination of organizing the images in flash memory suitably, and introducing fragmentation if necessary. Any fragmented image can be defragmented prior to product shipment of the embedded device in which the flash memory resides.
- A host machine contains the images that are to be updated in the flash memory. For the purposes of the following description, it is assumed that the host machine is to be connected to the embedded device through a serial line. Of course, this general approach is also valid for a network connection, though the initial handshake process will be different.
- The embedded device with which the technique is used preferably has a mechanism for determining when to initiate an update. This may be, for example, a jumper setting in the device, or some signal or other indication provided by the host machine etc.
- When the embedded device powers on, the boot-loader gets control of the device. If the boot-loader detects that an update indication (such as a software flag, or some form of hardware indication) is ON, the boot-loader copies the update logic to RAM and branches to the update logic. This procedure is needed as most flash memory chips do not support simultaneous writes and reads—which is required if the update logic writes to the flash memory, while also executing from the flash memory. If the boot-loader senses that the update indication is OFF, the boot-loader boots the system. The kernel flash-disk block driver subsequently mounts a file-system resident in flash memory of the embedded device as the root device.
- Flash memory is normally organized into banks and further into sectors. Erases can be done only at the granularity of a sector. A flash-write has to follow an erase on the corresponding sector.
- In the described arrangement, it is assumed that there is only one file-system image and one kernel image resident in flash memory. It is later explained how the described techniques differ for cases in which there are multiple images and file systems.
-
FIG. 1 schematically represents aflash memory 100 used in connection with the techniques described. Physically, theflash memory 100 comprisesN banks flash memory 100 there is aboot loader 120, followed by theupdate logic image 130. - Next, a
scratch area 140 contains the start addresses and sizes of all the flash-resident images (as explained below in further detail, with reference toFIG. 4 ). Thescratch area 140 is used by the boot-loader 120 to boot the device. Thescratch area 140 is also used by the kernel flash-disk block driver to determine where the file-system 150 starts. Theupdate logic 130 software also needs to use the contents of thescratch area 140 to perform selective updates. From a programming perspective, it is faster (though not necessary) if thescratch area 140 resides in a separate sector from theupdate logic 130 and thefile system 150. If thescratch area 140 is resident in a partly used sector, the remaining contents have to be buffered while re-programming thescratch area 140. The kernel flash-disk driver emulates a disk inflash memory 100, so that one or more file-systems can be resident on theflash memory 100. -
FIG. 2 represents the start protocol, between thehost resident program 210 executing on the host machine, and theupdate logic 130 executing on theflash memory 100 of the embedded device. - As soon as the
update logic 130 begins execution, it emits a UPDATE— START— CHAR 230 to inform thehost resident program 210 on the host machine that it is ready to start the update. If the embedded device has multiple serial ports, the device sends theUPDATE_START_CHAR 230 on all ports. When the host machine receives the UPDATE— START— CHAR 230, thehost resident program 210 returns a UPDATE_ACK 240 to acknowledge receipt of theUPDATE_START_CHAR 230. Theupdate logic 130 polls each of the serial ports (using a timeout of, for example, 1 ms) to determine thePORT_NUMBER 250 on which theUPDATE_ACK 240 arrived. - The
update logic 130 now knows the serial port to which all reads and writes are to be directed. Now theupdate logic 130 sends the serial port number (that is, PORT— NUMBER 250) back to the host machine (through the serial port that it just detected), completing the three-way handshake. Thehost resident program 210 subsequently sends commands to theupdate logic 130 to configure the serial port that it thus detected, and to immediately switch the serial port to the same configuration. - The start protocol, described immediately above, also enables the implementation of a
multi-functional program 210 on the host machine. For instance, certain processor chips used in embedded devices have two boot-modes: (i) a first boot-mode that is used to load the boot-loader 120 and the other images for the first time (code-load), and (ii) a second boot-mode that boots from the top of theflash memory 100. In this second mode, a boot-loader is expected to be resident at the top of theflash memory 100. An example of such a processor chip is the EP7211 produced by Cirrus Logic of Austin, Tex. During different boot modes, different memory addresses obtain control. The software resident at these different memory addresses emits different start characters. By using different start characters for these different modes, thehost resident program 210 executing on the host machine determines the boot mode that is active. - The start address for the kernel in
flash memory 100 is computed as follows. The highest possible word-aligned address that accommodates the kernel inflash memory 100 is obtained. For this, one calculates backwards from the end address of the lastflash memory bank 116. The word-size depends on the flash chip-set used. Certain flash memory chip-sets support “page-write” commands. If the flash memory writes are done using this “page-write” mode, the computed address is the highest possible ‘page-aligned’ address. - The start address for the file-
system image 150 is the first word-aligned (or, “page-aligned”, as noted above) address following thescratch area 140. Thekernel 170 and the file-system 150 reside at different ends of theflash memory 100. This facilitates selective update of thekernel 170 or the file-system 150 for cases in which the replacement image is greater in size than the currentlyresident kernel 170 or the file-system 150, without physical relocation of images within theflash memory 100, and hence eliminates undesirable erases and writes to theflash memory 100. The size of the updated image is thus limited only by the available capacity of theflash memory 100. - During updates, if the image start address is not recomputed, there is a significant probability (especially while updating file-system images) that some of the sectors that are to be updated have data that has not changed. Only those sectors whose replacement data does not match the original data need be updated. Whether to perform this optimization or not, can be decided by the user at run time, via a special command supported by the update logic. In cases where the replacement image has large differences with the resident image, the above process might slow down the update, even though it could reduce the number of flash erases. This is described in more detail subsequently, in the general case where there are multiple file-system images. In the case of kernel images, revising the start address is preferable to fragmentation, especially if the embedded device executes the kernel in place; that is, runs the kernel directly from
flash memory 100. - The
kernel 170 is located at the end of theflash memory 100, and the file-system 150 near the start of theflash memory 100, rather than the other way around. This relative arrangement facilitates dynamic file-system extension, if the file-system 150 supports such a mechanism. - A predetermined memory portion at the top of the
flash memory 100 can be reserved for the boot-loader 120 and updatelogic 130 combination. An approach similar to that described above (in respect of the file-system 150 and kernel 170) can be used, wherein the boot-loader 120 and updatelogic 130 reside at different ends of this reserved memory portion. However, simpler approaches, as later described, can also be used. - To support multiple file-systems, the
scratch area 140 has to contain partition information. The partition area contains a set of null-terminated tuples. Each tuple set [(start bank i, start sector i, start offset i), (end bank i, end sector i, end offset i), NULL] represents the different flash fragments where the corresponding file-system resides, the tuple ordering reflecting the fragment ordering. The number of resident file-systems and the index of the root file-system are also part of the partition area. - In
FIG. 3 , “sect a” represents sector number “a”, and similar abbreviations are used for other sectors. For convenience, the offsets within the sectors are not shown.FIG. 4 is a schematic representation of the contents of thescratch area 140, as represented inFIG. 3 . The core of multiple resident file systems is described in more detail below. - The computed addresses and the image sizes for the various images are stored in the
scratch area 140.FIG. 4 schematically indicates the contents of thescratch area 140 for the different images resident in theflash memory 100, as represented inFIG. 3 . -
FIG. 5 is a schematic representation of the sequence of steps that occur between thehost resident program 210 and theupdate logic 130 in theflash memory 100 when thescratch area 140 is to be updated. The sequence of steps is progressively ordered from top to bottom. First, thehost resident program 210 sends a “Z” character to theupdate logic 130, denoting that the sector of theflash memory 100 in which thescratch area 140 is resident is to be erased under control of theupdate logic 130. Once this step is performed by theupdate logic 130, a “+” character is sent by theupdate logic 130 to thehost resident program 210 to indicate that thescratch area 140 has been erased. - In response, the
host resident program 210 sends a “W” character to theupdate logic 130, indicating that the erased sector is to be replaced by a revisedscratch area 140. Thehost resident program 210 then writes the length of the scratch area data, followed by the actual data representing the contents of the scratch area. This is received by theupdate logic 130, and used to write to thescratch area 140 of theflash memory 100. - Once the write process has been completed by the
update logic 130, a checksum representing the integrity of the scratch area data is returned by theupdate logic 130 to the host program. A checksum received from theupdate logic 130 by thehost resident program 210 that agrees with that computed by thehost resident program 210 indicates that the updating of thescratch area 140 has been successfully completed. - In order to update only the
kernel 170 resident in flash memory, theupdate logic 130 program performs the following steps: - 1. Detecting whether the
new kernel 170′ will fit into the memory available (the free space available for thenew kernel 170′ can be calculated from the information present in the scratch area 140). If sufficient capacity is not available, the update is stopped and the user is alerted accordingly. - 2. Computing the start address to load the
replacement kernel 170′ as previously described in relation to theoriginal kernel 170. - 3. Computing the location of the sectors to be erased.
- 4. Erasing the required sectors, located in
step 3. - 5. Writing the
new kernel 170′ toflash memory 100. Performing appropriate bank address translation, if the updatedkernel 170′ spans banks - 6. Computing and returning checksums to the
host resident program 210. The checksums are computed and sent for every block of data written toflash memory 100. Thehost resident program 210 indicates the update progress whenever a checksum value is received, if it matches the value that it expects. If a checksum mismatch is detected, the update is stopped and the user is alerted accordingly. - 7. Reading the contents of the
scratch area 140. Erasing thescratch area 140 and updating thescratch area 140 using new values for kernel start and kernel size. - If the kernel start-address is in the same sector as the end of the resident file-
system 150, special care is taken in updating this sector—the bytes used by the file-system 150 in this sector are temporarily saved before the erase, and then copied back as appropriate to maintain the integrity of the contents of thememory 100 that are not updated. - The scratch sector erase should not be performed along with
step 3, because if the host program terminates in the middle of the selective update, we would end up effectively losing the file-system image also. - In order to instead update only the flash resident file-
system 150, theupdate logic 130 program performs the following steps: - 1. Detecting whether the new file-
system 150′ will fit into the memory available (the free space available for the new file-system 150′ can be calculated from the information present in the scratch area 140). If sufficient capacity is not available, the update is stopped and the user is alerted accordingly. - 2. Computing the start address for the replacement file-
system image 150′ as the first word-aligned address following the scratch area, as previously described. - 3. Computing the location of the sectors to be erased. Only those sectors whose replacement data differs from the original data needs to be replaced, as previously described.
- 4. Erasing the required sectors computed in
step 3. - 5. Writing the replacement file-
system 150′ image toflash memory 100. Performing appropriate bank address translation if the update spans banks - 6. Computing and returning checksums to the
host resident program 210 on the host machine. The checksums are computed and sent for every block of data written to flash. Thehost resident program 210 indicates the update progress whenever a checksum value is received, if it matches the value that it expects. If a checksum mismatch is detected, the update is stopped and the user is alerted accordingly. - 7. Reading the contents of the
scratch area 140. Erasing thescratch area 140 and updating thescratch area 140 using the newly computed values for file-system start and end addresses. - If the kernel start-address is in the same sector as the end address of the file system, special care is taken in updating this sector—the bytes used by the
kernel 170 in this sector are temporarily saved before the erase, and then copied back as appropriate, to maintain the integrity of the contents of thememory 100 that is not updated. - The scratch sector erase should not be performed along with
step 3, because if thehost resident program 210 terminates in the middle of the selective update, thekernel image 170 is effectively lost. - An approach analogous to that used for the
kernel 170/file-system 150 combination described above can also be used for the boot-loader 120/update logic 130 combination. A predetermined size can be reserved for the boot-loader/update logic combination—both residing at different ends of the reserved memory portion of theflash memory 100, as noted above. This technique can be simplified if it can be assumed that the boot-loader 120 and updatelogic 130 are updated together. - Many flash memory chips have initial sectors whose sizes are small. In that case, it is realistic for the boot-
loader 120 and updatelogic 130 to occupy separate predetermined sectors (saysector 0 and sector 1). In this case, selectively updating them is more convenient. As with the steps described above, the new start address and size information is updated in thescratch area 140 once the update is complete. - It is described above how a combination of images are selectively updated. For instance, one can update just the boot-
loader 120 and thekernel 170 without disturbing the other images, obviating erases and writes in other parts of theflash memory 100. - A total update (of all the flash resident images) is relatively straight forward. The relevant steps are as follows:
- 1. Erasing all sectors.
- 2. Computing the start address for the images (boot-
loader 120, updatelogic 130,kernel image 170 and file-system image 150), as described above. Updating thescratch area 140 with these new values. - 3. Writing the new images to the flash memory at the computed addresses. Performing appropriate bank address translation, if necessary.
- 4. Computing and returning checksums to the
host resident program 210. The checksums are computed and sent for every block of data written toflash memory 100. Thehost resident program 210 indicates the update progress whenever a checksum value is received, if it matches the value that it expects. If a checksum mismatch is detected, the update is stopped and the user is alerted accordingly. - The
update logic 130 also supports reverse updates (that is, copying combination of images from theflash memory 100 of the embedded device back to the host machine). This is useful for taking file-system backups, debugging crashes, etc. - For example, if a file-
system image 150 is to be uploaded from the embedded device to the host machine, theupdate logic 130 does the following (similar steps can be followed to upload other combinations of flash-resident images): - 1. Determining the file-system start and end addresses from the
scratch area 140. - 2. Sending the file-system size back to the
host resident program 210. - 3. Reading the file-
system image 150 from the above-determined start address, and transmitting it back to thehost resident program 210. - 4. Computing (by the host resident program 210) the checksum and sending the checksum back to the
update logic 130. Theupdate logic 130 flags an error to thehost resident program 210 if the checksum value received by theupdate logic 130 does not match the value that it expects. - The embedded device may have multiple file-system images or kernel images resident in the
flash memory 100. It is now assumed for convenience and ease of illustration that only multiple file-system images are present. However, the described procedure in general holds for multiple kernel images also. - The
update logic 130, as described above, supports selective updates of a file-system image 150, without changing or relocating other resident image(s). Further, as an updated image can be bigger or smaller than the original one, image replacement can result in the file-systems becoming fragmented (that is, each file-system could end up occupying non-contiguous areas in the flash memory 100). This is because, theupdate logic 130 would use space available in disjointed (that is, non-contiguous) memory fragments in theflash memory 100 rather than physically move resident images between different memory locations within theflash memory 100. - Whenever the
update logic 130 decides to use a fragment, theupdate logic 130 updates the partition information in thescratch area 140. This process is described in further detail below.FIG. 3 is a schematic representation of an example of how a portion of theflash memory 100 may be occupied after a few selective updates to thememory 100 in which there are multiple file systems. -
FIGS. 6A and 6B jointly represent a flowchart of steps that occur for a generalized case in which there are multiple file-systems. In this instance, the algorithm for selectively updating a file-system becomes more complex than described above. With reference toFIGS. 6A and 6B , the steps involved are as follows: - 1. It is first determined in
step 605 whether the size of the new file-system image is smaller than or equal to the size of the existing file-system image. If the size of the new image is smaller than or equal to the size of the existing image, the new file-system uses the needed fragments out of the ones owned by the original image, instep 645. - 2. If the updated file-system image is larger than the existing size, it is determined in
step 610 whether all the free flash fragments can together accommodate the extra size of the new file-system image. (The location of free flash fragments can be figured out from the tuple information in the partition table). If the physical memory capacity available is not sufficient, the update is stopped and the user is alerted instep 615. - 3. Else if there is sufficient space, any free space following the existing image is used in
step 620, in addition to the original fragments, by recomputing the end address of the last component fragment accordingly. - 4. If that is insufficient or unavailable, a free flash fragment that best fits the remaining size is chosen in
step 630. If the largest free fragment is smaller than the needed size, that is used and the same procedure is continued for the remaining size. Fragments that do not have the end of another image directly above it are used in preference to the ones that do have the end of another image directly above it. - 5.
- (a) While writing data to pre-existing fragments, the following process is followed in
step 635. Sectors, whose original and replacement data match, are left undisturbed. For this, bytes that are being received from the external host are buffered for the sector that is being currently updated. The comparison between the received data and the data present in the corresponding sector is stopped as soon as a mismatch is detected. Whether to perform the above optimization or not, can be controlled by the user at run time, via a special command supported by the update logic. This is because, in cases where the replacement image has large differences with the resident image, the above comparison might slow down the update process, even though it could reduce the number of flash erases and writes. - (b) If the user does not want the above optimisation, the update logic first expands the component fragments wherever possible, before making use of the new free fragments described in step 4. Fragments that do not have the end of another image directly preceding the fragment are enlarged in preference to the fragments that do have the end of another image directly above the fragment.
- (c) The necessary sectors are erased, data is written to flash, bank translation is performed if the fragment spans banks, and checksums are computed and sent to the host in
step 640. If the write is to a sector partly being used by another image, the relevant bytes are saved and copied back to their former position to maintain the integrity of the unaltered portions.
- (a) While writing data to pre-existing fragments, the following process is followed in
- 6. Once the new image has been updated in
step 645 orsteps 610 to 640, the partition table is also updated instep 650 with the new fragment information (start and end addresses of each fragment) for each updated file-system. - The writes to the partition table (that is, involving the scratch area 140) are done onto a cached copy. The partition table is written back to the flash at the end of the update process.
- The
update logic 130 also supports a “defrag” command (that is, one that defragments the contents of the flash memory 100). When thehost resident program 210 issues this command, theupdate logic 130 makes each image reside in a physically contiguous area, using RAM for temporary storage. - Selective file-system updates as described above will be used during embedded software development, and the ‘defrag’ command will be used prior to product shipment. ‘Defrag’ would eliminate the burden of extra translation logic inside the kernel flash-disk block device driver. If the file-systems in the flash are fragmented, the kernel flash-disk device driver will have to do extra translation on the offsets generated by the file-system, to locate the correct physical bank, sector and sector offset.
- The techniques described above are driven by a
host resident program 210 resident on the host machine. The host machine sends a series of commands to theupdate logic 130. In response, theupdate logic 130 processes these commands and returns the results back to thehost resident program 210 on the host machine. - For example, if the host machine wants the
update logic 130 to erase thescratch area 140, thehost program 210, sends a command to theupdate logic 130. Erasing a sector typically takes a few milliseconds. Theupdate logic 130 sends back an acknowledgment (ACK) when it completes the erase. The host waits till the ACK arrives, before sending the next command to theupdate logic 130. - The above described process involves a host machine from which the updated image originates. The host machine and the
host resident program 210 that executes on the host machine can be implemented using a computer program product in conjunction with acomputer system 700 as shown inFIG. 3 . In particular, the process performed by thehost resident program 210 can be implemented as a computer software program, or some other form of programmed code, executing on thecomputer system 700. - The
computer system 700 includes acomputer 750, avideo display 710, andinput devices computer system 700 can have any of a number of other output devices including line printers, laser printers, plotters, and other reproduction devices connected to thecomputer 750. Thecomputer system 700 can be connected to one or more other similar computers via a communication input/output (I/O)interface 764 using anappropriate communication channel 740 such as a modem communications path, an electronic network, or the like. The network may include a local area network (LAN), a wide area network (WAN), an Intranet, and/or theInternet 720, as represented. - The
computer 750 includes thecontrol module 766, amemory 770 that may include random access memory (RAM) and read-only memory (ROM), input/output (I/O) interfaces 764, 772, avideo interface 760, and one or more storage devices generally represented by thestorage device 762. Thecontrol module 766 is implemented using a central processing unit (CPU) that executes or runs a computer readable software program code that performs a particular function or related set of functions. - The
video interface 760 is connected to thevideo display 710 and provides video signals from thecomputer 750 for display on thevideo display 710. User input to operate thecomputer 750 can be provided by one or more of theinput devices O interface 772. For example, a user of thecomputer 750 can use a keyboard as I/O interface 730 and/or a pointing device such as a mouse as I/O interface 732. The keyboard and the mouse provide input to thecomputer 750. Thestorage device 762 can consist of one or more of the following: a floppy disk, a hard disk drive, a magneto-optical disk drive, CD-ROM, magnetic tape or any other of a number of existing non-volatile storage devices. Each of the elements in thecomputer system 750 is typically connected to other devices via a bus 780 that in turn can consist of data, address, and control buses. - The software may be stored in a computer readable medium, including the
storage device 762, or downloaded from a remote location via theinterface 764 and communications channel 740 from theInternet 720 or another network location or site. Thecomputer system 700 includes the computer readable medium having such software or program code recorded such that instructions of the software or the program code can be carried out. - The
computer system 700 is provided for illustrative purposes and other configurations can be employed without departing from the scope and spirit of the invention. The foregoing is merely an example of the types of computers or computer systems with which the embodiments of the invention may be practised. Typically, the processes of the embodiments are resident as software or a computer readable program code recorded on a hard disk drive as the computer readable medium, and read and controlled using thecontrol module 766. Intermediate storage of the program code and any data may be accomplished using thememory 770, possibly in conjunction with thestorage device 762. - In some instances, the program may be supplied to the user encoded on a CD-ROM or a floppy disk (both generally depicted by the storage device 762), or alternatively could be read by the user from the network via a modem device connected to the
computer 750. Still further, thecomputer system 700 can load the software from other computer readable media. This may include magnetic tape, a ROM or integrated circuit, a magneto-optical disk, a radio or infra-red transmission channel between the computer and another device, a computer readable card such as a PCMCIA card, and theInternet 720 and Intranets including email transmissions and information recorded on Internet sites and the like. The foregoing are merely examples of relevant computer readable media. Other computer readable media may be used as appropriate. - Further to the above, the described methods can be realised in a centralised fashion in one
computer system 700 or in a distributed fashion where different elements are spread across several interconnected computer systems. - Computer program means, or computer program, in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation or b) reproduction in a different material form.
- As described, the above techniques allow for selective updates of portions of the contents of a flash memory 100 (of, for example, an embedded device) to be performed with relative ease and speed, from a host machine onto the
flash memory 100. The method uses a combination of suitably organizing the images inflash memory 100 and introducing fragmentation if necessary, to minimize the number of flash operations, and hence speed up the update process. - Various alterations and modifications can be made to the techniques and arrangements described herein, as would be apparent to one skilled in the relevant art.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/859,350 US9678761B2 (en) | 2002-04-01 | 2015-09-20 | Technology for selectively updating memory-resident images |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/115,203 US7089549B2 (en) | 2002-04-01 | 2002-04-01 | Updating flash memory |
US11/489,977 US8495608B2 (en) | 2002-04-01 | 2006-07-20 | Communicating with an update logic image |
US13/920,030 US9170936B2 (en) | 2002-04-01 | 2013-06-17 | Communicating to update a memory |
US14/859,350 US9678761B2 (en) | 2002-04-01 | 2015-09-20 | Technology for selectively updating memory-resident images |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/920,030 Continuation US9170936B2 (en) | 2002-04-01 | 2013-06-17 | Communicating to update a memory |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160011884A1 true US20160011884A1 (en) | 2016-01-14 |
US9678761B2 US9678761B2 (en) | 2017-06-13 |
Family
ID=29709445
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/115,203 Expired - Fee Related US7089549B2 (en) | 2002-04-01 | 2002-04-01 | Updating flash memory |
US11/489,977 Expired - Fee Related US8495608B2 (en) | 2002-04-01 | 2006-07-20 | Communicating with an update logic image |
US13/920,030 Expired - Fee Related US9170936B2 (en) | 2002-04-01 | 2013-06-17 | Communicating to update a memory |
US14/859,350 Expired - Fee Related US9678761B2 (en) | 2002-04-01 | 2015-09-20 | Technology for selectively updating memory-resident images |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/115,203 Expired - Fee Related US7089549B2 (en) | 2002-04-01 | 2002-04-01 | Updating flash memory |
US11/489,977 Expired - Fee Related US8495608B2 (en) | 2002-04-01 | 2006-07-20 | Communicating with an update logic image |
US13/920,030 Expired - Fee Related US9170936B2 (en) | 2002-04-01 | 2013-06-17 | Communicating to update a memory |
Country Status (1)
Country | Link |
---|---|
US (4) | US7089549B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9678761B2 (en) * | 2002-04-01 | 2017-06-13 | International Business Machines Corporation | Technology for selectively updating memory-resident images |
US20210149838A1 (en) * | 2019-11-14 | 2021-05-20 | Pegatron Corporation | Device, method and non-transitory computer readable medium for writing image files into memories |
Families Citing this family (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7409685B2 (en) | 2002-04-12 | 2008-08-05 | Hewlett-Packard Development Company, L.P. | Initialization and update of software and/or firmware in electronic devices |
US8479189B2 (en) | 2000-11-17 | 2013-07-02 | Hewlett-Packard Development Company, L.P. | Pattern detection preprocessor in an electronic device update generation system |
US7814474B2 (en) * | 2000-11-17 | 2010-10-12 | Hewlett-Packard Development Company, L.P. | Updatable mobile handset based on Linux with compression and decompression techniques |
TWI278750B (en) * | 2002-09-05 | 2007-04-11 | Mediatek Inc | System and method which updates firmware in a non-volatile memory without using a processor |
JP2004152279A (en) * | 2002-10-08 | 2004-05-27 | Matsushita Electric Ind Co Ltd | Program updating method, and terminal device |
US7480907B1 (en) * | 2003-01-09 | 2009-01-20 | Hewlett-Packard Development Company, L.P. | Mobile services network for update of firmware/software in mobile handsets |
TWI229291B (en) * | 2003-04-03 | 2005-03-11 | Inventec Corp | Device and method for updating contents of flash memory unit |
TW200421172A (en) * | 2003-04-04 | 2004-10-16 | Incomm Technologies Co Ltd | Drive codes upgrading method of portable memory device and device thereof |
US8555273B1 (en) | 2003-09-17 | 2013-10-08 | Palm. Inc. | Network for updating electronic devices |
US7904895B1 (en) | 2004-04-21 | 2011-03-08 | Hewlett-Packard Develpment Company, L.P. | Firmware update in electronic devices employing update agent in a flash memory card |
EP1756711A1 (en) * | 2004-05-31 | 2007-02-28 | STMicroelectronics Pvl. Ltd. | A method for remotely upgrading the firmware of a target device using wireless technology |
TWI257047B (en) * | 2004-06-25 | 2006-06-21 | Fan-Sheng Lin | Controlling method for embedded system device |
US8526940B1 (en) | 2004-08-17 | 2013-09-03 | Palm, Inc. | Centralized rules repository for smart phone customer care |
US9292274B2 (en) * | 2004-08-31 | 2016-03-22 | Smith Micro Software, Inc. | Efficient method and system for reducing the time to apply update package |
KR100664933B1 (en) * | 2004-12-15 | 2007-01-04 | 삼성전자주식회사 | Method and apparatus for storing multimedia data to nonvolatile storage by block unit |
DE102005050288A1 (en) * | 2005-10-14 | 2007-04-19 | Siemens Ag | System for implementing software updates in embedded systems and a method for doing so |
TWI275029B (en) * | 2005-11-18 | 2007-03-01 | Hon Hai Prec Ind Co Ltd | An embedded system and method for processing data thereof |
JP2009540417A (en) * | 2006-06-08 | 2009-11-19 | エヌエックスピー ビー ヴィ | Device for remote defragmentation of embedded devices |
WO2007146710A2 (en) | 2006-06-08 | 2007-12-21 | Hewlett-Packard Development Company, L.P. | Device management in a network |
US7721059B2 (en) * | 2006-07-06 | 2010-05-18 | Nokia Corporation | Performance optimization in solid-state media |
US8752044B2 (en) | 2006-07-27 | 2014-06-10 | Qualcomm Incorporated | User experience and dependency management in a mobile device |
CN100435099C (en) * | 2006-11-21 | 2008-11-19 | 四川长虹电器股份有限公司 | Method for upgrading program of embedded system |
US7681009B2 (en) * | 2006-12-28 | 2010-03-16 | Motorola, Inc. | Dynamically updateable and moveable memory zones |
US9100248B2 (en) * | 2007-05-07 | 2015-08-04 | Vorne Industries, Inc. | Method and system for extending the capabilities of embedded devices through network clients |
KR101472797B1 (en) * | 2007-07-16 | 2014-12-15 | 삼성전자주식회사 | Method and apparatus for reading or writing data |
EP2195737B1 (en) * | 2007-10-03 | 2018-07-11 | ABB Schweiz AG | Method for reprogramming applications in embedded devices and related device |
US20090144538A1 (en) * | 2007-11-05 | 2009-06-04 | Duda Kenneth J | Patch installation at boot time for dynamically installable, piecemeal revertible patches |
WO2009074444A2 (en) * | 2007-12-13 | 2009-06-18 | Telefonaktiebolaget L M Ericsson (Publ) | Updating firmware of an electronic device |
EP2310941A1 (en) * | 2008-06-02 | 2011-04-20 | Awox | Method and device for updating a computer application |
EP2169545A1 (en) | 2008-09-26 | 2010-03-31 | Moxa Inc. | Embedded system that automatically updates its software and the method thereof |
GB2472051B (en) | 2009-07-22 | 2012-10-10 | Wolfson Microelectronics Plc | Power management apparatus and methods |
US8886597B2 (en) * | 2009-10-28 | 2014-11-11 | Sandisk Il Ltd. | Synchronizing changes in a file system which are initiated by a storage device and a host device |
US10496608B2 (en) * | 2009-10-28 | 2019-12-03 | Sandisk Il Ltd. | Synchronizing changes in a file system which are initiated by a storage device and a host device |
US8700669B1 (en) * | 2009-12-21 | 2014-04-15 | Emc Corporation | Techniques for data storage system management |
EP2453352A1 (en) * | 2010-11-08 | 2012-05-16 | Gemalto SA | Software updating process for an embedded device |
TWI502507B (en) * | 2013-01-22 | 2015-10-01 | Wistron Corp | Method of updating battery firmware, portable electronics device and rechargeable battery module |
US9647838B2 (en) * | 2013-01-25 | 2017-05-09 | Ralph John Hilla | Restructuring the computer and its association with the internet |
KR102039537B1 (en) | 2013-03-15 | 2019-11-01 | 삼성전자주식회사 | Nonvolatile storage device and os image program method thereof |
US10116493B2 (en) | 2014-11-21 | 2018-10-30 | Cisco Technology, Inc. | Recovering from virtual port channel peer failure |
US10162625B2 (en) * | 2015-04-14 | 2018-12-25 | Ford Global Technologies, Llc | Vehicle control storage methods and systems |
US10394491B2 (en) * | 2016-04-14 | 2019-08-27 | International Business Machines Corporation | Efficient asynchronous mirror copy of thin-provisioned volumes |
US10333828B2 (en) | 2016-05-31 | 2019-06-25 | Cisco Technology, Inc. | Bidirectional multicasting over virtual port channel |
US11509501B2 (en) * | 2016-07-20 | 2022-11-22 | Cisco Technology, Inc. | Automatic port verification and policy application for rogue devices |
US10430121B2 (en) | 2016-08-22 | 2019-10-01 | International Business Machines Corporation | Efficient asynchronous mirror copy of fully provisioned volumes to thin-provisioned volumes |
US10193750B2 (en) | 2016-09-07 | 2019-01-29 | Cisco Technology, Inc. | Managing virtual port channel switch peers from software-defined network controller |
US10620879B2 (en) | 2017-05-17 | 2020-04-14 | Macronix International Co., Ltd. | Write-while-read access method for a memory device |
US10547509B2 (en) | 2017-06-19 | 2020-01-28 | Cisco Technology, Inc. | Validation of a virtual port channel (VPC) endpoint in the network fabric |
US10445088B2 (en) * | 2018-01-11 | 2019-10-15 | Macronix International Co., Ltd. | System boot code clone |
TWI716767B (en) * | 2018-11-20 | 2021-01-21 | 和碩聯合科技股份有限公司 | Data updating system, embedded electronic device and data updating method |
WO2020107469A1 (en) * | 2018-11-30 | 2020-06-04 | 深圳市大疆创新科技有限公司 | Application processing method and apparatus and storage medium |
CN111008033A (en) * | 2019-10-30 | 2020-04-14 | 中国航空工业集团公司洛阳电光设备研究所 | Universal DSP (digital signal processor) online upgrading system and upgrading method based on serial port |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5930504A (en) * | 1996-07-22 | 1999-07-27 | Intel Corporation | Dynamic nonvolatile memory update in a computer system |
US6560703B1 (en) * | 2000-04-18 | 2003-05-06 | International Business Machines Corporation | Redundant updatable self-booting firmware |
US20030163508A1 (en) * | 2002-02-26 | 2003-08-28 | International Business Machines Corporation | Background code update for embedded systems |
US20030229752A1 (en) * | 2002-04-01 | 2003-12-11 | Sreekrishnan Venkiteswaran | Updating flash memory |
US20040205745A1 (en) * | 2001-07-30 | 2004-10-14 | International Business Machines Corporation | Method and system for identifying compatibility between firmware images |
US7017004B1 (en) * | 2002-03-29 | 2006-03-21 | Microsoft Corporation | System and method for updating contents of a flash ROM |
US20060190939A1 (en) * | 2000-11-17 | 2006-08-24 | Shao-Chun Chen | Updatable mobile handset based on linux with compression and decompression techniques |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5210854A (en) * | 1989-06-14 | 1993-05-11 | Digital Equipment Corporation | System for updating program stored in eeprom by storing new version into new location and updating second transfer vector to contain starting address of new version |
US5594903A (en) * | 1991-02-26 | 1997-01-14 | Lynx Real-Time Systems, Inc. | Operating System architecture with reserved memory space resident program code identified in file system name space |
US5870609A (en) * | 1993-12-17 | 1999-02-09 | Xircom, Inc. | Technique for bootstrapping executable code to an adapter |
US5647986A (en) * | 1994-12-02 | 1997-07-15 | Nawathe; Dilip | Apparatus and process for distributed treatment of wastewater |
US5764992A (en) * | 1995-06-06 | 1998-06-09 | Apple Computer, Inc. | Method and apparatus for automatic software replacement |
US5701492A (en) * | 1996-03-29 | 1997-12-23 | Canon Kabushiki Kaisha | Fail-safe flashing of EPROM |
US6317827B1 (en) * | 1996-08-16 | 2001-11-13 | Intel Corporation | Method and apparatus for fault tolerant flash upgrading |
US6854000B2 (en) * | 1997-12-27 | 2005-02-08 | Canon Kabushiki Kaisha | Image forming apparatus and control method for the same |
US6532217B1 (en) * | 1998-06-29 | 2003-03-11 | Ip Dynamics, Inc. | System for automatically determining a network address |
TW436734B (en) * | 1998-12-24 | 2001-05-28 | Destiny Technology Corp | Printer firmware updating method |
IL129947A (en) * | 1999-05-13 | 2003-06-24 | Tadiran Telecom Business Syste | Method and apparatus for downloading software into an embedded system |
US7222155B1 (en) * | 1999-06-15 | 2007-05-22 | Wink Communications, Inc. | Synchronous updating of dynamic interactive applications |
US6880086B2 (en) * | 2000-05-20 | 2005-04-12 | Ciena Corporation | Signatures for facilitating hot upgrades of modular software components |
US8281022B1 (en) * | 2000-06-30 | 2012-10-02 | Emc Corporation | Method and apparatus for implementing high-performance, scaleable data processing and storage systems |
US20030182414A1 (en) * | 2003-05-13 | 2003-09-25 | O'neill Patrick J. | System and method for updating and distributing information |
US20090307068A1 (en) * | 2006-01-23 | 2009-12-10 | Futurelogic, Inc. | Distributed promotional coupon system with real-time activity monitoring |
US7478188B2 (en) * | 2006-06-02 | 2009-01-13 | Hewlett-Packard Development Company, L.P. | System and method for connecting a WUSB device to multiple WUSB hosts |
-
2002
- 2002-04-01 US US10/115,203 patent/US7089549B2/en not_active Expired - Fee Related
-
2006
- 2006-07-20 US US11/489,977 patent/US8495608B2/en not_active Expired - Fee Related
-
2013
- 2013-06-17 US US13/920,030 patent/US9170936B2/en not_active Expired - Fee Related
-
2015
- 2015-09-20 US US14/859,350 patent/US9678761B2/en not_active Expired - Fee Related
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5930504A (en) * | 1996-07-22 | 1999-07-27 | Intel Corporation | Dynamic nonvolatile memory update in a computer system |
US6560703B1 (en) * | 2000-04-18 | 2003-05-06 | International Business Machines Corporation | Redundant updatable self-booting firmware |
US20060190939A1 (en) * | 2000-11-17 | 2006-08-24 | Shao-Chun Chen | Updatable mobile handset based on linux with compression and decompression techniques |
US20040205745A1 (en) * | 2001-07-30 | 2004-10-14 | International Business Machines Corporation | Method and system for identifying compatibility between firmware images |
US20030163508A1 (en) * | 2002-02-26 | 2003-08-28 | International Business Machines Corporation | Background code update for embedded systems |
US7017004B1 (en) * | 2002-03-29 | 2006-03-21 | Microsoft Corporation | System and method for updating contents of a flash ROM |
US20030229752A1 (en) * | 2002-04-01 | 2003-12-11 | Sreekrishnan Venkiteswaran | Updating flash memory |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9678761B2 (en) * | 2002-04-01 | 2017-06-13 | International Business Machines Corporation | Technology for selectively updating memory-resident images |
US20210149838A1 (en) * | 2019-11-14 | 2021-05-20 | Pegatron Corporation | Device, method and non-transitory computer readable medium for writing image files into memories |
US11829329B2 (en) * | 2019-11-14 | 2023-11-28 | Pegatron Corporation | Device, method and non-transitory computer readable medium for writing image files into memories |
Also Published As
Publication number | Publication date |
---|---|
US20030229752A1 (en) | 2003-12-11 |
US8495608B2 (en) | 2013-07-23 |
US20130282966A1 (en) | 2013-10-24 |
US20070006211A1 (en) | 2007-01-04 |
US9170936B2 (en) | 2015-10-27 |
US7089549B2 (en) | 2006-08-08 |
US9678761B2 (en) | 2017-06-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9678761B2 (en) | Technology for selectively updating memory-resident images | |
US6477616B1 (en) | Storage device, storage system, memory management method, recording medium, and computer data signal | |
KR100448905B1 (en) | Computer system with nand flash memory for booting and storagement | |
US7302517B2 (en) | Apparatus and method for controlling execute-in-place (XIP) in serial flash memory, and flash memory chip using the same | |
EP1729304B1 (en) | Space management for managing high capacity nonvolatile memory | |
EP0522780B1 (en) | Control method for a computer memory device | |
EP1036364B1 (en) | Alignment of cluster address to block addresses within a semiconductor non-volatile mass storage memory | |
EP1938200B1 (en) | Initialization of flash storage via an embedded controller | |
US5953737A (en) | Method and apparatus for performing erase operations transparent to a solid state storage system | |
JP4037605B2 (en) | Nonvolatile memory unit controller, memory system having the controller, and nonvolatile memory unit control method | |
US7814264B2 (en) | Memory card, semiconductor device, and method of controlling semiconductor memory | |
US6745278B2 (en) | Computer capable of rewriting an area of a non-volatile memory with a boot program during self mode operation of the computer | |
US7783857B2 (en) | Data management apparatus and method, non-volatile memory, storage device having the non-volatile memory and data processing system | |
US20070136510A1 (en) | Storage device, memory managing device, memory managing method, and program | |
JPH10124384A (en) | Method for controlling non-volatile semiconductor memory | |
JPH0830515A (en) | Data processor using flash eeprom | |
US7809878B2 (en) | Apparatus and method for controlling flash memory | |
KR20050011869A (en) | Memory device using flash memory and error correction method the same | |
JP2002175193A (en) | Device and method for rewriting program | |
KR100316584B1 (en) | Flash Memory To Share With Booting And Main Operation Program In System And Upgrade Method In That Memory | |
JP2001344156A (en) | Device with flash memory and data rewriting method | |
US20040133755A1 (en) | Minimization of overhead of non-volatile memory operation | |
KR20000033437A (en) | Apparatus for implementing function of bootstrap loader | |
CN113535204A (en) | FPGA (field programmable Gate array) online upgrading method based on Flash reconstruction technology | |
JP2003150398A (en) | Flash memory |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VENKITESWARAN, SREEKRISHNAN;REEL/FRAME:036640/0776 Effective date: 20130617 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: AIRBNB, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:056427/0193 Effective date: 20210106 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20210613 |