Disable imgtool publishing on Travis; update scripts to work on both
Travis and GH; add GH workflow for publishing.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
Add configuration and DTS overlays to run MCUboot + smp_svr on the
nrf52840dk using the secondary slot in the external QSPI NOR flash.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
TinyCrypt uses a modified version of micro-ecc that is also used by the Mbed Cordio BLE stack. When building mcuboot for a target with BLE enabled, this causes multiple-defined symbol errors during linking. Due to the nature of Mbed's current build system, it is difficult to fix this.
Mbed will soon release a more flexible cmake-based build system that will make it possible to exclude these TinyCrypt files from an application build that may also link Cordio BLE sources.
Until then, this commit temporarily disables the use of TinyCrypt with Mbed-OS and excludes its sources from the build to avoid this build error.
Signed-off-by: George Beckstein <becksteing@embeddedplanet.com>
This commit reverts the addition of an mbed-os.lib file introduced with the Mbed-OS port. Mbed-OS build tools use .lib files to pull in additional dependencies automatically with a single command. The intended usage of mcuboot with mbed-os is to clone mcuboot *next to* mbed-os, rather than mbed-os inside mcuboot.
Signed-off-by: George Beckstein <becksteing@embeddedplanet.com>
This PR provides a porting layer implementation and framework for building an mcuboot-based bootloader with Mbed-OS. Some symbols are not provided by the Mbed-OS port within mcuboot, namely:
- The secondary storage device (see below)
- The signing keys
- The encryption keys, if used
Use of this port is demonstrated by the following projects:
- https://github.com/AGlass0fMilk/mbed-mcuboot-demo (a complete mcuboot/Mbed-OS-based bootloader)
- https://github.com/AGlass0fMilk/mbed-mcuboot-blinky (example showing how to make an Mbed-OS application that is bootable by mcuboot)
Memory porting implementation:
The underlying implemenation uses Mbed's BlockDevice API as the storage backend for mcuboot's memory operations. This provides a very flexible way of configuring the location and layout of the secondary flash storage area. To build an mcuboot-based bootloader with Mbed-OS, the user must implement a hook function, mbed::BlockDevice* get_secondary_bd(), to provide the secondary BlockDevice that mcuboot will use.
The signing and encryption keys must also be provided by the user. They can be generated using the existing imgtool utility in the same manner used by Zephyr. There are no automated build steps currently provided by Mbed-OS to sign/encrypt build artifacts.
Known limitations:
The update candidate encryption features have not yet been fully tested. A truly secure implementation will require integration with Mbed's TRNG API in the future to inhibit side-channel attacks on the decryption process.
The TinyCrypt backend is currently only supported for Mbed-OS builds when building with the GCC toolchain. The new cmake-based Mbed-OS build system will fix the underlying issue (file name uniqueness).
Signed-off-by: George Beckstein <becksteing@embeddedplanet.com>
Signed-off-by: Evelyne Donnaes <evelyne.donnaes@arm.com>
Signed-off-by: Lingkai Dong <lingkai.dong@arm.com>
Co-authored-by: Lingkai Dong <lingkai.dong@arm.com>
Co-authored-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
This patch adds comments to reserve off a portion of the available TLV range
for use by vendors for proprietary TLV types.
Signed-off-by: Andy Gross <andy.gross@juul.com>
The 'revert' mechanism in direct-xip is similar to the one in swap mode.
It requires the trailer magic to be added to the signed image. When a
reboot happens without the image being confirmed at runtime (without the
image_ok flag being set), the bootloader considers the image faulty and
erases it. After this it will attempt to boot the previous image
instead. The images can also be made permanent (marked as confirmed in
advance) just like in swap mode.
Change-Id: Ibde9361d4a7302dd8efbb277b691b71eca0ca877
Signed-off-by: David Vincze <david.vincze@linaro.org>
After modifying the CONTROL register, ISB function should be
used to ensure the effect of the change applies to
subsequent code.
Due to the simple nature of the Cortex-M3, Cortex-M4, Cortex-M0+,
Cortex-M0, and Cortex-M1 pipeline,
omission of the ISB instruction does not cause any problem.
But might cause problem on a more advanced core.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
A previous fix for allowing padded images in the primary slot, ended up
causing an issue that would fail to upgrade under the right
circumstances. The issue was caused when the following set of steps
happened after an upgrade was detected:
1) trailer is erased on the primary slot
2) status is written to the primary slot
3) trailer is erased on the secondary slot
4) reset
1) trailer is erased on the primary slot
2) status partially written or not written to primary slot (no magic)
3) reset
This would result in images stored in the same slots they were
initially, aka no upgrade, which would fail the simulator test for
upgraded images.
The previous padded images fix was reverted and the status source was
upgraded to also check that the secondary slot has a valid magic in it,
so that there's never a circumstance where there is no trailer in any
of the slots while an upgrade operation is being decided on.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
Clean up the ARM core configuration only when
the CONFIG_MCUBOOT_CLEANUP_ARM_CORE is selected.
This involves cache and stack pointer limit registers.
Add also an MPU cleanup in platforms with the ARM MPU
supported.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Zephyr has introduced an option to perform the cleanup
of ARM core HW registers during early boot, when the
firmware is chain-loaded by MCUboot. Therefore, MCUboot
does not need to perform the same cleanup before jumping
to the application image. The patch relies on the fact
that building MCUboot with Zephyr implies loading also
a Zephyr-based application firmware. If this is not the
case, the application developer needs to enable the
MCUBOOT_CLEANUP_ARM_CODE Kconfig option manually, in the
project configuration.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The IAR toolchain does not handle the "%=" template. Emulate it with
a combination of __LINE__ and __COUNTER__
Signed-off-by: TTornblom <thomas.tornblom@iar.com>
This contains fixes for CC310 for nRF devices using the nrfxlib.
Removed some const for compilation warnings and added `NUM_ECC_BYTES`
define.
Signed-off-by: Sigvart Hovland <sigvart.m@gmail.com>
The function was made week so zephyr-rtos implementation
will be used if available.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
For some configurations, eg CONFIG_BOOT_DIRECT_XIP=y, fih_rc might
never be initialized; initialize and fix warning.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
The last data packet might be non aligned to multiple of
the flash write-block-size. This cause that the `image upload`
mcumgr command mighty fail if the device flash driver doesn't
support one-byte write-block-size.
This patch complements the last write operation to aligned chunk
so it meet the requirements.
Added check for ensure than received data chunk doesn't
cross expected image size.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Some design.md content is causing build errors when they are included
in a .rst based documentation tree in Sphinx.
Adjust the format to make it work in both systems.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Enables BOOT_ERASE_PROGRESSIVELY for Nordic nRF boards.
This fixes issue where mcumgr upload command would result in
device being deleted, but no new image being uploaded
due to timeout while waiting for erase operation.
This avoids a delay of several seconds during firmware upload.
Signed-off-by: Bernt Johan Damslora <bernt.johan.damslora@nordicsemi.no>
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This to correctly set the kconfig default value.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This fixes soft-bricks that we have seen as a result
of the bootloader being interrupted by the watchdog.
Signed-off-by: Emil Hammarstrom <emil.hammarstrom@assaabloy.com>
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Removes the current `flash_area_read_is_empty` which lacked a bit of
clarity in its naming and error handling, as well as requiring an
extra API in the flash map, and switches to using an internal function
`bootutil_buffer_is_erased`.
Code that was previously using `flash_area_read_is_empty` must now be
updated to do a `flash_area_read` followed by a call to
`bootutil_buffer_is_erased` with the read buffer.
The proposal was previously discussed here:
https://github.com/zephyrproject-rtos/zephyr/pull/28519
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
When the image in the primary slot is padded, the boot source is
considered the primary slot; this results in skipping the typical
initialization of the trailer, which ends up bricking the device. As
it is fine to always initialize the trailer in the primary slot when
starting a new upgrade the extra check was removed.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
The comment on why first parameter to bootutil_img_validate is allowed
to be NULL, in boot_image_validation of single_loader.c, has been
rewritten.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Direct inclusion of "bootutil/fault_injection_hardening_delay_rng.h"
might cause linking collision as this header belongs to `FIH_ENABLE_DELAY`
mode.
This header is already included by "bootutil/fault_injection_hardening.h"
appropriately.
fixes#831
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Remove unnecessary includes and create conditionally
the MCUBOOT_FIH_PROFILE_OFF define to avoid redefinition
warnings.
Change-Id: I6a34af2a5e45b81fdedd26bc1fa50ab0b9a05918
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Some Zephyr boards enable HW stack protection by default, which
propagates in mcuboot build. Bootloader works fine with that option, but
the problem arises when we jump to application code. HW stack protection
catches application code during early init, which results in
"unresponsive" application.
Disable HW stack protection, so it doesn't make any harm for application
code.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Fix boostrapping in swap-move that was being skipped due to the having
an erased header in the primary slot which caused an early return
because of the requirement of having to re-read image headers when
"moving" an image during an upgrade.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
Remove `MCUBOOT_OVERWRITE_ONLY_FAST` from overwrite-only upgrades, to
make it compatible with `large-write` tests after the latest changes
to the fast overwrite code; make it default when bootstrapping.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
Previously when `MCUBOOT_OVERWRITE_ONLY_FAST` was set, the whole amount
of sectors that stored an image were being copied. After this commit
only the exact amount of data used by the image is copied; this avoids
copying some 0xff (or garbage) data between the end of the image and the
end of the last sector storing it.
Extra trailer management was added which suits using the copy upgrade
routine also for bootstrapping.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
The simulated alignment functions were returning u8 which would be
invalid for any alignment beyond 128; as a first step in the direction
of allowing larger alignments, make them u16 which should allow for up
to 2**15 aligment size.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
Add support for the pinnacle_100_dvk board.
The Pinnacle 100 modem slot 1 partition
is located in external QSPI.
Add a board file overlay to enable QSPI flash.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
Fabio Utzig