6.2 KiB
Targets
STM32-F407
Example 512KB partitioning on STM32-F407
The example firmware provided in the test-app
is configured to boot from the primary partition
starting at address 0x20000. The flash layout is provided by the default example using the following
configuration in target.h
:
#define WOLFBOOT_SECTOR_SIZE 0x20000
#define WOLFBOOT_PARTITION_SIZE 0x20000
#define WOLFBOOT_PARTITION_BOOT_ADDRESS 0x20000
#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x40000
#define WOLFBOOT_PARTITION_SWAP_ADDRESS 0x60000
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
,
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
In this particular case, due to the flash geometry, the swap space must be as big as 64KB, to account for proper sector swapping between the two images.
On other systems, the SWAP space can be as small as 512B, if multiple smaller flash blocks are used.
More information about the geometry of the flash and in-application programming (IAP) can be found in the manufacturer manual of each target device.
STM32L0x3
Example 192KB partitioning on STM32-L073
This device is capable of erasing single flash pages (256B each).
However, we choose to use a logic sector size of 4KB for the swaps, to limit the amount of writes to the swap partition.
The proposed geometry in this example target.h
uses 32KB for wolfBoot, and two
partitions of 64KB each, leaving room for up to 8KB to use for swap (4K are being used here).
#define WOLFBOOT_SECTOR_SIZE 0x1000 /* 4 KB */
#define WOLFBOOT_PARTITION_BOOT_ADDRESS 0x8000
#define WOLFBOOT_PARTITION_SIZE 0x10000 /* 64 KB */
#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x18000
#define WOLFBOOT_PARTITION_SWAP_ADDRESS 0x28000
Building
Use make TARGET=stm32l0
. The option CORTEX_M0
is automatically selected for this target.
Known issues
With Ed25519 (default SIGN algorithm) it's not possible at the moment to compile wolfboot
with optimizations, due to a GCC linker error complaining about a missing symbol __gnu_thumb1_case_uqi
.
Possible workarounds:
- Compile ed25519 with debug (optimizations are disabled) :
make TARGET=stm32l0 DEBUG=1
- Use ECDSA instead (which is much faster) :
make TARGET=stm32l0 SIGN=ECC256
STM32G0x0/STM32G0x1
Example 128KB partitioning on STM32-G070:
- Sector size: 2KB
- Wolfboot partition size: 32KB
- Application partition size: 45 KB
#define WOLFBOOT_SECTOR_SIZE 0x800 /* 2 KB */
#define WOLFBOOT_PARTITION_BOOT_ADDRESS 0x8000
#define WOLFBOOT_PARTITION_SIZE 0xB000 /* 45 KB */
#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x13000
#define WOLFBOOT_PARTITION_SWAP_ADDRESS 0x1E000
Building
Use make TARGET=stm32l0
. The option CORTEX_M0
is automatically selected for this target.
The option NVM_FLASH_WRITEONCE=1
is mandatory on this target, since the IAP driver does not support
multiple writes after each erase operation.
Compile with:
make TARGET=stm32g0 NVM_FLASH_WRITEONCE=1
Known issues
With Ed25519 (default SIGN algorithm) it's not possible at the moment to compile wolfboot
with optimizations, due to a GCC linker error complaining about a missing symbol __gnu_thumb1_case_uqi
.
Possible workarounds:
- Compile ed25519 with debug (optimizations are disabled) :
make TARGET=stm32l0 DEBUG=1
- Use ECDSA instead (which is much faster) :
make TARGET=stm32l0 SIGN=ECC256
SiFive HiFive1 RISC-V
Features
- E31 RISC-V 320MHz 32-bit processor
- Onboard 16KB scratchpad RAM
- External 4MB QSPI Flash
Default Linker Settings
- FLASH: Address 0x20000000, Len 0x6a120 (424 KB)
- RAM: Address 0x80000000, Len 0x4000 (16 KB)
Stock bootloader
Start Address: 0x20000000 is 64KB. Provides a "double tap" reset feature to halt boot and allow debugger to attach for reprogramming. Press reset button, when green light comes on press reset button again, then board will flash red.
Application Code
Start Address: 0x20010000
wolfBoot configuration
The default wolfBoot configuration will add a second stage bootloader, leaving the stock "double tap" bootloader as a fallback for recovery. Your production implementation should replace this and partition addresses in target.h
will need updated, so they are 0x10000
less.
For testing wolfBoot here are the changes required:
-
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 addCROSS_COMPILE=riscv64-unknown-elf-
to yourmake
or modifyarch.mk
as follows:ifeq ($(ARCH),RISCV) - CROSS_COMPILE:=riscv32-unknown-elf- + CROSS_COMPILE:=riscv64-unknown-elf-
-
include/target.h
Bootloader Size: 0x10000 (64KB) Application Size 0x40000 (256KB) Swap Sector Size: 0x1000 (4KB)
#define WOLFBOOT_SECTOR_SIZE 0x1000
#define WOLFBOOT_PARTITION_BOOT_ADDRESS 0x20020000
#define WOLFBOOT_PARTITION_SIZE 0x40000
#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x20060000
#define WOLFBOOT_PARTITION_SWAP_ADDRESS 0x200A0000
Build Options
- To use ECC instead of ED25519 use make argument
SIGN=ECC256
- To output wolfboot as hex for loading with JLink use make argument
wolfboot.hex
Loading
Loading with JLink:
JLinkExe -device FE310 -if JTAG -speed 4000 -jtagconf -1,-1 -autoconnect 1
loadbin factory.bin 0x20010000
rnh
Debugging
Debugging with JLink:
In one terminal:
JLinkGDBServer -device FE310 -port 3333
In another terminal:
riscv64-unknown-elf-gdb wolfboot.elf -ex "set remotetimeout 240" -ex "target extended-remote localhost:3333"
add-symbol-file test-app/image.elf 0x20020100
riscv64-unknown-elf-objdump -D test-app/image.elf