JP2006202086A - Updating method for firmware - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To evade incomplete updating of firmware and to carry out firmware updating when the free area in ROM runs short. <P>SOLUTION: The incomplete updating of the firmware is evaded by operating a file system so that a file to be updated is given the original name after a file to be updated is written in as a different file to a free area in the ROM such as a flash memory through the file system and writing in is terminated normally. The safe and sure updating of the firmware is carried out by using a module for updating when it is necessary to update the firmware with a combination of two or more files, or the free area in the ROM runs short. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a secure firmware update method that does not require a special automatic recovery function or the like for a failure during firmware update.

  If an unexpected failure such as a power interruption occurs during the firmware update, the firmware in the ROM may be incompletely rewritten and damaged, and the system may not start up. To restore the firmware, manual work such as replacing the ROM was required.

Various methods have been proposed for automating firmware recovery. For example, in Japanese Patent Application Laid-Open No. 10-307726 “Firmware Recovery Method at Startup Error”, a method for backing up firmware before update to another storage device in advance is disclosed in Japanese Patent Application Laid-Open No. 2004-38716 “Automatic Recovery Function in Case of Failure”. In the “Firmware Update Method”, a method including a flag indicating whether the update has been successfully performed and a recovery program has been proposed.
JP-A-10-307726 JP 2004-38716 A

  However, these methods inevitably affect the cost of the product and increase the number of product test steps by preparing a firmware storage device other than the ROM that is normally used and a recovery program.

  The present invention does not recover when the above-mentioned firmware is incompletely rewritten and is damaged, but by updating the firmware via the ROM file system, it is possible to completely prevent the firmware from being damaged due to a failure. To do.

  By using the present invention, it is possible to provide a safe and reliable firmware update method for a conventional system without adding special hardware.

  The first feature of the present invention described in claim 1 is that the firmware is updated in units of files via the ROM file system. Conventionally, firmware is updated by rewriting the entire firmware or a group of modules divided into a plurality of blocks, but in the present invention, updating is performed in units of files via a file system.

  Furthermore, the firmware update is incomplete by writing the file to be updated in the free area of the ROM as a separate file and operating the file system so that the file to be updated has the original name after the writing is completed normally. The second feature is to avoid becoming.

  If a file that needs to be rewritten is directly replaced with new data sent from a network or other device, the firmware will be damaged if a failure occurs during this time. This is the same in the case of the update in the conventional block unit and the update through the file system.

  Therefore, the following method is used to prevent the firmware from being damaged. The file name to be updated is abcd.efg. First, a new file for update is stored in a free area of the ROM with a name different from the original name. Since the free area is managed by the file system itself, no special mechanism is required for the firmware update program, and it is sufficient to save the file with the changed name. Let this name be ~ abcd.efg. Even if a failure occurs at the time of saving, there is no particular problem because there is only a file with a name that has nothing to do with the execution of the system. After confirming that ~ abcd.efg has been created normally, the file system is operated to remap the area indicated by the updated new file data ~ abcd.efg to the file name abcd.efg. Since this operation is an atomic operation (inseparable operation) in the file system, there is no possibility that an illegal file is created when the file is updated.

  An example in the case where a UNIX (registered trademark) file system is used will be described. A file system other than UNIX (registered trademark) may be basically the same except for the names of the components. FIG. 1 shows an outline of a UNIX (registered trademark) file system. The file system maps the abstract file name A in the directory 10 to an index node (hereinafter referred to as an i-node) that is an abstract file segment. The i-node 11 that is an abstract file segment passes through the physical data blocks 13 to 14 storing the segment in the ROM 16 or further via the i-node 12 (there may be a plurality of i-nodes). Get) mapped to the physical data block 15. In this way, the UNIX (registered trademark) file system maps abstract file names and physical data blocks via inodes.

  FIG. 2 shows the state of the file system before updating the firmware. The file name to be updated is abcd.efg. This file is mapped to the physical data block 22 via the i-node 21. In this figure, the i-node description of files other than abcd.efg is omitted.

  FIG. 3 shows a state where an update file is written with a file name of ~ abcd.efg. The data block is secured in the free area of the ROM by the file system, and the update file is mapped to the physical data block 35 with the file name ~ abcd.efg via the i-node 34.

  FIG. 4 shows a state after the i-node pointer 46 corresponding to abcd.efg to be updated is re-mapped from the original value n to z corresponding to the update file ~ abcd.efg. Since this operation is an atomic operation performed using a system call of UNIX (registered trademark), it is impossible to fall into an illegal state due to a failure. The original i-node 41 is released from the mapping state with the file name, and the physical data block 42 mapped to the i-node 41 is thereafter treated as a free area.

  The above is the description of the update for one file, but when a plurality of files need to be updated, the firmware can be updated without falling into an illegal state by repeating the above procedure.

  The present invention according to claim 2 provides a method for updating firmware when it is necessary to perform a combination of a plurality of files and when the total file size of files to be updated exceeds the free space of the ROM. Application software and driver software used by the application software must be updated at the same time so that there is no inconsistency between versions. If a failure occurs at the time when only the driver software is successfully updated, inconsistency may occur between the application software and the driver software, and the system may not start.

  These problems are avoided using the following method. First, an update module is created. Further, the function of the module is basically the simple one shown in FIG. 5, and has other functions such as displaying an update status as necessary. Also, the module name must be consistent with the files to be updated at the same time, and must be activated whenever the system is executed as the update target.

  The update module is replaced with the file to be updated using the method of claim 1. The update module updates a file that needs to be updated from the network or another device using the update method according to claim 1. If this operation is repeated and it is confirmed that all the files are normal and updated, the process of updating itself to the original update file is performed, and the updated original system is activated.

  Even if a failure occurs in the middle of the update, the update module remains in the ROM, so the update can be continued at the next startup, and all files must be updated in the end. Is guaranteed.

Overview of UNIX (registered trademark) file system Inode state before file update Inode state after saving update file Inode state after file update Update module function flowchart

Explanation of symbols

10 directory 11 inode 12 inode 13 physical data block 14 physical data block 15 physical data block 16 ROM
20 directory 21 inode 22 physical data block 23 ROM
30 directory 31 inode 32 physical data block 33 ROM
34 inode 35 physical data block 40 directory 41 inode 42 physical data block 43 ROM
44 inode 45 physical data block 46 modified inode pointer

Claims (2)

  Write the file to be updated as a separate file to the free space in the ROM such as flash memory via the file system, and after successfully writing, operate the file system so that the file to be updated has the original name and update. Firmware update method characterized by avoiding incompleteness of image.
When the firmware needs to be updated with a combination of multiple files whose total file size exceeds the free space, an invalid file combination is made using an update module that has a function to update the necessary files. A firmware update method characterized in that the update is possible by repeating a plurality of differential updates.

Images