The dlcache script is useful to avoid unnecessary repeated downloads
of zip archives, similar to the git-cache scripts. The command order
was changed to stay compatible with DOWNLOAD_TO_FILE and the only other
usage of $(DLCACHE) was changed accordingly.
To avoid the risk of collisions, dlcache now uses SHA512 sums instead
of MD5.
If no SHA512 checksum is given to dlcache.sh, it will just act as
$(DOWNLOAD_TO_FILE).
When building for native with `BUILD_IN_DOCKER=1`, the created elf file
may not be compatible with the host system if:
- The container used is using glibc and the host system is using another
C lib
- Both container and host are using glibc, but the container is using
a more recent one than the host
To avoid these issues, this commit changes behavior to just run the `test`
goal inside the docker image as well when the board is `native%`.
When `OPENOCD_DEBUG_ADAPTER` was set to `stlink`, no `openocd.cfg`
was needed for most STM32 boards. (But one could still be provided if
special handling was needed.) However, for any other debug adapter this
was not the case.
This moves the handling for when no custom `openocd.cfg` is provided from
the `stlink.inc.mk` to `openocd.inc.mk`, so that most boards now work
out of the box with other debuggers.
Co-authored-by: crasbe <crasbe@gmail.com>
This avoids inconsistent output when external code gets linked in that
directly links against newlib's assert implementation (e.g. binary blobs
or packages that do not add `core/lib/include` to the include paths).
This also greatly benefits wrapping printf, as newlib's `__assert_func()`
directly links to internal printf functions of newlib.
Co-authored-by: crasbe <crasbe@gmail.com>
This makes use of the new bug modeling to declare all platforms that
can use newlib and have no reentrancy hooks as affected by the
non-thread-safe stdio bug. (Which is every platform but ESP* and AVR,
the former because the reentrancy hooks are provided, the latter because
we do not and never will support newlib on them.)
Building on that, the mpaland-printf package is used when newlib is
used and the bug is present. This way we can rely on the stdio being
thread-safe on every platform and not causing random crashes at run
time.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
If we only have access the the public key, we don't want it to be
accidentally overwritten by the build system.
Intrudce a new `SUIT_GEN_PUBKEY` that defaults to 1, but can be set
to 0 to disable auto-generating the public key from the private key
(and generating a new private/public key pair if the private key does
not exist).
The cleanup includes the following changes:
- The `esptool.py` is no longer installed as a RIOT package, but as a pure Python package, as published by Espressif. The installation takes place in a virtual Python environment in the `dist/tools/esptools/venv` directory.
- The installation of the `esptool.py` is now version-sensitive.
- The `esptool.py` from the Python package is always used.
- The option for users to use a custom `esptool.py` has been removed because newer versions of `esptool.py` use renamed options that are not compatible with older versions of `esptool.py`. Using a custom `esptool.py` therefore makes no sense.
It makes no sense to have a separate `esp_ble_$(CPU_FAM)` feature for each ESP32x variant. The ESP32x has either a BLE controller or not. Therefore, a single common `esp_ble` feature is sufficient.
`esptool.py` is now used as a package within a virtual Python environment. Since `esptool.py` is used for compilation on the one hand and for flashing on the other, `esptool.py` is installed in two separate virtual Python environments, one for compilation and one for flashing only. This is required
1. to be able to flash a precompiled application only without compiling the package and
2. to be able to compile an application in RIOT Docker and flash it on the host system.
This adds a default `TTY_BOARD_FILTER` for use with the Tigard debugger,
so that when the programmer is a Tigard that tigard is also used by
default for the serial connection.
In addition, this allows selecting the TTY via the programmer serial
number.
Co-authored-by: crasbe <crasbe@gmail.com>
