The patch introduce usage of zephyr flas_map module instead
of mcuboot zephyr-only implementation. Unused flash_area_to_sectors
API of former flash_map was removed as well.
Size of sector-status-update-map entry is now defined thanks to the
minimum write size supported by the flash driver.
For avoid ambiguity former zephyr-only files flash_map.c
were renamed to flash_map_extended.c (its code now implements
only addition to this what zephyr flash_map implements).
flash_map.h header include is now warped by flash_map_backedn.h headre
because implementations and include pathes are diferent in Zephyr and Mynewt.
Usage of hal_flash_align() were replaced by usage flash_area_align().
This provide consistency between MyNewt and Zephyr implementation as
this API is available in both RTOSes.
flash_map.h was moved to the simulator c-support files as now missing in
the boot/zephyr subdirectories.
f. boot_scratch_fa_device_id was removed as unused.
f. boot_img_fa_device_id was and expanded the only use of it
(on loader.c).
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
The unit tests depend on a few Mynewt packages (`test/testutil` and
`sys/console/stub`). If there is no repo prefix in the dependency
specifier, newt assumes the package is in the local repo (mcuboot)`.
This commit adds the `@apache-mynewt-core/` prefix to these
dependencies.
Signed-off-by: Christopher Collins <ccollins@apache.org>
Use flash_device_base() in the boot code to compute a real address,
given the offset returned by boot_go().
Provide an implementation on mynewt that preserves existing
behavior. If mynewt needs to support devices with nonzero flash base
addresses, this can be migrated to the core OS.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Similarly, it's confusing whether br_flash_id is a flash device ID or
a flash area ID. Make this unambiguous.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The boot response returns a flash offset, not a flash address. This is
causing confusion and leading to crashes on some platforms which don't
have flash at address 0.
Rename the field to make it more clear what its purpose is; future
patches can start fixing up usages.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Use flash_device_base() in the boot code to compute a real address,
given the offset returned by boot_go().
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Similarly, it's confusing whether br_flash_id is a flash device ID or
a flash area ID. Make this unambiguous.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The boot response returns a flash offset, not a flash address. This is
causing confusion and leading to crashes on some platforms which don't
have flash at address 0.
Rename the field to make it more clear what its purpose is; future
patches can start fixing up usages.
Signed-off-by: Marti Bolivar <marti.bolivar@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.
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
Andrzej Puzdrowski