Added support for STM32F7 + DUALBANK_SWAP hw-assisted support

Author: danielinux

Makefile

@@ -24,6 +24,7 @@ WOLFBOOT_VERSION?=0
 V?=0
 SPMATH?=1
 RAM_CODE?=0
+DUALBANK_SWAP=0
 
 
 
@@ -85,6 +86,10 @@ ifeq ($(RAM_CODE),1)
    CFLAGS+= -DRAM_CODE
 endif
 
+ifeq ($(DUALBANK_SWAP),1)
+   CFLAGS+= -DDUALBANK_SWAP
+endif
+
 ifeq ($(SPI_FLASH),1)
    EXT_FLASH=1
    CFLAGS+= -DSPI_FLASH=1

arch.mk

@@ -30,6 +30,12 @@ ifeq ($(ARCH),ARM)
     CORTEX_M0=1
   endif
 
+  ifeq ($(TARGET),stm32f7)
+    ARCH_FLASH_OFFSET=0x08000000
+  else
+    ARCH_FLASH_OFFSET=0x0
+  endif
+
   ## Cortex-M CPU
   ifeq ($(CORTEX_M0),1)
     CFLAGS+=-mcpu=cortex-m0

docs/Targets.md

@@ -26,7 +26,7 @@ This results in the following partition configuration:
 This configuration demonstrates one of the possible layouts, with the slots
 aligned to the beginning of the physical sector on the flash.
 
-The entry point for all the runnable firmware images on this target will be `0x20100`, 
+The entry point for all the runnable firmware images on this target will be `0x20100`,
 256 Bytes after the beginning of the first flash partition. This is due to the presence
 of the firmware image header at the beginning of the partition, as explained more in details
 in [Firmware image](firmware_image.md)
@@ -114,14 +114,14 @@ For testing wolfBoot here are the changes required:
 1. Makefile arguments:
     * ARCH=RISCV
     * TARGET=hifive1
- 
+
     ```
     make ARCH=RISCV TARGET=hifive1 RAM_CODE=1 clean
     make ARCH=RISCV TARGET=hifive1 RAM_CODE=1
     ```
 
     If using the `riscv64-unknown-elf-` cross compiler you can add `CROSS_COMPILE=riscv64-unknown-elf-` to your `make` or modify `arch.mk` as follows:
-    
+
     ```
      ifeq ($(ARCH),RISCV)
     -  CROSS_COMPILE:=riscv32-unknown-elf-
@@ -172,3 +172,115 @@ riscv64-unknown-elf-gdb wolfboot.elf -ex "set remotetimeout 240" -ex "target ext
 add-symbol-file test-app/image.elf 0x20020100
 ```
 
+
+## STM32-F769
+
+The STM32-F76x and F77x offer dual-bank hardware-assisted swapping.
+The flash geometry must be defined beforehand, and wolfBoot can be compiled to use hardware
+assisted bank-swapping to perform updates.
+
+
+Example 2MB partitioning on STM32-F769:
+
+- Dual-bank configuration
+
+BANK A: 0x08000000 to 0x080FFFFFF (1MB)
+BANK B: 0x08100000 to 0x081FFFFFF (1MB)
+
+- WolfBoot executes from BANK A after reboot (address: 0x08000000)
+- Boot partition @ BANK A + 0x20000 = 0x08020000
+- Update partition @ BANK B + 0x20000 = 0x08120000
+- Application entry point: 0x08020100
+
+```C
+#define WOLFBOOT_SECTOR_SIZE              0x20000
+#define WOLFBOOT_PARTITION_SIZE           0x40000
+
+#define WOLFBOOT_PARTITION_BOOT_ADDRESS   0x08020000
+#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x08120000
+#define WOLFBOOT_PARTITION_SWAP_ADDRESS   0x0   /* Unused, swap is hw-assisted */
+```
+
+### Build Options
+
+To activate the dual-bank hardware-assisted swap feature on STM32F76x/77x, use the
+`DUALBANK_SWAP=1` compile time option. Some code requires to run in RAM during the swapping
+of the images, so the compile-time option `RAMCODE=1` is also required in this case.
+
+Dual-bank STM32F7 build can be built using:
+
+```
+make TARGET=stm32f7 DUALBANK_SWAP=1 RAM_CODE=1
+```
+
+
+### Loading the firmware
+
+To switch between single-bank (1x2MB) and dual-bank (2 x 1MB) mode mapping, this [stm32f7-dualbank-tool](https://github.com/danielinux/stm32f7-dualbank-tool)
+can be used.
+Before starting openocd, switch the flash mode to dualbank (e.g. via `make dualbank` using the dualbank tool).
+
+OpenOCD configuration for flashing/debugging, can be copied into `openocd.cfg` in your working directory:
+
+```
+source [find interface/stlink.cfg]
+source [find board/stm32f7discovery.cfg]
+$_TARGETNAME configure -event reset-init {
+    mmw 0xe0042004 0x7 0x0
+}
+init
+reset
+halt
+```
+
+OpenOCD can be either run in background (to allow remote GDB and monitor terminal connections), or 
+directly from command line, to execute terminal scripts.
+
+If OpenOCD is running, local TCP port 4444 can be used to access an interactive terminal prompt.
+
+Using the following openocd commands, the initial images for wolfBoot and the test application
+are loaded to flash in bank 0:
+
+```
+flash write_image unlock erase wolfboot.bin 0x08000000
+flash verify_bank 0 wolfboot.bin
+flash write_image unlock erase test-app/image_v1_signed.bin 0x08020000
+flash verify_bank 0 test-app/image_v1_signed.bin 0x20000
+reset
+resume 0x0000001
+```
+
+To sign the same application image as new version (2), use the python script `sign.py` provided:
+
+```
+tools/keytools/sign.py test-app/image.bin ed25519.der 2
+```
+
+From OpenOCD, the updated image (version 2) can be flashed to the second bank:
+```
+flash write_image unlock erase test-app/image_v2_signed.bin 0x08120000
+flash verify_bank 0 test-app/image_v1_signed.bin 0x20000
+```
+
+Upon reboot, wolfboot will elect the best candidate (version 2 in this case) and authenticate the image.
+If the accepted candidate image resides on BANK B (like in this case), wolfBoot will perform one bank swap before
+booting.
+
+The bank-swap operation is immediate and a SWAP image is not required  in this case. Fallback mechanism can rely on 
+a second choice (older firmware) in the other bank.
+
+
+### Debugging
+
+Debugging with OpenOCD:
+
+Use the OpenOCD configuration from the previous section to run OpenOCD.
+
+From another console, connect using gdb, e.g.:
+
+```
+arm-none-eabi-gdb
+(gdb) target remote:3333
+```
+
+

docs/compile.md

@@ -136,6 +136,19 @@ both `PART_UPDATE_EXT` and `PART_SWAP_EXT` are defined.
 When external memory is used, the HAL API must be extended to define methods to access the custom memory.
 Refer to the [HAL](HAL.md) page for the description of the `ext_flash_*` API.
 
+### Executing flash access code from RAM
+
+On some platform, flash access code requires to be executed from RAM, to avoid conflict e.g. when writing
+to the same device where wolfBoot is executing, or when changing the configuration of the flash itself.
+
+To move all the code accessing the internal flash for writing, into a section in RAM, use the compile time option
+`RAM_CODE=1` (on some hardware configurations this is required for the bootloader to access the flash for writing).
+
+### Enable Dual-bank hardware-assisted swapping
+
+When supported by the target platform, hardware-assisted dual-bank swapping can be used to perform updates.
+To enable this functionality, use `DUALBANK_SWAP=1`. Currently, only STM32F76x and F77x support this feature.
+
 ### Using Mac OS/X
 
 If you see 0xC3 0xBF (C3BF) repeated in your factory.bin then your OS is using Unicode characters.
@@ -155,3 +168,4 @@ LC_ALL=
 ```
 
 Then run the normal `make` steps.
+