RU2375769C2 - Automatic back up saving in modifications of embedded software - Google Patents

Abstract

FIELD: physics; computer engineering.

SUBSTANCE: invention relates to methods of modifying software through reception and execution of delta-files. Software is partitioned and stored in several memory units (201-204), defined in the address space (211) of the physical memory (48) in the device. The method includes stages on which: an additional memory unit (212), which is associated with the said several memory units, is determined; the said additional memory unit is cleared so as to determine the region of the additional memory unit; updated data are recorded for the first of the said several memory units, as defined by the said delta-file, into the said additional memory unit; the said memory unit is cleared, thereby shifting the said region of the additional memory unit by one unit; and updated data are recorded for the second of the said several memory units, as defined by the said delta-file, into the said first memory unit.

EFFECT: reduced power loss when modifying an assignment object.

8 cl, 5 dwg

Description

FIELD OF THE INVENTION

The present invention defines methods for use in computers and microprocessor systems for modifying software by receiving and executing delta files to modify a target. In particular, the present invention relates to improved solutions in order to cope with a possible loss of power supply during the modification of the target.

State of the art

There are several technologies that provide the ability to modify binary software files, sending only the differences between the current software version and the updated software version. The difference in the new version of a specific piece of software is usually about 1-10% of the source binary. The procedure for using a diff file, commonly called a delta file, is especially beneficial when updates are sent over low bandwidth unidirectional data channels, such as GPRS (General Purpose Packet Radio). This technology is called on-air firmware modification and is currently standardized in the OMA standard. One example of how this type of modification works can be outlined as follows.

The mobile phone, which is a microprocessor-controlled device that needs to be modified, currently has V1 software. The goal is to upgrade the software to the latest working version of V2. To update the software on your mobile phone, the following procedure is performed:

1) final software is compiled and linked, V2;

2) the difference D12 of the binary files V1 and the binary files V2 is calculated. D12 contains all the information needed to create V2 from V1;

3) D12 is delivered to the destination, for example, via GPRS;

4) automatic overwriting to flash memory, that is, modification, of the target device by using the current binary file V1 and D12 to create V2 at the target is allowed.

The target device is now upgraded to V2 just by sending a small update package D12 to the device.

A critical step in the above update process is the modification of the destination. Due to the fact that the final software, such as RTOS (real-time operating system) and applications, is overwritten, the loss of power supply can be fatal to the device. The upgrade process should provide 100% recovery from failures, it is understood that the upgrade process must be able to continue after an unforeseen power failure. A method for implementing the resiliency capability of the prior art is called biphasic transaction control, which is already used in a variety of applications, such as databases. The idea is to keep a copy of the old information during the update. Only when the update is complete is the old information deleted. Thus, there is always the opportunity to return to the last state if the update was disrupted during the update.

For devices using NOR-type flash memory, the memory is divided into blocks of the same size, usually 64 kB. There are special restrictions when recording to a NOR device. Only whole blocks can be erased at once, while all the bits in the block are set to 1. Recording can be done at the byte level, but this is only possible to change the state of a bit from 1 to 0. Modification of the NOR device is carried out block by block. To ensure the possibility of recovery during failures, each block is first copied to a special backup block before the updated block is written to the original block. This prior art procedure is described herein with reference to FIG. one.

The software of a particular device consists of four program blocks 1-4 stored in four memory blocks 101-104. The memory blocks 101-104 are defined in the memory area 111 on the physical memory of the device. The memory blocks 101-104 are depicted vertically, which is presented for individual states 106-110 during the update process. Each column represents a new state in the update process, running from left to right, as indicated by the arrows in the drawing. The process is also mapped to a delta package, status information, and the update application, but they are not illustrated here to clarify the overall process as such. During the update process, two program blocks 1 and 2 have already been updated, which is the state shown in column 106. Block 3 should be updated next. In order to be able to recover in case of a possible loss of power supply, the information must be constantly stored. The status information is used to track which block is being processed and in which update status you are currently in. In addition, the old block must be kept until a new block is generated. The update process of block 3 is carried out by pre-erasing the backup block 105, which is also set in the memory area 111, upon transition to state 107. Then, the data of block 3 are copied from block 103 to the backup block 105 upon transition to state 108. Then, block 103 is erased upon transition to state 109, leaving block 103 empty. Finally, when switching to state 110, the process of writing to block 103 is performed, modifying the data in it to the new block 3. Alternatively, a new block 3 is created in the backup block 105, instead of copying Insert the old block 3 into the backup block 105.

Without the use of the backup unit 105, the loss of power after erasing the unit and before the new unit is completely written would be irreparable, since neither the source unit nor the target unit will be available. When using the above procedure, it is always possible to resume the update from the place where it was interrupted by overwriting the last block and continuing the update.

A problem with this prior art procedure is that the recording time during the update on the flash memory is doubled, because each block must be recorded twice for each block to ensure recovery from a loss of power supply. For NOR type flash memory, the usual write speed is approximately 200 kilobytes per second. Then, the recording time of blocks when updating a 16-megabyte image is approximately 16 MB * 2 / 0.2 = 160 s, if all blocks must be updated. During the update, the device is completely unusable, so it is important to keep this time as small as possible. Depending on the size of the update and how the code changes are distributed in the new binary image, the number of blocks that need to be updated may vary. Experience has shown that most updates require updating most of all available blocks. There are ways to reduce the number of blocks that need to be updated by structuring the binary image so that updates are concentrated in smaller parts of the image. However, these techniques are quite complex.

Disclosure of invention

The main objective of the present invention is to provide an improved solution in order to ensure that the software update process is restored after interruption, for example, as a result of loss of power supply. In particular, the objective is to provide a solution for modifying software binaries with delta files, which minimizes the update time of the target.

According to a first aspect of the present invention, this task is performed by a method of updating software presented in a first version on a device by receiving and executing a delta file for modifying said first version to a second version, said software being divided and stored in a plurality of memory blocks defined in the address space of physical memory in the device, the method comprises the steps of:

- determine an additional memory block associated with the aforementioned set of memory blocks;

- erasing said additional memory unit to determine an area of the additional memory unit;

- write the updated data for the first of said plurality of memory blocks, as specified by said delta file, into said additional memory block;

- erasing said first memory block, thereby moving said region of the additional memory block by one block; and

- write updated data for the second of said plurality of memory blocks, as specified by said delta file, into said first memory block.

In a preferred embodiment, said additional memory unit is defined as an adjacent memory unit for said first memory unit in said address space.

It is useful if the method comprises the step of processing all of said plurality of memory blocks, one after another, starting from said additional memory block, by writing data to one of said plurality of memory blocks from the next memory block in said address space during modification, as is specified by said delta file until all of the plurality of memory blocks are shifted by one interval in the address space.

In one embodiment, the method comprises the step of changing the writing order of memory blocks in the address space from said modification from the first version to the second version to another modification from said second version to the third version.

Preferably, the method comprises the steps of:

- by means of the aforementioned device, before receiving and executing the delta file, they are connected to the server and transmit information related to the state of the current address space, which determines what type of delta file is applicable for modifying the mentioned software, depending on the existing position of the said additional unit in the said address space, and the first type of delta file is designed to modify the software presented in the mentioned memory blocks in one pore order in the address space, and the second type of delta file is designed to modify the software represented in said memory blocks in reverse order in the address space;

- download the delta file of the appropriate type of delta file from the server to the device; and

- modify the mentioned software using a suitable delta file.

In one embodiment, the method comprises converting the start address within said address space in the boot code for said software depending on the movement of data between said memory blocks during recording, as specified by said delta file.

According to a second aspect of the present invention, the problem is solved using a computer software product intended for use in an electronic device with computer control for updating the software presented in the first version of this device, and this device contains means for receiving and executing a delta file for modifying the aforementioned first version to a second version, wherein the software is divided and stored in a plurality of memory units Defined in an address space in a physical memory device, said computer program product comprises executable computer program code is designed for instructing the apparatus to perform the steps of:

- determining an additional memory block associated with said plurality of memory blocks;

- erasing said additional memory unit to determine an area of the additional memory unit;

- recording updated data for the first of said plurality of memory units, as specified by said delta file, into said additional memory unit;

erasing said first memory block, thereby moving said region of the additional memory block by one block; and

- recording updated data for the second of said plurality of memory blocks, as specified by said delta file, into said first memory block.

In one embodiment, the computer program product comprises executable computer program code designed to cause the device to perform the steps of each of the above method steps.

According to a third aspect of the present invention, the problem is solved using a radio communication terminal comprising a computer system with corresponding computer code for updating the software presented in the first version on the terminal, and means for receiving and executing a delta file for modifying said first version to the second version moreover, this software is divided and stored in a variety of memory blocks defined in the address space of the physical memory in the terminal, When this extra memory block corresponding to said plurality of memory blocks is defined in said address space, said terminal further comprising means for erasing said extra memory block to define an additional area of the storage unit; data recording means for recording updated data for a first of said plurality of memory units, as specified by said delta file, into said additional memory unit; data erasure means for erasing said first memory block for moving said region of the additional memory block by one block; wherein said data recording means is configured to record updated data for a second of said plurality of memory blocks, as specified by said delta file, into said first memory block.

In one embodiment, said additional memory unit is adjacent to said first memory unit in said address space.

Preferably, said data recording means is adapted to process all of said plurality of memory blocks, one after the other, starting from said additional memory block, by writing data to one of said plurality of memory blocks from the next memory block in said address space, in the modification time, as specified by the said delta file, until all of the said plurality of memory blocks are shifted by one interval in the address space.

Advantageously, the radio communication terminal comprises means for changing the recording order of memory blocks in the address space from said modification from the first version to the second version to the second modification from said second version to the third version.

In a preferred embodiment, said terminal is configured to connect to a server before receiving and executing a delta file for transmitting information related to the state of the current address space, determining what type of delta file is applicable for modifying said software, depending on the available position said additional block in said address space, wherein the first type of delta file is for modifying software, etc. arranged in the mentioned memory blocks in the same order in the address space, and the second type of delta file is used to modify the software presented in the mentioned memory blocks in the reverse order in the address space, said terminal contains means for downloading a delta file of the appropriate type of delta file from said server to said terminal and means for modifying said software using a suitable delta file.

Preferably, the radio terminal comprises means for converting the starting address within said address space in the boot code for said software depending on the movement of data between said memory units during recording, as specified by said delta file.

Brief Description of the Drawings

The features and advantages of the present invention will be better apparent from the following description of preferred embodiments with reference to the accompanying drawings.

FIG. 1 is a schematic illustration of a prior art software update process by modifying a target.

FIG. 2 is a schematic illustration of a process according to an embodiment of the present invention for updating software by modifying a target.

FIG. 3 is a schematic illustration of two different embodiments of the general process of FIG. 2.

FIG. 4 is a schematic illustration of an illustrative radio communication terminal implementing a computer program product for executing process steps according to the present invention.

FIG. 5 is a schematic illustration of the terminal of FIG. 4 with its integrated computer system while communicating with a base station for receiving update delta files for modifying a destination in a terminal.

The implementation of the invention

The present description relates to a means and methods for use in modifying firmware using delta files and modifying a target. The present invention is particularly useful for use in systems with a relatively small bandwidth, but is not limited to such areas. A preferred embodiment described below relates to the field of mobile telephony, and in particular to implementation in radio terminals. The term "radio communication terminal" includes all mobile communication equipment designed for radio communication with a radio station, and this radio station can also be a mobile terminal or, for example, a stationary base station. Thus, the term “radio terminal” includes mobile phones, communicators, electronic notebooks, smartphones, PDAs (personal digital assistants) mounted on a vehicle of a radio communication device, or the like, as well as portable laptop computers configured for wireless communication in, for example, a wireless local area network (WLAN). In addition, it must be emphasized that the terms “comprising” or “contains” when used in the present description and in the attached claims to indicate the features, elements or steps contained in them should in no way be construed as excluding the presence of other features, elements or steps, rather than explicitly stated.

The following description relates to preferred embodiments of the present invention, in which the address space contains four memory blocks. However, it should be noted that the present invention is applicable to an address space containing any number of memory blocks.

FIG. 2 depicts a preferred embodiment of an algorithm of a method according to the present invention for automatically backing up upon modification of firmware. Using this update algorithm, the need to reserve each block before updating it can be eliminated. In the illustrative embodiment of FIG. 2, the device comprises a memory defining a memory or address space 211 containing four memory blocks 201-204, each of which accommodates one program unit 1-4, respectively. In the state shown in column 206, there are no blocks updated before that, and the software is presented in the first version. As with the prior art described above, the memory area 211 comprises at least one block more than four blocks 201-204. However, instead of using a special redundant block, an additional block before the binary image represented by blocks 201-204 is used to move the entire software image one block back or forward in address space 211. In alternative embodiments, more than one can be used. for example two additional blocks.

When the software is to be updated, a device having physical memory to which the address space 211 belongs receives a delta file or a difference file including all the information necessary for updating the software from the first version to the second version. In a step from state 206 to state 207, additional unit 212 is erased. Then, the program unit 1 is updated in accordance with the delta file corresponding to the presented software. When using this algorithm, there is no need to reserve each block, because the updated block is always written immediately before the old block. The old block is not overwritten until the updated block is written. Instead of two erase / write operations, only one erase / write operation is required.

The proposed solution has obvious benefits, but also leads to a problem that needs to be overcome. When one update has passed, there is no longer one additional block at the beginning of the image, since the entire image was shifted in the address space. However, a preferred embodiment of the present invention provides a solution to this problem. After the first update operation, instead, one additional block will appear at the end of the image, block 204 in the embodiment of FIG. 2. At the same time, changing the direction of the update process, that is, writing blocks in the reverse order, the next update, you can use the same algorithm. Another problem is that the actual binary is paired with a specific base address. If the base address is moved, the code will not be executed, since absolute addresses for memory cells inside the binary image will point to an invalid address. One way or another, the absolute addresses used in the image must be moved one block after the update. According to one embodiment, this problem is solved by generating two delta files for each update, as shown schematically in FIG. 3.

In FIG. 3 D12 (UP) represents the first delta file for converting software version V1 of type A, which is shown in column 306, to V2 of type B, which is shown in column 307. An image of type A is therefore a specific address space with an additional block located after blocks 1-4, while the image of type B is a specific address space with an additional block located in front of blocks 1-4. Dl2 (DOWN) symbolizes the second delta file for converting software version V1 of type B, which is shown in column 308, to V2 of type B, which is shown in column 309. It is preferable that two delta files are generated by converting the build process for obtaining images of types A and B before generating the actual delta files. In conclusion, the starting address in the boot code must be converted to indicate the correct starting address, such that the software will execute as intended. This can be done as the last step of the upgrade procedure.

Update time, at best, is halved with the new redundancy algorithm provided in accordance with the present invention. This is the case when all blocks are updated. With the proposed solution, all blocks should be rewritten once. With today's solution, only modified blocks should be updated, but they must be written twice. For an update with a change of more than half the blocks, the new solution is faster. Typically, most blocks should be changed during the upgrade.

In a preferred embodiment, the present invention is used for broadcast modification of firmware and, in particular, is used in the field of mobile radio communications with radio terminals as target devices. FIG. 4 illustrates, by way of example, a device in which the present invention can be used, a radio terminal in an embodiment of a cellular mobile phone 40. The terminal 40 includes a chassis or housing 45 carrying an audio input from a user in the form of a microphone 41 and an audio output for a user in the form of a speaker 42 or a headphone jack (not shown). A set of keys, buttons or the like makes up the data input interface 43, used, for example, to dial a telephone number in a conventional manner. Additionally, a data output interface is included that includes a display device 44 configured to display communication information, a list of addresses, etc. in a manner well known to those skilled in the art. The radio communication terminal 40 includes electronic equipment for radio transmission and reception (not shown) and is configured to accommodate the built-in antenna 46 inside the housing 45, this antenna is indicated by a dotted line in the drawing as a substantially flat object. FIG. 5 is a simplified depiction of terminal 40 of FIG. 4. The terminal 40 may in the usual way be connected using communication means using its antenna 46 with the base station 50 included in the radio communication network. The terminal 40 further includes a computer system comprising a microprocessor control device 47 (controller) with an associated physical memory 48. In communication with the base station 50, the terminal 40 is capable of receiving delta files for modifying software present in the memory 48, in particular software binary files according to the invention. In addition, a computer system including processor 47 is configured to store and access software stored in memory 48 using the address space as defined in FIG. 2 and 3, and carry out the process steps defined above in connection with FIG. 2 and 3. In particular, the computer system controlled by the processor 47 comprises means for erasing and recording in the memory blocks, as defined by the contents of the delta files, for updating said software, thereby shifting the contents of the memory blocks, updated or not, by an interval corresponding to the size of one block in the address space.

The foregoing describes the basic requirements, preferred embodiments and modes of operation of the present invention. However, it should be understood by those skilled in the art that changes can be made to these embodiments without deviating from the scope of the present invention as defined in the appended claims.

Claims (8)

1. A method of updating the software presented in the first version (V1) on the device (40) by receiving and executing a delta file (D12) for modifying the aforementioned first version to the second version (V2), wherein the software is divided and stored in a plurality of memory blocks (201-204) defined in the address space (211) of the physical memory (48) in the device, the method comprising the steps of
determining an additional memory unit (212) associated with said plurality of memory units, initially placed in front of the first memory unit located on one side of the memory area;
erasing said additional memory unit;
writing updated data for the first memory block to said additional memory block;
move the additional memory block one block forward and
process all of the aforementioned plurality of memory blocks one by one by performing steps in which:
erasing said additional memory unit,
write updated data for the memory unit adjacent to the additional memory unit and following it to the additional memory unit,
simultaneously move said additional memory unit one block forward,
until all of the said plurality of memory blocks are shifted by one interval in the address space. 2. The method according to claim 1, comprising the step of changing the recording order of the memory blocks in the address space from said modification from the first version to the second version to another modification from said second version to the third version. 3. The method according to claim 2, containing stages in which:
by means of the aforementioned device, before receiving and executing the delta file, they are connected to the server and transmit information related to the state of the current address space, which determines what type of delta file is applicable for modifying the mentioned software, depending on the existing position of the said additional block in the said address space moreover, the first type of delta file is intended for modifying the software presented in the mentioned memory blocks in one piece ke in the address space, and the second type of delta file is designed to modify the software represented in said memory blocks in reverse order in the address space;
downloading a delta file of a suitable type of delta file from said server to said device and
modify said software using a suitable delta file. 4. The method according to any one of the preceding paragraphs, comprising the step of converting the starting address within said address space in the boot code for said software depending on the movement of data between said memory blocks during recording, as specified by said delta file. 5. A radio communication terminal (40) containing a computer system (47) with the corresponding computer code for updating the software presented in the first version (V1) on the terminal, and means (46) for receiving and executing a delta file (D12) for updating the aforementioned first version to the second version (V2), wherein the software is partitioned and stored in a plurality of memory blocks (201-204) defined in the address space (211) of the physical memory (48) in the terminal, characterized in that the additional block (212 ) memory, respectively uyuschy said plurality of memory blocks is defined in said address space, initially being placed before a first memory block located on one side of the memory area, and in that it further comprises means for erasing said extra memory block; data recording means for recording updated data for the first memory block into an additional memory block; means for moving the additional memory block one block forward and means for processing all of the above-mentioned plurality of memory blocks one by one by
erasing said additional memory unit,
writing updated data for the memory block adjacent to the additional memory block and following it to the additional memory block,
simultaneous movement of the aforementioned additional memory block one block forward,
until all of the said plurality of memory blocks are shifted by one interval in the address space. 6. The radio communication terminal according to claim 5, characterized in that it comprises means for changing the recording order of memory blocks in the address space from said modification from the first version to the second version to another modification from the said second version to the third version. 7. The radio terminal according to claim 6, characterized in that it is configured to connect to a server before receiving and executing a delta file for transmitting information related to the state of the current address space, which determines what type of delta file is applicable for modifying the mentioned software , depending on the existing position of said additional block in said address space, wherein the first type of delta file is for modifying the software provided said memory blocks in the same order in the address space, and the second type of delta file is for modifying the software presented in said memory blocks in the reverse order in the address space, said terminal comprising means for downloading a delta file of a suitable type of delta file from said server to said terminal; and means for modifying said software using a suitable delta file. 8. A radio communication terminal according to any one of the preceding claims 5 to 7, characterized in that it comprises means for converting the starting address within said address space in the boot code for said software depending on the movement of data between said memory blocks during recording, as specified by the delta file.

Images