Update the list of target triples to match
`makefiles/arch/riscv.inc.mk`. This fixes compilation with toolchains
other than the obsolete toolchain that uses the incorrect
`riscv-none-embed` triple.
19030: tests/periph_timer_short_relative_set: improve test r=benpicco a=maribu
### Contribution description
Reduce the number lines to output by only testing for intervals 0..15 to speed up the test.
In addition, run each test case 128 repetitions (it is still faster than before) to give some confidence the short relative set actually succeeded.
### Testing procedure
The test application should consistently fail or succeed, rather than occasionally passing.
### Issues/PRs references
None
19085: makefiles/tests/tests.inc.mk: fix test/available target r=benpicco a=maribu
### Contribution description
`dist/tools/compile_and_test_for_board/compile_and_test_for_board.py` relies on `make test/available` to check if a test if available. However, this so far did not take `TEST_ON_CI_BLACKLIST` and `TEST_ON_CI_WHITELIST` into account, resulting in tests being executed for boards which they are not available. This should fix the issue.
### Testing procedure
#### Expected to fail
```
$ make BOARD=nrf52840dk -C tests/gcoap_fileserver test/available
$ make BOARD=microbit -C tests/log_color test/available
```
(On `master`, they succeed, but fail in this PR.)
#### Expected to succeed
```
$ make BOARD=native -C tests/gcoap_fileserver test/available
$ make BOARD=nrf52840dk -C tests/pkg_edhoc_c test/available
$ make BOARD=nrf52840dk -C tests/log_color test/available
```
(Succeed in both `master` and this PR.)
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
dist/tools/compile_and_test_for_board/compile_and_test_for_board.py
relies on `make test/available` to check if a test if available.
However, this so far did not take `TEST_ON_CI_BLACKLIST` and
`TEST_ON_CI_WHITELIST` into account, resulting in tests being executed
for boards which they are not available. This should fix the issue.
19074: cpu/esp8266: build the SDK bootloader from source r=benpicco a=gschorcht
### Contribution description
This PR is a takeover of PR #17043, which is rebased to the current master and includes some corrections that became necessary after rebasing.
**Copied from description of PR #17043:**
We had four versions of pre-built bootloaders for the esp8266 with different settings of logging and color logging. These bootloaders were manually built from the SDK and shipped with RIOT-OS source code. However there are more settings that affect the bootloader build that are relevant to the app or final board that uses this bootloader. In particular, flash size and flash speed is important for the bootloader to be able to load an app from a large partition table at the fastest speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the bootloader. The boot ROM will normally start at a baud rate of 74880 (depending on the crystal installed), so it might make sense to keep the UART output at the same speed so we can debug boot modes and bootloader with the same terminal.
This patch builds the `bootloader.bin` file from the ESP8266 SDK source code. The code is built as a module (`esp8266_bootloader`) which at the moment doesn't generate any object code for the application and only produces a `bootloader.bin` file set to the `BOOTLOADER_BIN` make variable for the `esptool.inc.mk` to flash.
The code needs to be compiled and linked with custom rules defined in the module's Makefile since the `bootloader.bin` is its own separate application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the `$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier for applications or board to provide their own bootloader binary if needed.
As a result of building the bootloader from source we fixed the issue of having a large partition table.
### Testing procedure
Use following command to flash the application with STDIO UART baudrate of 115200 baud.
```
BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
Connect with a terminal programm of your choice (unfortunatly `picocom` and `socat` don't support a baudrate close to 74880), for example:
```
python -m serial.tools.miniterm /dev/ttyUSB0 74880
```
On reset, the `esp8266-esp-12x` node shows the ROM bootloader log output
```
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 6152, room 16
tail 8
chksum 0x6f
load 0x3ffe8008, len 24, room 0
tail 8
chksum 0x86
load 0x3ffe8020, len 3408, room 0
tail 0
chksum 0x79
```
as well as the second-stage bootloader built by this PR (`ESP-IDF v3.1-51-g913a06a9ac3`) at 74880 baudrate.
```
I (42) boot: ESP-IDF v3.1-51-g913a06a9ac3 2nd stage bootloader
I (42) boot: compile time 11:25:03
I (42) boot: SPI Speed : 26.7MHz
...
I (151) boot: Loaded app from partition at offset 0x10000
```
The application output is seen as garbage since the `esp8266-esp-12x` uses 115200 as baurate by default.
To see all output at a baudrate of 74880 baud, you can use the following command:
```
CFLAGS='-DSTDIO_UART_BAUDRATE=74880' BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
If the application is built without options, the ROOM bootloader output will be 74880 baud and the second stage bootloader and application output will be 115200 baud.
### Issues/PRs references
Fixes issue #16402
Co-authored-by: iosabi <iosabi@protonmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
We had four versions of pre-built bootloaders for the esp8266 with
different settings of logging and color logging. These bootloaders were
manually built from the SDK and shipped with RIOT-OS source code.
However there are more settings that affect the bootloader build that
are relevant to the app or final board that uses this bootloader. In
particular, flash size and flash speed is important for the bootloader
to be able to load an app from a large partition table at the fastest
speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the
bootloader. The boot ROM will normally start at a baud rate of 74880
(depending on the crystal installed), so it might make sense to keep
the UART output at the same speed so we can debug boot modes and
bootloader with the same terminal.
This patch builds the bootloader.bin file from the ESP8266 SDK source
code. The code is built as a module (esp8266_bootloader) which at the
moment doesn't generate any object code for the application and only
produces a bootloader.bin file set to the BOOTLOADER_BIN make variable
for the esptool.inc.mk to flash.
The code needs to be compiled and linked with custom rules defined in
the module's Makefile since the bootloader.bin is its own separate
application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the
`$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier
for applications or board to provide their own bootloader binary if
needed.
As a result of building the bootloader from source we fixed the issue of
having a large partition table. Fixes#16402.
Allow overriding the shell command used to auto-detect the TTY of a
board with `MOST_RECENT_PORT=1` via the `TTY_SELECT_CMD` variable.
The use case is to also detect Arduino Mega 2560 clones with cheap
USB UART bridges (for which the filter command may yield false
positives) while preferring genuine Arduino Mega 2560 boards (if
found) over the clones (as the filter for genuine boards does not yield
false positives).
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`.
When trying to compile `examples/hello-world` on my 465 MHz Mendocino
I got
/home/benpicco/dev/RIOT/makefiles/toolchain/gnu.inc.mk:29: extraneous text after 'ifneq' directive
Turns out the version of `make` on Archlinux32 is newer than that in
Ubuntu 22.04, which somehow ignored the extra parenthesis.
Turns out this (t)rusty old machine is still good for writing patches :D
Hooking into the existing wrappers for `malloc()`, `calloc()`,
`realloc()`, and `free()`, the new (pseudo) module `malloc_tracing`
prints out the calls to the given functions, the program counter of
the caller, as well as the return result.
The intent is to aid debugging double-frees, invalid frees, or memory
leaks.
Modern binutils complain about segments with RWX permissions. While
this is indeed a bad habit, RIOT ignores segments permissions anyway.
(We do have a `mpu_noexec_ram` module to disable execution of all of
RAM, which would do so regardless of the segment permission.) So for
now, we can safely just disable the warning.
This fixes:
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: warning: /home/maribu/Repos/software/RIOT/examples/default/bin/nucleo-f767zi/default.elf has a LOAD segment with RWX permissions
collect2: error: ld returned 1 exit status
The test for the requirement of disabling wchar_t size warnings assumed
that $(CC) is used for linking, instead of $(LINK). With GCC $(LINK)
and $(CC) happen to be (in most cases) identical, but with LLVM they
are not. This results in issues with compiling with LLVM.
GCC on some platforms does need an executable stack to generate
trampoline code, but use of nested functions is not allowed in
RIOT's code base anyway.
This allows including C headers from C++. It sadly reduced the
diagnostics on C++ code as well, were there warning may make sense as
unintended side effect. We may be able to drop that later on, when more
C APIs are properly wrapped in native C++ APIs, so that C headers do no
longer need to be compatible with C++ compilers.
In an ideal world everyone would just install `gdb-multiarch` and be
happy. However, some MCUs need magic GDB versions sprinkled with
unicorn-stardust-Espressif-patches...
Since there is little reason to have `$(target)-gdb` installed in
addition to `gdb-multiarch` if `gdb-multiarch` would work fine, let's
assume the user wants to use `$(target)-gdb` when present over
`gdb-multiarch`.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Add USE_MODULE += "stdio_uart_onlcr" to enable it.
This is named after the "onlcr" stty flag, which does the same thing.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Model the LoRaWAN integration to GNRC's netif command (ifconfig) as
submodule of it, namely `shell_cmd_gnrc_netif_lorawan`.
This should fix a regression introduced by
https://github.com/RIOT-OS/RIOT/pull/18355
When using podman instead of docker the registry is not set by default.
Docker has a builtin registry default "docker.io". Podman does not have a
default. By specifying the registry explicitly both tools can be used.
With RISC-V being a relatively young toolchain, a lot of inconsistencies
between different toolchains are to be found that differ in the target
triple and the flags supported. This build system performs run-time
tests to detect the toolchain and supported flags.
With `BUILD_IN_DOCKER=1` issues arise, as this checks are performed
outside of the docker container. However, the host may have no RISC-V
toolchain installed or a different toolchain, so there is little reason
in performing this detection then. Instead, a hard coded target triple
and supported flags are provided when using `BUILD_IN_DOCKER=1`.
If `AVRDUDE_PROGRAMMER` is already set to a programmer that is also
capable of debugging, we can assume that typically the user will want
to use the same hardware for debugging. Thus, let `AVR_DEBUGDEVICE`
default to the matching hardware.
`tiny_strerror()` is a drop-in replacement for `strerror()`, but
instead of a long help message it returns the much shorter macro name
matching the given number.
The (pseudo-)module `tiny_strerror_as_strerror` can be used to
replace all calls to `strerror()` with calls to `tiny_strerror()`.
Previously `shell_commands` was a "catch-all" module that included
shell commands for each and every used module that has a shell
companion. Instead, the new `shell_cmds` module is now used to provide
shell commands as individually selectable submodules, e.g.
`cmd_gnrc_icmpv6_echo` now provides the ICMPv6 echo command (a.k.a.
ping).
To still have a "catch all" module to pull in shell commands of modules
already used, `shell_cmds_default` was introduced. `shell_commands`
depends now on `shell_cmds_default` for backward compatibility, but
has been deprecated. New apps should use `shell_cmds_default`
instead.
For a handful of shell commands individual selection was already
possible. Those modules now depend on the corresponding `cmd_%` module
and they have been deprecated.
Add tracing support via GPIOs to trace the basic state of the Ethernet
peripheral. The following signals are provided:
- One GPIO pin is toggled on entry of the Ethernet ISR
- On TX start an GPIO is set, on TX completion it is cleared
- On RX complete an GPIO is set, once this is passed to the upper layer
the GPIO is cleared again
In order to reduce the overhead, GPIO LL is used. By default the
on-board LEDs are used as tracing GPIOs. This makes it easy to debug
when the state machine gets stuck without the need to attach a scope or
logic analyzer.
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.
When `stdio_cdc_acm` is used, assume `"RIOT-os\.org"` as vendor string
and `$(BOARD)` being used as model string. This is the default
behavior in RIOT since eaace28804
After introducing #18423 there are occasional messages that still happen.
These messages cause a diff output when testing with TEST_KCONFIG=1.
This then causes a failure when comparing make/kconfig modules and packages.
A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
Allow issuing a reset to bootloader sequence by abusing the RTS and
the DTR pins of a TTL adapter. This makes flashing via UART much
more convenient, as no jumpers need to be placed to select booting to
the bootloader / flash and no reset buttons need to be pressed.
If Quad SPI modes qout or qio are set by variable FLASH_MODE, esptool.py has to be called with parameter `--flash_mode dio` so that the first stage bootloader is always using Dual SPI mode.
Examples have previously relied on the (really: some) nightly toolchain
to be the default. As that, in practice, is a problematic assumption,
the latest toolchain to use is now determined programmatically, and that
is set explicitly on the examples that use nightly.
Workaround-For: https://github.com/rust-lang/rustup/issues/3015
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.
This is also a workaround for Rust's [97685], but primarily to enhance
the error message by pointing out that -Zbuild-std is an option, and
generally presenting the error as RIOT usually does.
[97685]: https://github.com/rust-lang/rust/issues/97685
Module to lock the shell after a given timeout of time x. When the
shell did not receive any input within time x, then the shell is
locked automatically.
When `MOST_RECENT_PORT` is set to `1`, the most recently added USB
serial is selected. This is a crude but surprisingly effective filter.
However, for the CC2560-Launchpad this doesn't work, as it provides
two USB serials. The first USB serial interface is the targeted UART
bridge and the second controls the debugger. Since the second is added
a tiny fraction after the first, this reliably selects the wrong
interface. Allowing the board to filter USB serials first can avoid
this issue.
This is also useful as e.g. an STM Nucleo board can easily be told
apart from an `samr21-xpro` or an nRF52840dk using such filters.
Placing the SUIT key in the RIOT repository folder is dangerous as
a repo checkout is by most people considered a volatile location.
Since all important files are stored in git, deleting the entire folder
or it's contents is not an uncommon cleanup operation.
If the user is at that point unaware that SUIT key material is stored
in that folder, that key will then be lost.
Another workflow may involve multiple checkouts of the RIOT repository
to multiple folders to work on several features at the same time, or for
easy cross-referencing or splitting of off features from an integration
into a feature branch.
In that case each checkout would use it's own incompatible SUIT key.
To avoid all these pitfalls, place the SUIT keys outside the RIOT
repository in the $XDG_DATA_HOME directory.
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
I think the intention was that SUIT_VENDOR_DOMAIN gets set to
$(SUIT_VENDOR) so it can be overwritten by the build system.
However, no such code was in place yet.
Individual files need to be converted to uf2 format, targets
flashing individual slots or the bootloader will work:
- riotboot/flash-slot%
- riotboot/flash-bootloader
'flash' also works by flashing both the bootloader and slot0
independently.
But not targets flashing combined/extended versions since conversion
of the blob is not possible with the uf2conv.py script.
When doing a `make debug` on a board with riotboot bootloader, the original
(non-offset) elf file gets selected.
This causes all ROM addresses to be at the wrong offset, leading to strange
debug behavior.
Set `DEBUG_ELFFILE` to the .elf file that already accounts for the bootloader
offset so the debugger gets the correct addresses.
Use -misa-spec=2.2 on newer toolchains, which allows passing the same
-march value to both the linker and the compiler even when binutils and
GCC support difference ISA specs.
This is intended for the bootloader module where we don't enter thread
mode, so mutex must never attempt to switch context.
Instead use a simple busy wait that is enough to make the possible mutex
users (e.g. interrupt based SPI) in bootloader mode work.
- move all generated manifests under $(BINDIR)/suit_files (this can be
overwritten.
- rename signed manifests so that they are of the form:
<somename>.<version>.bin, where <somename> is by default riot.suit.
This avoids cluterring BINDIR while as well having a naming scheme that
allows custom names for manifests addresssing different types of
payloads.
- rename riotboot files so that they are of the form: slot<n>.<version>.bin
- move all generated files under $(BINDIR)/riotboot_files (this can be
overwritten.
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.
A backward incompatible change in the RISC-V resulting in instructions
previously included by rv32imac to only be available with
rv32imac_zicsr. All RISC-V CPUs supported by RIOT are hence either
considered as rv32imac (from the old ISA spec point of view) or as
rv32imac_zicsr (from the new ISA spec point of view). This adds a
simple test if GCC understands rv32imac_zicsr and uses it then as march,
but uses rv32imac as march if not.
This flag disables all builtin functions provided by the compiler as
well as disabling all optimizations and error checking related to
standard C library functions. If you're using a C library which
conforms to the ANSI C standard, you want to leave these compiler
features enabled.
Signed-off-by: Keith Packard <keithp@keithp.com>
This adds a xtimer_no_ztimer_default that is currently always
selected in Makefile, but that can be switched off in Kconfig.
Removing its inclusion will allow switching the default xtimer
backend to ztimer, while allowing for an easy way back.
This PR removes the old xtimer based implementation for sema. Since
this implementation used 64bit timeout, backweard compatibility is
kept by having `sema_wait_timed` be implemented by `ztimer64_usec`
which is enabled by selecting `sema_deprecated`
With this 64bit `sema` api is now deprecated.
- 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>
The directory `dist/tools/esptool` already contains a couple of ESP tools and not only esptool.py. As the location for a couple of ESP related tools, it is more clear to call it `esptools` instead of `esptool`.
Many simple kconfig configurations are added to boards and brought in with the board name.
This makes a common import of these configs so one only requires adding a BOARD.config without having to alter the makefile.
Some DEFAULT_MODULEs in tree have dependencies of their own. This is
usually done for aliases of init modules, and do not have dependencies
themselves.
This adds the final stage to dependency resolutions where DEFAULT_MODULEs
dependencies MAY be included. These included modules MUST NOT have
dependencies themselves.
This allows for modules to disable DEFAULT_MODULEs during dependencies
resolution independent of the inclusion order.
auto_init and periph_init modules are moved to this outer-loop, allowing
therefore for modules to disable them during the dependency resolution
Add a basic SenML module and submodules with support for:
- Encoding SenML values as CBOR using NanoCBOR.
- Converting from Phydat to SenML.
- Reading and encoding SAUL sensors.
This adds a list of variables that should always be passed to docker
since they are commonly set in Makefile/Makefile.include and therefore
can not be checked for their origin.
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.
Implement a new module stdio_nimble, which uses nimble
for stdio. The characteristic for stdin is writable and
the characteristic for stdout uses the indicate mechanism
to publish the system's output to a connected device.
Data will be sent out asynchronously via callout functions.
The module can be enabled with "USEMODULE += stdio_nimble"
Co-authored-by: Francisco Molina <femolina@uc.cl>
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.
The check for `newlib-nano` assumes that a toolchain which provides `newlib-nano` provides both the normal version and the nano version of the `newlib`.The nano version of `newlib.h` is therefore stored in its own include directory. This is the case for toolchains which allow to use both the normal and the nano version, e.g. for ARM and RISC-V.
However, if the toolchain provides `newlib_nano` but only allows the use of the nano version, it will only have the nano version of `newlib.h` and no separate directory for it, e.g. for ESP32.
To still be able to use such toolchains with `newlib_nano`, the check is changed so that the setting of the `-isystem` option depends on the existence of the separate directory.
Without passing this through, any crate downloads would go to the
container's image's scratch space, to be re-downloaded for each build,
and with new time stamps that cause compilation to start anew as well.
A couple of `stdio` backend implementations allow to check for the number of available bytes for reading before the blocking `stdio_read` is called. This helps to implement non-blocking functionalities while waiting for `stdin`.
For RISC-V and Cortex-M-not-3, triples are known and have worked in some
configuration, but do not work at the moment and stay disabled until the
reference platforms (native, M3) have been established well.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
The pseudomodules used by the PCF7857x driver are correctly defined by `Makfefile.include` of the driver. However, by mistake they were left in `makefiles/pseudomodules.mk` when the very old PR was rebased to the current master. That is, they were only leftovers that have been overseen after rebasing an squashing dozens of fixup commits.
As the packages need to be downloaded before they can be included in menuconfig it becomes a bit pointless.
This also messes around with make info-packages, adding unwanted output
This PR makes `event_timeout` and `event_timeout_ztimer` two distinct
pseudomodules, where the only api difference is in the init function.
If only `event_timeout_ztimer` is selected then no default ZTIMER
backend is selected and the old init function is not implemented.
If only `event_timeout` is selected then `xtimer` is used unless
`ztimer_usec` is included. In which case the `xtimer` wrapper on top
of `ztimer` is used and `xtimer` is not directly selected. This
allows for the legacy api to be supported with `ztimer_usec` as
a drop-in replacement.
If `event_timeout` and `event_timeut_ztimer` are selected then
`event_timeout` SRC file is excluded from compilation.
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.
