| Age | Commit message (Collapse) | Author |
|---|
|
This write the received firmware image data to the secondary MCUboot
slot. This prepares an update.
With the MCUboot shell it can be applied with:
mcuboot request_upgrade permanent
kernel reboot
If the signature is valid the device will permanently update to the new
application firmware. Otherwise it will refuse the new image and boot
the old one.
|
|
This implements a HTTP handler capable of receiving the full data of the
firmware image upload. The data is not handled at all and thus not
written to flash.
This is just an incremental step towards successful firmware image
upload to the secondary MCUboot slot.
|
|
This adds the HTTP PUT /update handler which just returns HTTP 204 No
Content.
This is the minimal first step towards a working /update handler.
|
|
This allows to use all MCUboot related functionality during the
development via the shell. Furthermore it allows to inspect the current
state of the primary and secondary slot.
Both traits are very valuable especially during the development of the
remote update system.
|
|
Because of an issue likely related to hardware design on the
nucleo_f767zi board (see issue [1] for details) the firmware should
reboot in case network access cannot be established after 4 seconds.
This makes the firmware more robust at the moment. As soon as
iot-contact hardware without this issue exists the behavior can be
changed again.
[1]: https://github.com/zephyrproject-rtos/zephyr/issues/77794
|
|
This adopts this pattern from the bootloader build. It adds more
flexibility. It is assumed that in this way multiple builds for
different boards can easily be achieved.
|
|
This makes the structure of the `fw` folder more clear and separates
application-related code from bootloader- or rtos-related code.
|
