The additional dependency of the ELFFILE variable on a LD_SCRIPTS variable allows to define rules for the generation of the used ld files from configurable LD templates.
Boards that are shipped with a DFU bootloader define the `dfu-util` configuration in their `Makefile.include`. However, when `riotboot_dfu` is used as the DFU bootloader, the board's `dfu-util` configuration must be overridden by the configuration as required by `riotboot_dfu` to use it to flash applications. Therefore, all `dfu-util` configurations are defined as overridable in the board's `Makefile.include` and the configuration as required by `riotboot_dfu` is included before the board's `Makefile.include`.
JLink presumably has information about the device's RAM available
internally. Not passing the precise symbol area (which would be
available in the ELF file) because a) that'd make the terminal break
when the flashed firmware does not equal the built one, and b) that
would introduce a dependency from `term` to the ELF file that other
terminals don't have.
Let's consider firmwares as identical if their flash files are matching.
This will have the side effect that hash mismatches for ESP32 due to
different .debug sections in the ELFFILE are prevented, as for ESP32
the BINFILE is used.
DEFAULT_MODULEs declared in defaultmodules_regular.inc.mk MAY only be
disabled at APPLICATION level or in BOARD/CPU Makefile.default. These
modules MAY have complex dependencies themselfs.
DEFAULT_MODULEs declared in defaultmodules_no_recursive_deps.inc.mk MAY be disabled
during dependency resolution. The MUST only have dependencies against
modules with no dependencies themselfs, and these dependencies must
be defined in makefiles/defaultmodules._deps.inc.mk
This adds:
* SUIT_MANIFEST_BASENAME: allow for non slotfiles payloads to have
different names that slotfiles payloads.
* SUIT_MANIFEST_PAYLOADS: firmware payloads to be published with the
manifest.
* SUIT_MANIFEST_SLOTFILES: firmware payloads referenced by the manifest
in the form 'filename:[offset]:[comp_name]' as expected by
gen_manifest.py.
With this the same recipes suit/publish suit/notify can be used with
non slotfiles payloads.
- Provide a new tool to list and filter TTYs
- Change `Makefile.include` to use `$(RIOTTOOLS)/usb-serial/ttys.py`
instead of `$(Q)$(RIOTTOOLS)/usb-serial/list-ttys.sh` to implement
`make list-ttys`
- Extend `makefiles/tools/serial.inc.mk` to allow using the most recent
port by passing `MOST_RECENT_PORT=1` as environment variable or
parameter to make
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Using EXTERNAL_MODULE_PATHS works fine when only using Kconfig for
configuratio, but when using it for dependencies this value is not
set since it depends on Kconfig. Instead use EXTERNAL_MODULE_DIRS
and filter matching on Kconfig files.
By default if IoT-LAB Cli Tools V3 is used then BINFILE is used to
flash on IoT-LAB. But BINFILE is not built by default when RIOT_CI_BUILD
is set as a ci optimization.
But since before IOTLAB_NODE was not passed to docker when building it
did not know that it should BUILD BINFILE as well, which led to failures
if doing:
$ IOTLAB_NODE=iotlab-m3.grenoble.iot-lab.info BOARD=iotlab-m3 \
RIOT_CI_BUILD=1 BUILD_IN_DOCKER=1 make -C examples/hello-world/ flash
But if IOTLAB_NODE is passed at is checks for IoT-LAB cli Tools also
happen in the docker container which leads to a make error since those
are not present in docker.
Therefore add BINFILE to BUILD_FILES if RIOT_CI_BUILD is set, but unset
IOTLAB_NODE once INSIDE_DOCKER.
If we
-include Makefile.ci
and `Makefile.ci` does not exist, but we provide `make` with a way
on how to do so, it will try to create `Makefile.ci`.
This is not what we want, but I don't know how to disable this automagic.
So rename the target to `create-Makefile.ci` to avoid the conflict.
The warning about the API change is scheduled to be removed by 2020.10.
Since the release has been branched off, we can now drop the warning
going forward.
If the repository was checked out without tags, parsing RIOT_VERSION
will fail.
Fall back to creating a fake release version code based on the current
year and month.
Redirecting `2>&1 >/dev/null` moves stderr to stdout first and then
stdout to /dev/null; when checking for command existence or otherwise
silencing output, this is usually not desired (but only starts producing
errors when the actual command fails, which is often not tested).
