Remove this workaround. The Kinetis flash driver has supported
FLASH_PAGE_LAYOUT since at least January 2018.
Signed-off-by: David Brown <david.brown@linaro.org>
The flash driver name was changed upstream during the v1.11
development cycle. Remove a shim which kept the old name around in the
Zephyr port now that v1.11 is out.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Zephyr now has proper page layout APIs in its flash driver. Use these
to implement flash_area_get_sectors() and flash_area_to_sectors() when
they are available. Leave the existing implementation behind as a
"legacy" version, for flash drivers which lack page layout support.
This lets us obtain all the target support we need for nRF and STM32
targets entirely from the operating system.
There are two cases where OS-level support is still not enough:
- NXP K6x targets still need an SoC family header, because their flash
driver does not yet support CONFIG_FLASH_PAGE_LAYOUT.
- The arduino_101 target needs partition and flash alignment
definitions in its DTS, and a flash driver with page layout support
as well, so its board-specific header must remain for now.
Fixing these is left to future work. Once that is done,
boot/zephyr/targets/ can be removed completely.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Zephyr now provides defines for FLASH_DRIVER_NAME and
FLASH_WRITE_BLOCK_SIZE (which is what we call FLASH_ALIGN) in
the SoC headers for most targets supported by mcuboot. Use that
information when it's available, falling back on MCUBOOT_TARGET_CONFIG
otherwise.
The soc_family_foo.h files remain for FLASH_AREA_IMAGE_SECTOR_SIZE. A
subsequent patch can remove these files when the relevant SoC flash
driver provides a page layout.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This cleanup commit requires a bit more target-specific knowledge
that's a bit harder to read than board-specific headers, but it's
still an improvement over what we have now.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
All of the information we need is in DTS or is the same across all
boards in the SoC family. There's no need for board-specific headers
for these targets.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Add the 2 official Nordic Development Kit targets that are missing from
the list in mcuboot, but supported in Zephyr.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Adds a new zephyr target for the nrf52_blenano2. This is the BLE
Nano 2 board created by Red Bear which contains a NRF52832 MCU.
Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
The hexiwear k64 is very similar to the frdm_k64, as far as mcuboot is
concerned. The partitions are now defined in DTS in Zephyr, and this
target file just needs the device name, sector size, and alignment.
Signed-off-by: David Brown <david.brown@linaro.org>
Now that the partition table has been added to the device tree for the
frdm_k64f in upstream Zephyr, these symbols become redundant defines.
Remove them to fully use the partitions defined in Zephyr.
Signed-off-by: David Brown <david.brown@linaro.org>
Expand the data slots to 384K each, leaving the boot and scratch areas
as 128K. This allows more room for code, but will wear the scratch
partition about 3x faster because of the more extensive use of the
partition.
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>
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>
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>
David Brown