Move the board specific configurations into its own header file, which
can now be created per board, once it gets tested and validated by the
bootloader.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
This reverts commit 920fc16b89.
The boot loader records its current state in the form of a pair of image
trailers, each located at the end of the corresponding image slot. If
an image is so big that it extends into the trailer space of a slot, the
boot loader would read the end of the image and interpet it as the start
of a trailer. The fix was to determine the size of each image upfront
by reading their headers, and only attempt to read an image's trailer if
the image is small enough that it doesn't extend into the trailer space.
If an image is too big to allow for a trailer, the boot loader fails
over to its "rescue mode": just boot into whatever is in slot 0.
The problem arises when the boot loader reads the image headers. There
are certain points during a swap when an image header is not in the
expected location. That is, if the device reboots at the wrong time
during an image swap, the boot loader will fail to read the image
headers when it comes up.
The image sectors are swapped in reverse order. When a swap is
performed, the final sectors of each slot are swapped first, and the
first sectors (containing the image headers) get swapped last. During
the final swap operation, there are two points at which the image
headers are not in the expected place:
1. slot 1 erased; header 1 in scratch area.
2. slot 0 erased; header 0 in scratch area.
In each case, the image header is not actually missing. Rather, the
boot loader is just looking in the wrong place. It should be looking in
the scratch area, not the start of the image slot.
The fix is to revert the original commit. Now, the boot loader won't
fail when an image header read fails. It is the user's responsibility
to ensure an image isn't too big.
Rather than commit our specific mbedtls config file into the Zephyr
tree, include it here, and add a path early in the make process so that
it will get picked up when building the library.
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.
Use the Rust logging so that normal messaging isn't overwhelmed by
messages printed. The default level is 'error' which will only print
full errors (including the failures at the end).
To run with warnings:
RUST_LOG=warn ./target/release/bootsim ...
This will print warnings, showing the particular failures in mind.
Using 'info' instead of 'warn' will print lots of progress as it runs.
'sim' is a small simulator for the bootloader's update code. It tests
untimely powerdowns to ensure that the bootloader will recover from a
power loss or reset at any time during the boot.
Note that, as of this commit, there are some failures in the test that
need to be investigated.
Also note that this build script does not output proper dependencies for
source files outside of the simulator directory, and won't rebuild the C
files if they or headers are modified.
The Zephyr build system does strange things if it refers to source
directories above the main Makefile (generating
outdir/<target>/../boot/... paths). For now, fix this by moving the
Zephyr Makefile to the top-level in the tree. This shouldn't have much
impact on Mynewt, as it doesn't use makefiles.
Add support for building mcuboot as a Zephyr application. This is
copied from the iotboot repo with some minor reorganization to work with
the mcuboot directory layout.
The previous commit for this ticket left the code in a working state.
However, it was not possible for image management to distinguish between
the test and permanent states.
Now, these two states are indicated by the addition of a new swap type:
BOOT_SWAP_TYPE_PERMANENT.
Currently, to permanently run the alternate image, the boot loader
requires the following sequence:
1. image test <slot-01-hash>
2. reboot
3. image confirm
The new feature is to remove the need for the third step. The user
should be able to permanently switch images with this sequence:
1. image confirm <slot-01-hash>
2. reboot
Ricardo Salveti