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>
Automate process of selecting correct .pem key file.
Zephyr users are familiar with using 'menuconfig' and similar tools
for seeing what options are available, so remove =n choices from
prj.conf which were used to show the available options.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
- Add Kconfig option `CONFIG_BOOT_SIGNATURE_TYPE_NONE`. When y,
The bootloader will not verify the cryptographic signature of the image
at boot or prior to upgrade. Image integrity check is retained.
Images would still need to be processed using `imgtool` however no key
should be provided to skip cryptographic signature generation.
Signed-off-by: Arvin Farahmand <arvinf@ip-logix.com>
Add Log processing configuration synchronous as default
if multithreading is disabled.
Additionally Kconfig makes MULTITHREADING default
if USB is selected.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Add Zephyr option to enable building a bootloader that uses an
alternative swap algorithm, that first moves up all sectors in slot1 and
then directly swaps between slot0 and slot1.
Signed-off-by: Fabio Utzig <utzig@apache.org>
CONFIG_MULTITHREADING is generally assumed to be y by the zephyr
kernel, even though that's not reflected in the Kconfig. For example,
semaphores depend on it being y, but CMake will still build sem.c even
if it's n.
The sensible default for this option is thus y.
However, it's a size advantage to disable it if the platform drivers
are all aware of this option, such as nRF.
Let's re-work our use of this option to keep it disabled when we know
it's safe, but enable it by default so more platforms can be expected
to work out of the box.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
This commit removes the non-standard BOOT_HAVE_LOGGING Kconfig option.
Instead the standard LOG / MCUBOOT_LOG_LEVEL can be used to control
logging.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
Let's ensure that random Zephyr changes in logging don't affect
the resource usage in MCUBOOT, by setting LOG_LEVEL_DEFAULT
to 0.
Signed-off-by: Michael Scott <mike@foundries.io>
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
The old log subsystem has been deprecated in Zephyr.
Migrate to the new subsystem to avoid compilation warnings.
In-place log processing is selected as it is required as MCUBoot is
one thread application.
Signed-off-by: Emanuele Di Santo <emdi@nordicsemi.no>
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Remove MPU_ALLOW_FLASH_WRITE from prj.conf and put it in
boot/zephyr/Kconfig enabling it only for every ARM_MPU
equipped device.
Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
Various Zephyr boards (I'm looking at you, every-single-nRF-board)
set CONFIG_BT_CTLR=y as well as CONFIG_BT. Make sure it's disabled for
MCUboot's default prj.conf, where it's not needed and has been causing
very verbose Kconfiglib warnings:
warning: BT_CTLR (defined at subsys/bluetooth/controller/Kconfig:10) was assigned the value 'y' but
got the value 'n'. You can check symbol information (including dependencies) in the 'menuconfig'
interface (see the Application Development Primer section of the manual), or in the Kconfig
reference at http://docs.zephyrproject.org/reference/kconfig/CONFIG_BT_CTLR.html (which is updated
regularly from the master branch). See the 'Setting configuration values' section of the Board
Porting Guide as well.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Power management requires multithreading and other kernel features that
are disabled in MCUboot, so disable it to avoid interrupts being
confused by power management code wrappers.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In order to provide a pleasant out-of-the-box experience to users,
default to the RSA .pem file so that users do not get a cryptic error
when building with the default .conf file in upstream.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Handle the CONFIG_BOOT_SIGNATURE_TYPE_xxx values in Zephyr's
mcuboot_config.h by converting them into the platform-agnostic MCUboot
definitions.
This requires some changes to the way the release test Makefile is
structured, since Kconfig symbols cannot be set from the command line.
Instead, use the OVERLAY_CONFIG feature of the Zephyr build system,
which allows specifying extra fragments to merge into the final
.config. (This is an orthogonal mechanism to setting CONF_FILE; it is
used by Zephyr's CI script sanitycheck to add additional fragments, so
it's appropriate for use by MCUboot's testing scripts as well.)
We additionally need to move to a single prj.conf file due to a
dependency issue. We can no longer determine CONF_FILE from the
signature type, since that is now determined from the final .config or
autoconf.h, which is a build output that depends on CONF_FILE.
To move to a single prj.conf:
- delete prj-p256.conf and adjust prj.conf to serve both signature types
- add a top-level mbedTLS configuration file which dispatches to
the right sub-header depending on the key type
- as a side effect, have the simulator pick the right config file
depending on the case
This fixes and cleans up quite a bit of the signature type handling,
which had become something of a mess over time. For example, it fixes
a bug in ECDSA mode's configuration that wasn't actually selecting
config-asn1.h, and forces the simulator to use the same mbedTLS
configuration file as builds for real hardware.
Finally, we also have to move the mbedTLS vs. TinyCrypt choice into
mcuboot_config.h at the same time as well, since CMakeLists.txt was
making that decision based on the signature type.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Instead of the overly-simplistic allocator in Zephyr, use the still
simplistic allocator in mbed TLS.
On K64f, this saves 848 bytes of text, 44 bytes of data, and 208 bytes
of bss.
Signed-off-by: David Brown <david.brown@linaro.org>
Upstream Zephyr is making a habit of enabling subsystems on any board
that supports them. That's a potential security risk if any of those
allow interference with the running bootloader, and is currently
exceeding mcuboot's flash allowance on some STM32 targets,
e.g. 96b_carbon. Turn off I2C to restore the build for those.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Recent Zephyr trees require this config option to be set in order to be
able to write to the flash device. Without it, targets with an MPU
enabled will abort during startup, usually before even printing a
message to the UART.
Signed-off-by: David Brown <david.brown@linaro.org>
Avoid clock related interrupts before jumping into the first image. Safe
to disable as the first application will enable the clock/timer again
once booted.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
The bootloader is just using Zephyr as a HAL and doesn't require
thread scheduling. Build Zephyr in single-threaded mode and gain
some footprint savings.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Bluetooth is enabled by default with some boards, so just make sure that
it gets disabled here to avoid having a large bootloader firmware.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Make it generic and let the SoC itself handle the FLASH driver support
as part of the Zephyr build system.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
The Zephyr build systems makes some assumptions about the directory
layout, and encounters problems if the necessary path contains "../..".
To help this, place the zephyr directory next to the bootutil directory
so that the Makefile can just refer to "../bootutil". This keeps all of
the build artifacts under the proper top-level directory.