|
| 1 | +# Targets |
| 2 | + |
| 3 | +## SiFive HiFive1 RISC-V |
| 4 | + |
| 5 | +### Features |
| 6 | +* E31 RISC-V 320MHz 32-bit processor |
| 7 | +* Onboard 16KB scratchpad RAM |
| 8 | +* External 4MB QSPI Flash |
| 9 | + |
| 10 | +### Default Linker Settings |
| 11 | +* FLASH: Address 0x20000000, Len 0x6a120 (424 KB) |
| 12 | +* RAM: Address 0x80000000, Len 0x4000 (16 KB) |
| 13 | + |
| 14 | +### Stock bootloader |
| 15 | +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. |
| 16 | + |
| 17 | +### Application Code |
| 18 | +Start Address: 0x20010000 |
| 19 | + |
| 20 | +### wolfBoot configuration |
| 21 | + |
| 22 | +The default wolfBoot configuration will add a second stage bootloader, leaving the stock "double tap" bootloader for safety. |
| 23 | + |
| 24 | +For testing wolfBoot here are the changes required: |
| 25 | + |
| 26 | +1. Makefile arguments: |
| 27 | + * ARCH?=RISCV |
| 28 | + * TARGET?=hifive1 |
| 29 | + |
| 30 | + ``` |
| 31 | + make ARCH=RISCV TARGET=hifive1 clean |
| 32 | + make ARCH=RISCV TARGET=hifive1 |
| 33 | + ``` |
| 34 | + |
| 35 | + 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: |
| 36 | + |
| 37 | + ``` |
| 38 | + ifeq ($(ARCH),RISCV) |
| 39 | + - CROSS_COMPILE:=riscv32-unknown-elf- |
| 40 | + + CROSS_COMPILE:=riscv64-unknown-elf- |
| 41 | + ``` |
| 42 | + |
| 43 | + |
| 44 | +2. `include/target.h` |
| 45 | + |
| 46 | +Bootloader Size: 0x10000 (64KB) |
| 47 | + |
| 48 | +```c |
| 49 | +#define WOLFBOOT_SECTOR_SIZE 0x10000 |
| 50 | +#define WOLFBOOT_PARTITION_BOOT_ADDRESS 0x20010000 |
| 51 | +``` |
| 52 | + |
| 53 | +Application Size 0x40000 (256KB) |
| 54 | + |
| 55 | +```c |
| 56 | +#define WOLFBOOT_PARTITION_SIZE 0x40000 |
| 57 | +#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x20020000 |
| 58 | +#define WOLFBOOT_PARTITION_SWAP_ADDRESS 0x20060000 |
| 59 | +``` |
| 60 | + |
| 61 | +## STM32-F407 |
| 62 | + |
| 63 | +Example 512KB partitioning on STM32-F407 |
| 64 | + |
| 65 | +The example firmware provided in the `test-app` is configured to boot from the primary partition |
| 66 | +starting at address 0x20000. The flash layout is provided by the default example using the following |
| 67 | +configuration in `target.h`: |
| 68 | + |
| 69 | +```C |
| 70 | +#define WOLFBOOT_SECTOR_SIZE 0x20000 |
| 71 | +#define WOLFBOOT_PARTITION_SIZE 0x20000 |
| 72 | + |
| 73 | +#define WOLFBOOT_PARTITION_BOOT_ADDRESS 0x20000 |
| 74 | +#define WOLFBOOT_PARTITION_UPDATE_ADDRESS 0x40000 |
| 75 | +#define WOLFBOOT_PARTITION_SWAP_ADDRESS 0x60000 |
| 76 | +``` |
| 77 | +
|
| 78 | +This results in the following partition configuration: |
| 79 | +
|
| 80 | + |
| 81 | +
|
| 82 | +This configuration demonstrates one of the possible layouts, with the slots |
| 83 | +aligned to the beginning of the physical sector on the flash. |
| 84 | +
|
| 85 | +The entry point for all the runnable firmware images on this target will be `0x20100`, |
| 86 | +256 Bytes after the beginning of the first flash partition. This is due to the presence |
| 87 | +of the firmware image header at the beginning of the partition, as explained more in details |
| 88 | +in [Firmware image](firmware_image.md) |
| 89 | +
|
| 90 | +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. |
| 91 | +
|
| 92 | +On other systems, the SWAP space can be as small as 512B, if multiple smaller flash blocks are used. |
| 93 | +
|
| 94 | +More information about the geometry of the flash and in-application programming (IAP) can be found in the manufacturer manual of each target device. |
0 commit comments