This command does the same as `help`, but provides a machine readable
JSON rather than a human readable table. It is only provided when the
(pseudo-)module `shell_builtin_cmd_help_json` is used.
- Allow specifying an alternative board filter for the bootloader TTY,
as this will present different vendor, model, and serial than RIOT's
USB implementation.
- Allow specifying the serial. This is useful when multiple CDC ACM
devices are present.
It turns out that the ID mechanics of docker are even more crazy than
realized before: On Linux (x86_64) they use a different SHA256 when
referring to a locally installed image than when referring to the
same image at dockerhub. On Mac OS (Apple Silicon), the use the repo
SHA256 also when referring to the local image.
Instead of increasing the complexity of the current solution even more
by covering both cases, we now use
`docker.io/riot/riotbuild@sha256:<SHA256_OF_DOCKERHUB_IMAGE>` to refer
to a specific docker image, which hopefully works across systems.
Instead of pulling the image explicitly, we now can rely on docker
to do so automatically if the pinned image is not found locally. As
a result, the knob to disable automatic pulling has been dropped.
Fixes https://github.com/RIOT-OS/RIOT/issues/20853
This patch exports the make macro `DEVELHELP`. Without this patch, use
of the macro in the following files does not work when the macro is set
in a makefile (such as in Makefile.local or an application's makefile as
demonstrated in dist/Makefile). Inside these files `DEVELHELP` is not
defined under these conditions.
- pkg/littlefs/Makefile
- pkg/littlefs2/Makefile
- sys/stdio_null/Makefile
Note that use of the macro does work in these files when the macro is
set from the command line, without the patch. For example:
``` sh
$make DEVELHELP=1 all
```
This implements the `shield_llcc68` module that allows using the LLCC68
LoRa shield on Arduino UNO compatible boards (with Arduino IO mappings
provided by the board) by just selecting the module.
We don't enable this on any other architecture.
-pedantic doesn't give us any more beneficial wanrings, only warns
about language extensions that are implemented by both GCC and Clang
anyway.
Since those are the only compilers we are targeting, we can just make
use of them to make our lives easier.
Specifying the password of the SUIT private key on the command line
and thereby committing it to shell history is a security issue.
Instead ask for the password interactively when an encrypted private
key is used.
This makes it easier to work with encrypted keys and multiple keys.
The firmware binary can contain multiple public keys that are used
to verify the manifest.
The use case is that we want to include the production public key
in the debug build, so we can seamlessly update to the production
version without re-flashing the device.
If the public keys is always generated on the fly, this would still
require the production key password even for the debug build.
Instead if we store the (unencrypted) public key, we can always
include it in the debug build.
The assumption that every MCU has this feature turned out wrong. Hence,
add a feature to allow testing for support of edge triggered IRQs on
both flanks.
We had a number of issues being reported that in the end were caused
by building with a version of riotbuild incompatible with the source,
because CI and source were updated in lock-step but users forgot to
run `docker pull` to update theirs.
In addition, checking out a random old release/commit will likely fail,
as older source may contain bugs that did not trigger with older
toolchains. To reliably succeed at building, a matching version of
riotbuild needs to be used for `BUILD_IN_DOCKER=1`.
This just pins the version of riotbuild manually, so it needs to be
updated by hand in lock step with updating the docker container.
In addition, the latest image is pulled automatically on mismatch.
Ideally, this would pull the tagged image. But that fails for unknown
reason when using the documented command for this with both docker and
podman with:
manifest for riot/riotbuild@sha256:f5951bc41dfface6cac869181d703e62cbdd3b7976b0946130a38f2e658000b3 not found: manifest unknown: manifest unknown
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
The `ethernet` feature has not yet been used, so renaming it should not
cause any issue.
The goal is to eventually have a number of `netif_<type>` features that
would allow filtering boards by the time of connectivity the have.
This gets rid of a long list of boards with network interfaces and
instead let's boards (or MCUs with peripheral network interfaces)
provide the netif feature.
The apps that before used the long list are not depending on the
feature instead (in case of the default example, this is an
optional dependency).
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: mewen.berthelot <mewen.berthelot@orange.com>
