OrgZephyr/mcuboot
OrgZephyr
/
mcuboot
mirror of https://github.com/zephyrproject-rtos/mcuboot.git
1
0
Fork 0
Code Issues Releases Wiki Activity

doc: zephyr: Extend info about flashing 

Add precisions to the information regarding flashing MCUboot and Zephyr
application images in order to make users aware of mass-erase scenarios
that might bite them.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This commit is contained in:
Carles Cufi 2018-04-03 17:10:18 +02:00
parent 30f6b2a908
commit 5a9688a5ac
1 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/readme-zephyr.md
View File

@ -57,7 +57,10 @@ After building the bootloader, the binaries should reside in
`build/zephyr/zephyr.{bin,hex,elf}`, where `build` is the build `build/zephyr/zephyr.{bin,hex,elf}`, where `build` is the build
directory you chose when running `cmake`. Use the Zephyr build directory you chose when running `cmake`. Use the Zephyr build
system `flash` target to flash these binaries, usually by running system `flash` target to flash these binaries, usually by running
`make flash` (or `ninja flash`, etc.) from the build directory. `make flash` (or `ninja flash`, etc.) from the build directory. Depending
on the target and flash tool used, this might erase the whole of the flash
memory (mass erase) or only the sectors where the boot loader resides prior to
programming the bootloader image itself.
## Building Applications for the bootloader ## Building Applications for the bootloader
@ -96,8 +99,15 @@ these signatures.
### Flashing the application ### Flashing the application
The application itself can flashed with regular flash tools, but will The application itself can flashed with regular flash tools, but will
need to be loaded at the offset of SLOT-0 for this particular target. need to be programmed at the offset of slot-0 for this particular target.
These images can also be marked for upgrade, and loaded into SLOT-1, Depending on the platform and flash tool you might need to manually specify a
flash offset corresponding to the slot-0 starting address. This is usually
not relevant for flash tools that use Intel Hex images (.hex) instead of raw
binary images (.bin) since the former include destination address information.
Additionally you will need to make sure that the flash tool does not perform
a mass erase (erasing the whole of the flash) or else you would be deleting
MCUboot.
These images can also be marked for upgrade, and loaded into slot-1,
at which point the bootloader should perform an upgrade. It is up to at which point the bootloader should perform an upgrade. It is up to
the image to mark slot-0 as "image ok" before the next reboot, the image to mark slot-0 as "image ok" before the next reboot,
otherwise the bootloader will revert the application. otherwise the bootloader will revert the application.