In change
commit bb5635e074
Author: Fabio Utzig <utzig@utzig.org>
Date: Mon Apr 10 09:07:02 2017 -0300
Add test of multiple random resets while upgrading
in addition to adding the try_random_fails, it shuffled the order that
the initial interruption test ran. However, this test always clones
the flash device, so it doesn't matter what order the tests are run.
Revert this part of the change to avoid unnecessary complexity in the
code.
There are some instances of hard-coded offsets, which break if the
simulated device doesn't have the same configuration. Query these
from the flash descriptor rather than hard-coding them.
Although this contains a phantom pointer, because it is passed to C,
this generates a warning on every compile. Until this is fixed,
remove the lifetime declarations from the structures. The user will
have to make sure that the pointed-to structures remain until the C
structure is completed. For the common case of generating the C
structures just to make a call, this should be safe.
This fixes MCUB-39.
On Zephyr targets, flash_area_to_sectors() assumes that the flash
device's sector size is equal to the size of the scratch area.
That breaks swap and rollback when scratch size doesn't divide image
size, since the image flash areas will not be correctly configured.
This is a valid configuration supported by the rest of mcuboot.
The best way to fix this would be to get the flash layout from Zephyr,
but that's not possible yet.
Instead, provide a new FLASH_AREA_IMAGE_SECTOR_SIZE define from
target.h. This must be the sector size for these areas:
- FLASH_AREA_IMAGE_0
- FLASH_AREA_IMAGE_1
- FLASH_AREA_IMAGE_SCRATCH
Other areas on the device may have sizes different than
FLASH_AREA_IMAGE_SECTOR_SIZE.
This won't work on platforms where those areas have nonuniform sector
sizes, but we'll cross that bridge when we come to it. (At that point,
an upstream Zephyr change to the flash API really seems needed.)
Revert to the old/buggy behavior when FLASH_AREA_IMAGE_SECTOR_SIZE
isn't provided, but emit a warning. Additionally, touch up the logging
and error handling while we're here.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The current configuration only allows ~170 updates before we can
expect wear on the flash device (per product spec that the flash
device supports 10,000 erase cycles). Increase the scratch size to
make this better by removing some application space, to allow for
~2500 application updates or rollbacks.
The new configuration is 52 KiB (13 sectors) for scratch, and 208
KiB (52 sectors) for each application image.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
MCUBOOT_TARGET_CONFIG is included in several places now,
not just boot/zephyr/main.c. This seems likely to continue.
Let's avoid trouble and make it a real header file, target.h, that
pulls in MCUBOOT_TARGET_CONFIG. That done, include target.h instead
everywhere MCUBOOT_TARGET_CONFIG is included.
This will make it easier to provide values at an SoC/family level
later. We can expect different Zephyr boards to have the same SoC and
thus likely the same mcuboot flash layout, so this will avoid
duplication.
All supported boards are compile-tested.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The Zephyr log backend already prepends the function, so it's
redundant to do it here.
Also convert a stray SYS_LOG_ERR to BOOT_LOG_ERR().
Signed-off-by: Marti Bolivar <marti.bolivar@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>
We won't need the GPIO, timer, or pinmux drivers for
functioning asa bootloader, and some extra exception
debug info has been disabled.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
arduino_101.conf was moved up a level, but the toplevel Makefile
was not updated so that it can be located.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Commit 7238f51 ("zephyr: add support for x86 booting method")
introduced a backend-specific do_boot() function. On ARM, this casts
to an undefined type 'struct vector_table*'. Fix this by using the
'struct arm_vector_table*' introduced in that patch.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
To build Zephyr as a bootloader will typically require
overriding the default flash regions where the binary lives,
and possibly other board-specific configuration directives.
Look for boot/zephyr/targets/$(BOARD).conf and include it
in the kernel configuration if it exists.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
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>
Previously, the return of boot_swap_sectors() was discarded. If a flash
operation failed, this information was lost.
Now, boot_swap_sectors() returns void. Rather than returning a result,
success is asserted for all flash operations during function execution
(boot_copy_sector() and boot_erase_sector()).
commit d930ec69c8
Author: David Brown <david.brown@linaro.org>
Date: Wed Dec 14 07:59:48 2016 -0700
Validate slot zero before booting
adds a feature to validate slot 0 before booting it. However, there
is an error in the logic, and if the magic number is written to an
invalid value, but not all 0xFF, it will consider any image to be
valid.
Fix this logic so that slot zero is always validated.
Let's stay in-sync automatically with Zephyr master by referring
to CONFIGs for the flash device names.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Fabio Utzig