|
|
|
|
Automatic software update from a TFTP server
|
|
|
|
|
============================================
|
|
|
|
|
|
|
|
|
|
Overview
|
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
|
This feature allows to automatically store software updates present on a TFTP
|
|
|
|
|
server in NOR Flash. In more detail: a TFTP transfer of a file given in
|
|
|
|
|
environment variable 'updatefile' from server 'serverip' is attempted during
|
|
|
|
|
boot. The update file should be a FIT file, and can contain one or more
|
|
|
|
|
updates. Each update in the update file has an address in NOR Flash where it
|
|
|
|
|
should be placed, updates are also protected with a SHA-1 checksum. If the
|
|
|
|
|
TFTP transfer is successful, the hash of each update is verified, and if the
|
|
|
|
|
verification is positive, the update is stored in Flash.
|
|
|
|
|
|
|
|
|
|
The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro:
|
|
|
|
|
|
|
|
|
|
#define CONFIG_UPDATE_TFTP 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that when enabling auto-update, Flash support must be turned on. Also,
|
|
|
|
|
one must enable FIT and LIBFDT support:
|
|
|
|
|
|
|
|
|
|
#define CONFIG_FIT 1
|
|
|
|
|
#define CONFIG_OF_LIBFDT 1
|
|
|
|
|
|
|
|
|
|
The auto-update feature uses the following configuration knobs:
|
|
|
|
|
|
|
|
|
|
- CONFIG_UPDATE_LOAD_ADDR
|
|
|
|
|
|
|
|
|
|
Normally, TFTP transfer of the update file is done to the address specified
|
|
|
|
|
in environment variable 'loadaddr'. If this variable is not present, the
|
|
|
|
|
transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000
|
|
|
|
|
by default).
|
|
|
|
|
|
|
|
|
|
- CONFIG_UPDATE_TFTP_CNT_MAX
|
|
|
|
|
CONFIG_UPDATE_TFTP_MSEC_MAX
|
|
|
|
|
|
|
|
|
|
These knobs control the timeouts during initial connection to the TFTP
|
|
|
|
|
server. Since a transfer is attempted during each boot, it is undesirable to
|
|
|
|
|
have a long delay when a TFTP server is not present.
|
|
|
|
|
CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for
|
|
|
|
|
the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX
|
|
|
|
|
gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must
|
|
|
|
|
be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be
|
|
|
|
|
positive and is 100 by default.
|
|
|
|
|
|
|
|
|
|
Since the update file is in FIT format, it is created from an *.its file using
|
|
|
|
|
the mkimage tool. dtc tool with support for binary includes, e.g. in version
|
|
|
|
|
1.2.0 or later, must also be available on the system where the update file is
|
|
|
|
|
to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT
|
|
|
|
|
images.
|
|
|
|
|
|
|
|
|
|
This mechanism can be also triggered by the command "fitupd".
|
|
|
|
|
If an optional, non-zero address is provided as argument, the TFTP transfer
|
|
|
|
|
is skipped and the image at this address is used.
|
|
|
|
|
The fitupd command is enabled by CONFIG_CMD_FITUPD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example .its files
|
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
- doc/uImage.FIT/update_uboot.its
|
|
|
|
|
|
|
|
|
|
A simple example that can be used to create an update file for automatically
|
|
|
|
|
replacing U-Boot image on a system.
|
|
|
|
|
|
|
|
|
|
Assuming that an U-Boot image u-boot.bin is present in the current working
|
|
|
|
|
directory, and that the address given in the 'load' property in the
|
|
|
|
|
'update_uboot.its' file is where the U-Boot is stored in Flash, the
|
|
|
|
|
following command will create the actual update file 'update_uboot.itb':
|
|
|
|
|
|
|
|
|
|
mkimage -f update_uboot.its update_uboot.itb
|
|
|
|
|
|
|
|
|
|
Place 'update_uboot.itb' on a TFTP server, for example as
|
|
|
|
|
'/tftpboot/update_uboot.itb', and set the 'updatefile' variable
|
|
|
|
|
appropriately, for example in the U-Boot prompt:
|
|
|
|
|
|
|
|
|
|
setenv updatefile /tftpboot/update_uboot.itb
|
|
|
|
|
saveenv
|
|
|
|
|
|
|
|
|
|
Now, when the system boots up and the update TFTP server specified in the
|
|
|
|
|
'serverip' environment variable is accessible, the new U-Boot image will be
|
|
|
|
|
automatically stored in Flash.
|
|
|
|
|
|
|
|
|
|
NOTE: do make sure that the 'u-boot.bin' image used to create the update
|
|
|
|
|
file is a good, working image. Also make sure that the address in Flash
|
|
|
|
|
where the update will be placed is correct. Making mistake here and
|
|
|
|
|
attempting the auto-update can render the system unusable.
|
|
|
|
|
|
|
|
|
|
- doc/uImage.FIT/update3.its
|
|
|
|
|
|
|
|
|
|
An example containing three updates. It can be used to update Linux kernel,
|
|
|
|
|
ramdisk and FDT blob stored in Flash. The procedure for preparing the update
|
|
|
|
|
file is similar to the example above.
|
|
|
|
|
|
|
|
|
|
TFTP update via DFU
|
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
|
|
- It is now possible to update firmware (bootloader, kernel, rootfs, etc.) via
|
|
|
|
|
TFTP by using DFU (Device Firmware Upgrade). More information can be found in
|
|
|
|
|
./doc/README.dfutftp documentation entry.
|
