The tests overrides the target all to be tested by the CI.
All the instructions how to use it are in README.md
The test is successful if the image boots and displays
information about the image and running slot.
Co-authored-by: Federico Pellegrin <fede@evolware.org>
Currently only tested boards provide the feature riotboot.
Potentially all boards embeding a cortex-m0+/3/4/7 are
able to have riotboot as a feature, but other dependencies
need to be met, e.g. usage of cortexm.ld linker script,
double initialisation of cpu_init(), etc. See doc in
bootloaders/riotboot.
RIOTBOOT_SLOT_LEN is calculated as an hexadecimal value and
handles ROM_LEN defined as kilobytes like '512K'
This enables support for all the cortex-m0+/3/4/7 arch,
so most boards embedding these are potentially supported.
One needs just to ensure that the CPU can be initialised
at least twice.
Co-authored-by: Gaëtan Harter <gaetan.harter@fu-berlin.de>
This new function allows to jump to another execution
environment (VTOR) located at a certain (aligned) address.
It's used to boot firmwares at another location than
`CPU_FLASH_BASE`.
The user needs to ensure that the CPU using this feature
is able to be initialised at least twice while jumping
to the RIOT `reset_handler_default` function, since it
initialises the CPU again (calls cpu_init()).
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
riotboot is introduced here and makes use of riotboot_hdr,
which indentifies the images encapsulated as slots.
The slot size and offset is configurable, which makes
slots extendable if needed, e.g. 2 or more slots can be
transparently added.
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Co-authored-by: Gaëtan Harter <gaetan.harter@fu-berlin.de>
In order to use the RIOT bootloader (riotboot) a header needs to
be created and placed before the firmware. This tool generates
such a header with the expected information by the bootloader.
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
When flash-only was introduced (in #8373), the `flash` rule was
made conditionally dependent on `all` by looking for `flash-only`
in MAKECMDGOALS. This was done to avoid code duplication.
There's a cleaner way, by using canned recipes. When we upgrade the
requirements to gnu make 4, the flash recipe can be defined as ?=.
This commit fixes configuration problems when trying to use i2c pins that need to be remapped.
All B8 and B9 pins for STM32F1 need to be remapped, so a check is done if the remappable pins are selected.
