RIOT-OS/RIOT
RIOT-OS/RIOT
1
0
Fork 0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
Code Releases Activity

Merge #19592

Browse Source 
19592: treewide: fix remaining broken paths to test applications r=maribu a=aabadie



Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
This commit is contained in:
bors[bot] 2023-05-14 16:30:50 +00:00 committed by GitHub
commit 2863dc9031
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
33 changed files with 74 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
.murdock
View File

@ -111,8 +111,8 @@ z1
"}
: ${TEST_KCONFIG_ENFORCE_APP_GROUPS:="
tests/cb_mux*
tests/congure_*
examples/hello-world
tests/build_system/external_board_dirs
tests/drivers/b*
tests/drivers/f*
tests/drivers/g*
@ -128,16 +128,16 @@ tests/drivers/s*
tests/drivers/t*
tests/drivers/u*
tests/drivers/v*
tests/external_board_dirs
tests/net/ieee802154_hal
tests/periph/*
tests/pkg/elk
tests/pkg/uzlib
tests/prng_*
tests/trace
tests/xtimer_*
tests/ztimer_*
examples/hello-world
tests/ieee802154_hal
tests/sys/cb_mux*
tests/sys/congure_*
tests/sys/prng_*
tests/sys/trace
tests/sys/xtimer_*
tests/sys/ztimer_*
"}
# This list prevents boards from being tested by the TEST_KCONFIG_TEST_ALLOWLIST
@ -155,8 +155,8 @@ tests/ieee802154_hal
# the kconfig implementations.
: ${TEST_KCONFIG_TEST_ALLOWLIST:="
examples/hello-world
tests/saul
tests/mtd_mapper
tests/drivers/saul
tests/drivers/mtd_mapper
"}
: ${TEST_WITH_CONFIG_SUPPORTED:="examples/suit_update tests/drivers/at86rf2xx_aes"}

10
CODEOWNERS
View File

@ -141,16 +141,16 @@
/sys/ztimer/ @kaspar030 @bergzand
/tests/ @smlng @leandrolanzieri @aabadie @MichelRottleuthner @fjmolinas
/tests/candev/ @wosym
/tests/drivers/candev/ @wosym
/tests/drivers/bq2429x/ @jeandudey
/tests/drivers/dht/ @wosym
/tests/gnrc* @miri64
/tests/lwip* @miri64
/tests/net/gnrc* @miri64
/tests/pkg/lwip* @miri64
/tests/pkg/libschc/ @miri64
/tests/slip/ @miri64
/tests/net/slip/ @miri64
/tests/unittests @miri64
/tests/*/tests/*.py @miri64
/tests/cpu_efm32_features/ @basilfx
/tests/cpu/efm32_features/ @basilfx
# KConfig maintainers will be notified about all KConfig changes
Kconfig @leandrolanzieri @jia200x @MrKevinWeiss

2
boards/b-u585i-iot02a/doc.txt
View File

@ -37,7 +37,7 @@ For using the ST B-U585I-IOT02A board we recommend the usage of the
[GNU Tools for ARM Embedded Processors](https://launchpad.net/gcc-arm-embedded)
toolchain.
**Important notice:** With GCC 10, the `tests/malloc` application doesn't work.
**Important notice:** With GCC 10, the `tests/sys/malloc` application doesn't work.
To use malloc, prefer GCC 9 which seems to work better.
*/

2
bootloaders/riotboot/doc.txt
View File

@ -121,7 +121,7 @@ microcontroller is rather straightforward. You need to:
- Provide the variables `ROM_START_ADDR` and `ROM_LEN` as well as
`RAM_LEN` and `RAM_START_ADDR`.
- Adapt the linker scripts for your cpu to pass the test
[tests/cortexm_common_ldscript](../../tests/cortexm_common_ldscript). This test
[tests/cpu/cortexm_common_ldscript](../../tests/cpu/cortexm_common_ldscript). This test
ensures that the linker script supports building firmware's with a rom offset
and specific sized firmware's.
- Make the startup code `board_init()`, `cpu_init` idempotent, i.e. whether you

22
cpu/esp32/doc.txt
View File

@ -576,11 +576,11 @@ command, for example:
- RIOT Docker build image installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options]
make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Local toolchain installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options]
$ make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `BOARD` variable in the example specifies the generic ESP32 board that uses
@ -2051,12 +2051,12 @@ installed.
To use QEMU for ESP32, an application has to be built with `esp_qemu` module
enabled, for example with local toolchain installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or with RIOT Docker build image
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Instead of flashing the image to the target hardware, a binary image named
@ -2070,7 +2070,7 @@ QEMU for ESP32 can then be started with command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ qemu-system-xtensa \
-s -machine esp32 \
-drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
-drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
-serial tcp::5555,server,nowait
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -2099,12 +2099,12 @@ start_test starts a test
To debug the application in QEMU for ESP32, another terminal is required:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf
$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
...
Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done.
Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
(gdb) target remote :1234
Remote debugging using :1234
@ -2117,10 +2117,10 @@ QEMU for ESP32 can also be used in RIOT Docker build image. For that purpose
QEMU has to be started in the Docker container.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo docker run --rm -i -t -u $UID -v $(pwd):/data/riotbuild riot/riotbuild
riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
riotbuild@container-id:~$ qemu-system-xtensa \
-s -machine esp32 \
-drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
-drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
-serial tcp::5555,server,nowait
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -2144,12 +2144,12 @@ test_shell.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo docker docker exec -it <container-id> bash
riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf
riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
...
Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done.
Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
(gdb) target remote :1234
Remote debugging using :1234

16
cpu/esp8266/doc.txt
View File

@ -59,7 +59,7 @@ To build a RIOT application, simply use the `make` command and specify an
existing ESP8266 board, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make flash BOARD=esp8266-esp-12x -C tests/shell ...
make flash BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For more information about the `make` command variables and specific compile
@ -283,7 +283,7 @@ directory, a RIOT application can be compiled inside RIOT Docker using the
make command as usual, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make BOARD=esp8266-esp-12x -C tests/shell ...
make BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This will generate a RIOT binary in ELF format.
@ -295,7 +295,7 @@ of the compilations is also accessible on the host system. On the host system,
the `flash-only` target can then be used to flash the binary.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make flash-only BOARD=esp8266-esp-12x -C tests/shell
make flash-only BOARD=esp8266-esp-12x -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@note Both steps can also be performed with a single command on the host
@ -1126,7 +1126,7 @@ For debugging purposes, the application should be compiled with debugging
information. This can either be done by using the `esp_gdb` module, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/shell
USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Back to table of contents](#esp8266_toc)
@ -1162,7 +1162,7 @@ term1> $QEMU/bin/qemu-system-xtensa -M esp8266 -nographic -serial stdio -monitor
where `/path/to/build/dir` is the path to the application build directory
`$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`. After that you can
`$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`. After that you can
start `GDB` in second terminal window using command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1203,7 +1203,7 @@ To start debugging, the application has to be compiled using
module `esp_gdbstub`, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/shell
USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once, the application is flashed to ESP82666, debugging can be started as
@ -1223,7 +1223,7 @@ term2> xtensa-esp8266-elf-gdb /path/to/the/build/dir/image.elf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where `/path/to/build/dir` is the path to the application build directory
`$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`.
`$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`.
3. Connect from `GDB` to the ESP8266 module with command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1250,7 +1250,7 @@ the application stepwise or just continue the execution using the `continue`
command. Please note the limitations below. Once you have started the execution
in `GDB`, you can use `Ctrl-C` in `GDB` or the console window to break it anytime.
If your application uses console inputs (stdio), such as the `tests/shell`
If your application uses console inputs (stdio), such as the `tests/sys/shell/`
application, you can type characters in the console window that gdbstub will
forward to the application. However, the echo of these inputs occur in `GDB`.

2
cpu/saml21/include/periph_cpu.h
View File

@ -140,7 +140,7 @@ static const gpio_t sam0_adc_pins[1][20] = {
#define RTT_CLOCK_FREQUENCY (32768U) /* in Hz */
#define RTT_MIN_FREQUENCY (RTT_CLOCK_FREQUENCY / 512U) /* in Hz */
#define RTT_MAX_FREQUENCY (RTT_CLOCK_FREQUENCY) /* in Hz */
/* determined by tests/ztimer_underflow */
/* determined by tests/sys/ztimer_underflow */
#define RTT_MIN_OFFSET (8U)
/** @} */

2
dist/pythonlibs/testrunner/spawn.py vendored
View File

@ -41,7 +41,7 @@ TEST_INTERACTIVE_DELAY = int(os.environ.get('TEST_INTERACTIVE_DELAY') or 1)
TESTRUNNER_RESET_AFTER_TERM = int(os.environ.get('TESTRUNNER_RESET_AFTER_TERM')
or 0)
# When running e.g. tests/shell_ble we don't want to reset the board, because
# When running e.g. tests/sys/shell/_ble we don't want to reset the board, because
# then ble-serial would terminate and the created virtual serial port would get
# lost. By default the board is reset before the test starts.
TESTRUNNER_RESET_BOARD_ON_STARTUP = \

8
dist/tools/compile_test/compile_like_murdock.py vendored
View File

@ -28,7 +28,7 @@ The following use cases are:
`./compile_like_murdock.py -c stm32`
I changed a driver the DHT driver
`./compile_like_murdock.py -a tests/drivers/dht tests/saul`
`./compile_like_murdock.py -a tests/drivers/dht tests/drivers/saul`
I changed a nucleo-f103rb board...
`./compile_like_murdock.py -a all -b nucleo-f103rb`
@ -50,10 +50,10 @@ _RATIOS = [
DEFAULT_APPS = [
"examples/hello-world",
"tests/drivers/mtd_mapper",
"tests/drivers/saul",
"tests/pkg/tinyusb_cdc_msc",
"tests/mtd_mapper",
"tests/shell",
"tests/saul"
"tests/sys/shell/",
]
DEFAULT_BOARDS = [

2
dist/tools/compile_test/tests/test.sh vendored
View File

@ -38,7 +38,7 @@ function call_with_defaults {
function call_with_specific_board_app {
${COMPILE_TEST_DIR}/compile_like_murdock.py \
--boards native \
--apps tests/shell \
--apps tests/sys/shell/ \
--dry-run
}

4
dist/tools/vagrant/freebsd/README.md vendored
View File

@ -31,8 +31,8 @@ See the general vagrant [README.md](../README.md) for more commands.
Once logged in to the VM you can run compile and run tests e.g.
```sh
make -C tests/shell all -j
make -C tests/shell test
make -C tests/sys/shell/ all -j
make -C tests/sys/shell/ test
```
Even applications requiring network interface access should be able to work:

2
doc/doxygen/src/creating-modules.md
View File

@ -82,7 +82,7 @@ External modules can optionally define the following files:
module `foo` must be located in `<PATH_IN_EXTERNAL_MODULE_DIRS>/foo`.
An example can be found in
[`tests/external_module_dirs`](https://github.com/RIOT-OS/RIOT/tree/master/tests/external_module_dirs)
[`tests/build_system/external_module_dirs`](https://github.com/RIOT-OS/RIOT/tree/master/tests/build_system/external_module_dirs)
Pseudomodules {#pseudomodules}
=============

2
doc/doxygen/src/kconfig/kconfig.md
View File

@ -86,7 +86,7 @@ applied. Note that if any dependency issue occurs, warnings will be generated
## Application configuration with Kconfig {#app-config-kconfig}
To expose application-specific configuration options a `Kconfig` file can
be placed in the application's folder. For an example of this you can check
the [tests/kconfig](https://github.com/RIOT-OS/RIOT/tree/master/tests/kconfig)
the [tests/build_system/kconfig](https://github.com/RIOT-OS/RIOT/tree/master/tests/build_system/kconfig)
application.
## Configuration via environment variables {#env-config-kconfig}

6
doc/doxygen/src/porting-boards.md
View File

@ -180,11 +180,11 @@ PROGRAMMER ?= openocd
When using high level timers, i.e. `ztimer` there is an overhead in calling
for @ref ztimer_sleep and @ref ztimer_set functions. This offset can be
compensated for. It can be measured by running `tests/ztimer_overhead`
compensated for. It can be measured by running `tests/sys/ztimer_overhead`
on your board, i.e:
```shell
$ BOARD=my-new-board make -C tests/ztimer_overhead
$ BOARD=my-new-board make -C tests/sys/ztimer_overhead
main(): This is RIOT!
ZTIMER_USEC auto_adjust params:
ZTIMER_USEC->adjust_set = xx
@ -379,7 +379,7 @@ In this case some special considerations must be taken with the makefiles:
`include $(RIOTBOARD)/foo-parent/Makefile.*include*`
An example can be found in
[`tests/external_board_native`](https://github.com/RIOT-OS/RIOT/tree/master/tests/external_board_native)
[`tests/build_system/external_board_native`](https://github.com/RIOT-OS/RIOT/tree/master/tests/build_system/external_board_native)
# Tools {#boards-tools}

2
drivers/include/pcf857x.h
View File

@ -195,7 +195,7 @@
* @note Module `saul_gpio` has to be added to the
* project to enable SAUL capabilities of the PCF857X driver, e.g.:
*
* USEMODULE="pcf8575 saul_gpio" make -C tests/saul BOARD=...
* USEMODULE="pcf8575 saul_gpio" make -C tests/drivers/saul BOARD=...
*
* ## Using Multiple Devices
*

2
examples/gnrc_minimal/Makefile
View File

@ -34,7 +34,7 @@ CFLAGS += -DCONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF=2 \
# Change this to 0 show compiler invocation lines by default:
QUIET ?= 1
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/external_board_dirs/esp-ci-boards
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/build_system/external_board_dirs/esp-ci-boards
include $(RIOTBASE)/Makefile.include

2
examples/gnrc_networking/Makefile
View File

@ -68,7 +68,7 @@ endif
# Change this to 0 show compiler invocation lines by default:
QUIET ?= 1
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/external_board_dirs/esp-ci-boards
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/build_system/external_board_dirs/esp-ci-boards
include $(RIOTBASE)/Makefile.include

2
makefiles/pseudomodules.inc.mk
View File

@ -590,7 +590,7 @@ PSEUDOMODULES += ztimer64_%
## a configurable @ref CONFIG_ZTIMER_AUTO_ADJUST_SETTLE value can be set for this.
##
## Alternatively CONFIG_ZTIMER_USEC_ADJUST_% values can be set in the BOARDs
## configuration header board.h. These can be found out by running tests/ztimer_overhead
## configuration header board.h. These can be found out by running tests/sys/ztimer_overhead
PSEUDOMODULES += ztimer_auto_adjust
# core_lib is not a submodule

2
pkg/doc.txt
View File

@ -96,7 +96,7 @@
* `foo`must be located in `<PATH_IN_EXTERNAL_PKG_DIRS>/foo`.
*
* An example can be found in
* [`tests/external_pkg_dirs`](https://github.com/RIOT-OS/RIOT/tree/master/tests/external_pkg_dirs)
* [`tests/build_system/external_pkg_dirs`](https://github.com/RIOT-OS/RIOT/tree/master/tests/build_system/external_pkg_dirs)
*
* RIOT welcomes new and useful packages. If you'd like to share your work,
* consider [contributing](https://github.com/RIOT-OS/RIOT/tree/master/CONTRIBUTING.md).

4
pkg/wolfssl/doc.txt
View File

@ -127,7 +127,7 @@
* platforms.
*
* ```makefile
* cd <path-to>/RIOT/tests/wolfssl-test
* cd <path-to>/RIOT/tests/pkg/wolfssl-test
* make
* ./bin/native/wolfssl-test.elf # execute native port
* ```
@ -138,7 +138,7 @@
* and memory requirements
*
* ```makefile
* cd <path-to>/RIOT/tests/wolfcrypt-ed25519-verify
* cd <path-to>/RIOT/tests/pkg/wolfcrypt-ed25519-verify
* make
* ./bin/native/wolfcrypt-ed25519-verify.elf # execute native port
* ```

2
sys/fido2/doc.txt
View File

@ -197,7 +197,7 @@
*
* Testing is done with the help of the fido2-tests package based on the [solokeys fido2-tests](https://github.com/solokeys/fido2-tests).
*
* For for more information about testing the FIDO2 CTAP implementation refer to the README of the test application (`/tests/sys_fido2_ctap`).
* For for more information about testing the FIDO2 CTAP implementation refer to the README of the test application (`/tests/sys/fido2_ctap`).
*
* **Todo**
*

2
sys/include/frac.h
View File

@ -18,7 +18,7 @@
* runtime, or via a precomputed initializer.
*
* Precomputing the frac_t values can be done via the application found in
* `tests/frac-config` in the RIOT tree.
* `tests/sys/frac-config` in the RIOT tree.
*
* ### Numeric precision
*

2
sys/include/puf_sram.h
View File

@ -30,7 +30,7 @@
* even before kernel initialization.
* Memory properties are hardware specific and can depend on environmental conditions.
* Thus, they should be evaluated for each individual deployment. A basic
* testing tool is provided in /RIOT/tests/puf_sram.
* testing tool is provided in /RIOT/tests/sys/puf_sram.
*
* # Soft-reset detection
*

2
sys/include/ztimer/config.h
View File

@ -155,7 +155,7 @@ extern "C" {
* introduced by turning on the underlying peripheral.
*
* @note This value can be measured with the
* `tests/ztimer_ondemand_benchmark` tool.
* `tests/sys/ztimer_ondemand_benchmark` tool.
*
* This value should be configured in the board.h.
*/

2
sys/shell/cmds/gnrc_ipv6_nib.c
View File

@ -30,7 +30,7 @@ static int _nib_route(int argc, char **argv);
static int _nib_abr(int argc, char **argv);
#endif /* CONFIG_GNRC_IPV6_NIB_MULTIHOP_P6C */
/* TODO: updated tests/gnrc_dhcpv6_client to no longer abuse this shell command
/* TODO: updated tests/net/gnrc_dhcpv6_client to no longer abuse this shell command
* and add static qualifier */
int _gnrc_ipv6_nib(int argc, char **argv)
{

2
sys/shell/cmds/gnrc_netif.c
View File

@ -1853,7 +1853,7 @@ static int _gnrc_netif_send(int argc, char **argv)
SHELL_COMMAND(txtsnd, "Sends a custom string as is over the link layer", _gnrc_netif_send);
#endif
/* TODO: updated tests/gnrc_dhcpv6_client to no longer abuse this shell command
/* TODO: updated tests/net/gnrc_dhcpv6_client to no longer abuse this shell command
* and add static qualifier */
int _gnrc_netif_config(int argc, char **argv)
{

6
sys/stdio_nimble/README.md
View File

@ -41,7 +41,7 @@ Otherwise the device will appear as "*RIOT OS device*".
## Instructions to connect to the bluetooth shell via ble-serial
- Configure and compile shell app for nrf52840dongle target in `tests/shell`.\
- Configure and compile shell app for nrf52840dongle target in `tests/sys/shell`.\
Add following to Makefile:
```
@ -50,11 +50,11 @@ USEMODULE += nimble_autoadv
USEMODULE += stdio_nimble
```
**NOTE:** You can also have a look at `tests/shell_ble`.
**NOTE:** You can also have a look at `tests/sys/shell_ble`.
- Flash
`$ make -C tests/shell -j clean all flash`
`$ make -C tests/sys/shell -j clean all flash`
- Install the ble-serial tool

4
sys/test_utils/dummy_thread/dummy_thread.c
View File

@ -21,8 +21,8 @@
* This module can be used by manually adding it to the command line when
* building, e.g.,
*
* USEMODULE+=dummy_thread make -C tests/rmutex
* make -C tests/rmutex test
* USEMODULE+=dummy_thread make -C tests/core/rmutex
* make -C tests/core/rmutex test
*
* Note how the output of the test changes compared to a build without
* dummy_thread.

2
tests/drivers/ws281x/Makefile
View File

@ -12,7 +12,7 @@ USEMODULE += xtimer
# is clocked at 14.7456 MHz :-/
BOARD_BLACKLIST := waspmote-pro
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/external_board_dirs/esp-ci-boards
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/build_system/external_board_dirs/esp-ci-boards
include $(RIOTBASE)/Makefile.include

2
tests/net/gnrc_netif_ieee802154/tests/01-run.py
View File

@ -23,7 +23,7 @@ def testfunc(child):
dst = int(child.match.group(1).replace(':', ''), base=16)
# first send valid packet to check if communication is set up correctly
# generated with udp send <link-local> 61616 0 in tests/gnrc_udp
# generated with udp send <link-local> 61616 0 in tests/net/gnrc_udp
payload = b"\x7e\x33\xf3\x00"
payload = (
Dot15d4FCS(fcf_srcaddrmode=2, fcf_panidcompress=True,

2
tests/net/gnrc_sock_tcp/README.md
View File

@ -2,7 +2,7 @@ Test description
==========
The testsuite tests the GNRC TCP integration into the SOCK TCP interface.
The tests offer only basic verification of the SOCK TCP interface since GNRC TCP aims
follow the SOCK TCP interface as close as possible, detailed tests are under tests/gnrc_tcp
follow the SOCK TCP interface as close as possible, detailed tests are under tests/net/gnrc_tcp
Setup
==========

2
tests/pkg/nimble_esp_wifi_coexist/Makefile
View File

@ -60,7 +60,7 @@ DEVELHELP ?= 1
# Change this to 0 show compiler invocation lines by default:
QUIET ?= 1
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/external_board_dirs/esp-ci-boards
EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/build_system/external_board_dirs/esp-ci-boards
include $(RIOTBASE)/Makefile.include

2
tests/sys/shell_ble/Makefile
View File

@ -8,7 +8,7 @@ USEMODULE += ps
USEMODULE += stdio_nimble stdio_nimble_debug
USEMODULE += nimble_autoadv
CFLAGS += -DCONFIG_NIMBLE_AUTOADV_DEVICE_NAME='"tests/shell_ble"'
CFLAGS += -DCONFIG_NIMBLE_AUTOADV_DEVICE_NAME='"tests/sys/shell/_ble"'
TESTRUNNER_SHELL_SKIP_REBOOT = 1
TESTRUNNER_RESET_BOARD_ON_STARTUP = 0