When doing a software update in the field, often the whole root filesystem is replaced. However then also some board-specific settings like configuration files, calibration data, log files and so on are also lost. If you plan this correctly beforehand, then you can store this information in an own UBI volume that is not overwritten by the update. But sometimes such problems are only recognized when the update should be done and then it is too late and these files are already in the root filesystem.
This article shows how you can save a couple of such files in the UserDef partition in NAND and restore them in Linux in the new environment. The UserDef partition is a small MTD partition that is available on most F&S boards by default. It is rather small (e.g. only 768KiB on our i.MX6 boards), but is often big enough to save the necessary data. Please note that on boards with Cortex-M CPU, this region may already be occupied by the Cortex-M program.
The solution consists of two parts. One part is a script for U-Boot. It is meant to be integrated into your own update script. This part reads the files to be saved from the root filesystem (in the rootfs UBI volume on top of TargetFS) and concatenates them together to build one long data region. This is similar to what tar is doing. The resulting data region is then saved in the UserDef MTD partition. Then the regular update procedure can follow that installs the new root filesystem.
The second part is a script that is run when the newly updated Linux system is started for the first time. It is located in /etc/init.d and simply loads the contents of the UserDef partition and stores the content under the original file names. Then it renames itself so that it is not run again on subsequent starts.
Prerequisites:
- Board with NAND storage
- Board with free UserDef (or other) partition
- Root filesystem in ubifs
- Root filesystem mounted read/write
- Root filesystem using /etc/init.d for startup-scripts
Usage:
- Add the code of saveconfig.txt to your own update script before the old root filesystem is overwritten. Replace "/root" in the assignment to variable path with the path to your own directory where the files to save are located. Replace "file1 file2 file3" with the names of the files to be saved. It is OK if not all files exist on a specific board. Those missing files will be skipped. So it is possible to have a single update script that will work in
different board environments. Please remember that the sum of all file lengths and all the file names must not exceed the size of the UserDef partition.
After that code, you can overwrite the rootfs volume as you are used to. Be aware that the rootfs partition is already mounted and the UBI structure is held in RAM. So it is not a good idea to erase the whole TargetFS partition with nand erase.part, because the UBI infrastructure will not see this and will still write the new data using the old pointers and structures from RAM. This will most probably result in a corrupted root filesystem. It is not a good idea to erase the whole UBI anyway, because then all erase counters for the wear leveling are lost. So this should be no issue. Just overwrite the rootfs UBI volume with the new image without erasing it first. - In the S01restoreconfig.txt script, replace "/root" in the cd command with the path to the directory where the files should be stored again. You do not need to give any file names, the names are stored in UserDef, too, so the script will recover file names as well.
Verify that the given /dev/mtdblock has the correct number for the UserDef partition. This may vary from board to board. You can see this in the boot messages, where Linux shows a list of all MTD partitions. The partition numbers are counted starting at zero, so if UserDef is shown in the second row, then it is mtdblock1.
Store the script as /etc/init.d/S01restoreconfig in your new root filesystem that is installed with your update. The script will be executed when the system is started for the first time. Then the script will rename itself so that it is not called again on further boot processes. If you want to change this name, please remember to also update the line at the end of the script that does the renaming.
Your F&S Support Team
