The `dfu-util` command uses `--device $(DFU_USB_ID)`, where `DFU_USB_ID` is derived from `USB_VID` and `USB_PID` to specify the DFU device to use. Without specifying `USB_VID` and `USB_PID` in the make command, `dfu-util` is called with `--device :`, which only works if there is only one DFU device. Also, the STM32 make system forbids the use of `dfu-util` as programmer without setting the variable `DFU_USB_ID`. Therefore, the documentation is changed to use `USB_VID`/`USB_PID` or `DFU_USB_ID` in the make command.
To avoid confusions between `auto_init_ztimer` and `ztimer_auto_init`
rename `ztimer_auto_init` to `ztimer_init`.
This allows for similar handling as `saul_init_devs` and
`auto_init_devs`. Dependencies are therefore done against the USEMODULE
and not DEFAULT_MODULE or checking DISABLE_MODULE. For this, both
`ztimer_init` and `auto_init_ztimer` are added to DEFAULT_MODULE and
both need disabling if the user does not want that module in.
With this, the comment in Kconfig no longer applies.
The IDs are not advertised to dfu-util to allow a smooth transition into
having a VID/PID-identifiable riotboot_dfu.
As allocated on https://pid.codes/1209/7D02/.
- Add FEATURES_REQUIRED_ANY to dependency-debug:
Now `make dependency-debug` by default also stores the contents of
`FEATURES_REQUIRED_ANY`.
- makefiles/features_check.inc.mk: Break long lines
- {tests/minimal,tests/unittests,bootloaders/riotboot}:
Disable auto_init_% in addition to auto_init.
This works around weird behavior due to the USEMODULE being recursively expended
in the first iteration of dependency resolution: Modules added to DEFAULT_MODULE
get automatically added to USEMODULE during the first run, but not for
subsequent. This should be iron out later on.
FLASHFILE is now set to RIOTBOOT_EXTENDED_BIN, changing the meaning of
make all`, `flash`, `flash-only`.
This commits updates the documentation accordingly.
riotboot looks for valid, available slots and compares its
version. The slot with the highest version is booted, otherwise
if no valid slot is found it loops on `while(1);`
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>
