3,260
edits
Changes
→Linux-based upgrading
== Linux-based upgrading ==
* System running Linux can be updated from user space using '''standard applications and tools'''. Most of the times the upgrade procedures can be created using common shell commands and scripts and usually, when the system provides a GUI, the upgrade function can be activated and controlled by the user through the graphical interface.
* If the network is availableUsually, it's a good point that when the embedded system is able to run programs like provides a tftp clientGUI, a ftp server/client, a ssh client (with scp program) or the wget program: with these tools, upgrade function is integrated in the system application interface and can easily retrieve the upgrade packages from be activated and controlled by the networkuser through graphical elements.
* If the '''network is available''', it's a good point that the embedded system is able to run programs like a tftp client, a ftp server/client, a ssh client (with scp program) or the wget program: with these tools, the system can easily retrieve the upgrade packages from the network. * When the '''network is unavailable''', a typical approach is to provide the end-user with a storage device (e.g. usb pen drive or SD card) with the software upgrade packages. This device can then be plugged to the system to run the upgrade.
* When preparing the root file system, it's fundamental to add all the application binaries and libraries required to implement the upgrade procedures.
* It's always possible to access the u-boot environment variables from user space, both for read and write operations. These operations can be performed using the '''fw_printenv/fw_setenv''' programs contained in the tools/env directory of the u-boot sources.
* In some cases, the upgrade procedures can be activated '''automatically''':
*# running periodic checks on some resource on the network
*# running periodic checks on some place on the local storage (e.g. a directory on the local file system which can be remotely written by ftp)
*# triggering the start when detecting an attached storage device containing the software upgrade
* A typical strategy on '''headless systems ''' is to create custom init scripts that perform checks on the file system at boot, looking for upgrade packages and triggering the upgrade procedure when required.
* Please note that, in order to erase and write MTD flash partitions, their writability flag must be set in Linux. Usually the U-Boot MTD partition dedicated to u-boot is protected against writein Linux, so an update of the kernel is required before storing a new u-bootimage. Updating U-Boot is not a common operationduring the system lifetime, but sometimes it is required to solve some bugs or implement new features.
== Local upgrading ==