@@ -2,11 +2,11 @@
Project's road-map
==================
-Please take into account that most of the items here are proposals.
+Please take into account that most of the items here are *proposals*.
I get some ideas talking with customers, some ideas are my own thoughts.
There is no plan when these features will be implemented - this depends
if enough interest is raised and if there will be contribution to the project
-in terms of patches or financial contribution to develop a feature.
+in terms of patches or financial contributions to develop a feature.
Thanks again to all companies that have supported my work up now and to
everybody who has contributed to the project, let me bring SWUpdate
@@ -20,17 +20,42 @@ SWUpdate suitable for a large number of products.
This will help to build a community around the project
itself.
+Disk partitions
+===============
+
+SWUpdate is able to set and handle UBI partitions, while it requires external
+tools to set up disk partitions (sfdisk / fdisk). Because an update should be self-contained, it is
+desirable that SWUpdate will integrate the code to be able to set up partitions
+configured in sw-descriptions even for disks (eMMC / SD / Hard-disks).
+This will let to use `partitions` inside sw-description to set up disk partitions
+and not only UBI volumes, and add further features as restoring configuration data and so on.
+
+Support for further compressors
+===============================
+
+SWUpdate supports image compressed with zlib. This is a compromise between compression rate
+and speed to decompress the single artifact. To reduce bandwidth or for big images, a stronger
+compressor could help. Adding a new compressor must be careful done because it changes the
+core of handling an image.
+
+System Update
+=============
+
+Not just the single device, but several devices connected together to build a more
+complex system should be updated at once in an atomic way. The installation and the
+restart of the system must be done in a controlled way.
+
SWUpdate as Updater Gateway
-===========================
+---------------------------
This feature was introduced with the "swuforward" handler. It is already
possible to update a tree of devices if each of them runs SWUpdate. This
-feature is already implemented in SWUpdate for embedded linux.
+feature is already implemented in SWUpdate for embedded Linux.
Anyway, a lot of embedded devices have small processors and maybe not a full
blown OS. Ensuring security for all of them can be a risk, and it is
easier to make sure on a single device. If the device running SWUpdate is
-acting as gateway, it can translate protocols from backend and send
+acting as gateway, it can translate protocols from back-end and send
package updates to the connected small devices.
One example could be if SWUpdate runs as MQTT-broker and takes updates
@@ -40,6 +65,15 @@ suricatta to do this.
One other examples is using LWM2M. The gateway should be generic enough
to allow to add further protocols in future.
+Enhance swuforward handler
+--------------------------
+
+This handler requires that SWUpdate-slaves connected to the master run the Web-server
+with old API using a poll mechanism to check the update's progress. This forbids
+to run at the same time SWUpdate as slave and with the Website, because in old mode
+the website is not available anymore. If swuforward will switch to Web-sockets and implements
+the newer API, this constraint can be removed.
+
Binary delta updates
====================
@@ -53,6 +87,15 @@ and the feature should not introduce leaks and make the system
more vulnerable. It is accepted that different technologies could be added,
each of them solves a specific use case for a delta update.
+SWUpdate is already able to perform delta updates based on librsync library. This is
+currently a good compromise to reduce complexity. Anyway, this helps in case of
+small changes, and it is not a general solution between two generic releases.
+A general approach could be to integrate SWUpdate with CA-Sync to allow a delta upgrade
+from any release. First proof of concept shows that changes in both SWUpdate and CA-Sync
+are required to be conform with requirements and security concepts in SWUpdate. A design
+just using CA-Sync as external fetcher without integration in SWUpdate breaks
+SWUpdate's security concept.
+
Integration in Linux distro
===========================
@@ -70,11 +113,11 @@ New Handlers
Users develop own custom handlers - I just enforce and encourage everyone
to send them and discuss how to integrate custom handler in mainline.
-A handler to update a microcontroller connected via UART is introduced.
+A handler to update a micro-controller connected via UART is introduced.
It could be enhanced to support other interfaces (SPI for example).
Some ideas for new handlers:
- - handlers to update microcontrollers
+ - handlers to update micro-controllers
- FPGA updater for FPGA with Flash
- Package handler to install packages (ipk, deb)
Packages can be inserted into the SWU and the atomicity is
@@ -90,11 +133,11 @@ The flash handler for raw-devices (mainly NOR flashes) does not allow to
stream the image and an error is reported if "installed-directly" is set.
The handler can be extended to stream images.
-Handlers installable as plugin at runtime
+Handlers install-able as plugin at runtime
-----------------------------------------
The project supports Lua as script language for pre- and postinstall
-script. It will be easy to add a way for installing a handler at runtime
+script. It will be easy to add a way for installing a handler at run-time
written in Lua, allowing to expand SWUpdate to the cases not covered
in the design phase of a product.
@@ -109,31 +152,47 @@ a unauthenticated handler cannot run.
Support for evaluation boards
=============================
-New is meta-swupdate-boards - examples regarding evaluation boards are
-put there. Currently, there are examples for Beaglebone Black,
-Raspberri PI 3 and Wandboard. Maybe some more boards ? Patches welcome.
+meta-swupdate-boards contains examples with evaluation boards.
+Currently, there are examples using Beaglebone Black,
+Raspberri PI 3 and Wandboard. The repo is a community driven project:
+patches welcome.
-Backend support (suricatta mode)
+Back-end support (suricatta mode)
================================
-Backend: Hawkbit Offline support
+Back-end: check before installing
+--------------------------------
+
+In some cases (for example, where bandwidth is important), it is better to check
+if an update must be installed instead of installing and performs checks later.
+If SWUpdate provides a way to inform a checker if an update can be accepted
+before downloading, a download is only done when it is really necessary.
+
+Back-end: Hawkbit Offline support
--------------------------------
There are several discussions on Hawkbit's ML about how to synchronize
-an offline update (done locally or via the internal Webserver) with
+an offline update (done locally or via the internal Web-server) with
the Hawkbit's server. Currently, Hawkbit thinks to be the only one
deploying software. Hawkbit DDI API should be extended, and afterwards
changes must be implemented in SWUpdate.
-Backend: Consolidate "general server"
+Back-end: Consolidate "general server"
-------------------------------------
A second OTA server was introduced with 2018.11, but there is not
an open source solution for a server. Anyway, the very simple interface
of the "general server" can be used by anyone to introduce an own server
-instead of a more complicate solution with a backend like Hawkbit.
+instead of a more complicate solution with a back-end like Hawkbit.
+
+Back-end: support for generic down-loader
+---------------------------------------
+
+SWUpdate in down-loader mode works as one-shot: it simply try to download a SWU
+from a URL. For simple applications, it could be moved into `suricatta` to detect
+if a new version is available before downloading and installing.
-Backend: support for Mender
+Back-end: support for Mender
---------------------------
There was several discussion how to make a stronger collaboration between
@@ -157,7 +216,7 @@ A first version of SWUpdate-GUI was released with a base set of features. The go
is to have a low footprint compared to GUI developed with state of art frameworks.
This lets to still have a rescue that fits in small devices.
-Test and Continuos Integration
+Test and Continuous Integration
==============================
The number of configurations and features in SWUpdate is steadily increasing and
@@ -171,5 +230,4 @@ and tested on real hardware.
Documentation
=============
-Documentation should be improved. There is just a little documentation for meta-swupdate
-how to set it up with different configurations.
+Documentation is a central point in SWUpdate - maintaining it up to date is a must in this project.
Signed-off-by: Stefano Babic <sbabic@denx.de> --- doc/source/roadmap.rst | 100 ++++++++++++++++++++++++++++++++--------- 1 file changed, 79 insertions(+), 21 deletions(-)