3,260
edits
Changes
→On-the-field software upgrades
= On-the-field software upgrades =
One of the greatest challenges for embedded systems manufacturers is to guarantee that the software on the system can be updated in the easiest way. On-the-field software upgradability is a major requirement that allows to replace bogus code and to enhance application features. How to perform this operation is highly platform-dependent. The following section shows in detail a specific situation.
== U-Boot/Linux system ==
We assume the system is composed by the following parts stored in flash memory (NOR and/or NAND):
* U-Boot bootloader with redundant environments
* Linux kernel
* Root file system (read/write but not persistent)
* Additional file system (read/write, persistent)
We also assume that Linux MTD subsystem provides partitions accordingly:
* /dev/mtd0 -> U-Boot code
* /dev/mtd1 -> U-Boot environment #1
* /dev/mtd2 -> U-Boot environment #2
* /dev/mtd3 -> Linux kernel
* /dev/mtd4 -> root file system
* /dev/mtd5 -> additional file system
Basically we can upgrade the system through the bootloader or through the kernel.
{{ImportantMessage|text='''Please note that, in case of problems (e.g. power failures) in the middle of U-Boot upgrading, the system might get in an unrecoverable state.'''}}
== U-Boot-based upgrading ==
With the help of the U-Boot commands (tftpload, protect, erase and cp) we can download and store kernel images, file system images and U-Boot itself in the target system. The main disadvantage is that this procedure usually requires to physically access the system.
== Linux-based upgrading ==
Please note that, in order to erase and write MTD partitions, their writability flag must be set. When the update phase is not so straightforward, the “mechanisms“ for the upgrade can be created using linux scripts. In these cases, it is important that the embedded system is able to run programs like a tftp client, a ftp server/client or scp.
== Remote upgrading ==
When the system features a LAN or internet connection, a remote-update strategy can be implemented. If the machine can be contacted (for example using a telnet or ssh connection), it is quite simple to activate a script that executes all the necessary commands to complete the upgrade procedure.
Note: building Dropbear SSH server for ARM platform
Dropbear is a light SSH suite, with client and server applications. It could be built as a multibinary application, like the famous Busybox: a single executable that can be used for SSH server, SSH client, scp, etc.
For example, to build Dropbear for the Zefeer platform, the user must:
1. Set the environment variables:
i. export PATH=/usr/local/eldk41arm/usr/bin:$PATH
ii. export ARCH=arm
iii. export CROSS_COMPILE=arm-linux
2. Run the configuration tool:
./configure –build=ARCH --host=CROSS_COMPILE
3. Run the make tool
make PROGRAMS=”dropbear dbclient scp” MULTI=1 STATIC=1
More information are available in README, INSTALL and MULTI files included in the distribution; Dropbear sources are available here: http://matt.ucc.asn.au/dropbear/dropbear.html.
== Local upgrading ==
When the system doesn't allow a remote access, an operator must locally access the system through its user interface (in the best case) or through the serial port (in the worst case). If the
system provides a USB port, SD, MMC or PCMCIA slot, the system can retrieve the upgrade packages from those memory devices; if the user interface features a sort of upgrade command, the operator should just plug the device and activate the upgrade function. The serial port is the last option to connect to the system and manually send the proper commands to complete the upgrade procedure.