Re: Zephyr DFU protocol

David Brown

On Tue, Aug 29, 2017 at 02:58:55PM +0200, Richard Peters wrote:

My devices are in a BLE mesh network with no direct internet
connectivity to the outer world.
The user can connect with a smartphone ot tablet to one of the devices
in the mesh over BLE.
There is an App, which downloads the latest firmware for the devices to
the smartphone.

A firmware update will be transfered via BLE to the connected device and
then spread to all devices in the mesh that need this update.

I think there are two possible ways to achieve this:

1.) The update gets transferred to the target devices via bluetooth.
This happend in the zephyr application and gets stored in a filesystem
(on internal or external flash memory). The bootloader performs the
update from the filesystem after a reboot.
How this works in Mynewt (and will with Zephyr, if we use newtmgr) is
that mcuboot has two partitions: slot0 is where the primary code
lives, and slot1 is where the upgrade is written. It can be written
a bit at a time until complete. Then, a reboot into mcuboot will
cause the bootloader to detect the upgrade, and initiate swapping the
two images.

2.) The bootloader starts and receives the firmware (on the fly) from
the next device in the mesh network (which is running zephyr, too).
I'm not sure if this has been implemented, but it certainly could be.
Again, it would take the firmware from slot0 on the source device, and
place it into slot1 on the upgrading device.

The whole process should be optimized for the memory usage.
There will need to be sufficient flash set aside for the second image.
In most configuration, this is a dedicated partition, which avoids
needing to have filesystem management code in the bootloader.

The images themselves are signed, and upgrades with invalid signatures
will just be ignored.


Join to automatically receive all group messages.