From 3989cd79ff443d545e4159802be5ff3b751a9414 Mon Sep 17 00:00:00 2001 From: Alexandre Abadie Date: Sat, 13 May 2023 18:23:57 +0200 Subject: [PATCH] treewide: fix path to shell related tests in doc --- cpu/esp32/doc.txt | 22 +++++++++---------- cpu/esp8266/doc.txt | 16 +++++++------- dist/pythonlibs/testrunner/spawn.py | 2 +- .../compile_test/compile_like_murdock.py | 2 +- dist/tools/compile_test/tests/test.sh | 2 +- dist/tools/vagrant/freebsd/README.md | 4 ++-- sys/stdio_nimble/README.md | 6 ++--- tests/sys/shell_ble/Makefile | 2 +- 8 files changed, 28 insertions(+), 28 deletions(-) diff --git a/cpu/esp32/doc.txt b/cpu/esp32/doc.txt index 8946f80603..ab2ff8366f 100644 --- a/cpu/esp32/doc.txt +++ b/cpu/esp32/doc.txt @@ -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 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 diff --git a/cpu/esp8266/doc.txt b/cpu/esp8266/doc.txt index 2c084e2175..c101157e3a 100644 --- a/cpu/esp8266/doc.txt +++ b/cpu/esp8266/doc.txt @@ -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`. diff --git a/dist/pythonlibs/testrunner/spawn.py b/dist/pythonlibs/testrunner/spawn.py index e334a894b3..9ca6b318e2 100644 --- a/dist/pythonlibs/testrunner/spawn.py +++ b/dist/pythonlibs/testrunner/spawn.py @@ -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 = \ diff --git a/dist/tools/compile_test/compile_like_murdock.py b/dist/tools/compile_test/compile_like_murdock.py index 0f32a0315a..727e17feaa 100755 --- a/dist/tools/compile_test/compile_like_murdock.py +++ b/dist/tools/compile_test/compile_like_murdock.py @@ -52,7 +52,7 @@ DEFAULT_APPS = [ "examples/hello-world", "tests/pkg/tinyusb_cdc_msc", "tests/mtd_mapper", - "tests/shell", + "tests/sys/shell/", "tests/saul" ] diff --git a/dist/tools/compile_test/tests/test.sh b/dist/tools/compile_test/tests/test.sh index 52e5381dee..47ae17c1be 100755 --- a/dist/tools/compile_test/tests/test.sh +++ b/dist/tools/compile_test/tests/test.sh @@ -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 } diff --git a/dist/tools/vagrant/freebsd/README.md b/dist/tools/vagrant/freebsd/README.md index 77965413b5..52feca19d0 100644 --- a/dist/tools/vagrant/freebsd/README.md +++ b/dist/tools/vagrant/freebsd/README.md @@ -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: diff --git a/sys/stdio_nimble/README.md b/sys/stdio_nimble/README.md index 4ee2fb82d6..78434eccb2 100644 --- a/sys/stdio_nimble/README.md +++ b/sys/stdio_nimble/README.md @@ -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 diff --git a/tests/sys/shell_ble/Makefile b/tests/sys/shell_ble/Makefile index ac8fe0e924..d2b66ddd7e 100644 --- a/tests/sys/shell_ble/Makefile +++ b/tests/sys/shell_ble/Makefile @@ -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