19060: SUBSYSTEMS.md: migrate subsystem list from wiki r=maribu a=jia200x
19154: tests/gcoap_dns: Remove duplicate r=miri64 a=Teufelchen1
### Contribution description
Removes a duplicated test. Originally, the test should have looked different and not be a duplicate. However, the behavior the test aimed at is no longer present anyway, hence it can be removed - rather than fixed.
Further insights can be provided by `@miri64`
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
18477: gnrc_static: add static network configuration r=miri64 a=benpicco
19101: CI: update check-labels-action r=miri64 a=kaspar030
19155: Revert "sys/pm_layered: pm_(un)block add attribute optimize(3)" r=maribu a=Teufelchen1
Revert "sys/pm_layered: pm_(un)block add attribute optimize(3) -shortens hotpath"
This reverts commit 5447203921.
### Contribution description
Compiling `examples/gnrc_networking_mac` using `TOOLCHAIN=llvm` yields the following error:
```
RIOT/sys/pm_layered/pm.c:77:16: error: unknown attribute 'optimize' ignored [-Werror,-Wunknown-attributes]
__attribute__((optimize(3)))
```
As indicated, this is because the attribute `optimize` is GCC only and not present in LLVM.
Compare the manpages of [GCC](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html) and [LLVM](https://clang.llvm.org/docs/AttributeReference.html).
### Testing procedure
Since this should only affect performance and not behavior, no special testing is needed. I am not aware of any tests in RIOT which could verify that assumption.
### Issues/PRs references
Introduced in #18846
There is another instance of this attribute being used in[ shell_lock.c](6fb340d654/sys/shell_lock/shell_lock.c (L80)). Since the usage is security related, I omit it from this PR.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19057: fuzzing: Add uri_parser setup r=benpicco a=Teufelchen1
Hello!
### Contribution description
This PR is a replacement for PR #18802
In this contribution:
* The variable `AFL_FLAGS` is renamed to `FLAGS_FOR_AFL` because AFL is always complaining that `AFL_FLAGS` is not a valid env var for it. While this is not a bug nor an issue, I found it to be annoying.
* A generic input reader is added to simplify building a test harness
* The usage of this reader is demonstrated by adding a harness for fuzzing the uri_parser
(needs squashing after review)
### Testing procedure
Go to `fuzzing/uri_parser` and run `make all-asan` and `make fuzz` to get some action going.
Also mildly interesting: `./dist/tools/compile_test/compile_like_murdock.py -b native -a fuzzing/uri_parser`
### Issues/PRs references
The original PR #18802 is replaced because the generic input reader is present in both PRs but this PoC harness is much simpler.
19151: examples/gcoap: Fix shell parameter validation r=benpicco a=maribu
### Contribution description
Executing the shell command with an URI-Path that doesn't start with a slash results in an assertion error while composing the client side message. This is suboptimal user experience, so add an explicit check for a valid URI-Path and a dedicated error message.
### Testing procedure
#### In `master`
```
$ make BOARD=microbit-v2 -C examples/gcoap flash term
[...]
2023-01-15 22:23:32,512 # coap get [::1] /.well-known/core
2023-01-15 22:23:32,516 # gcoap_cli: sending msg ID 52272, 23 bytes
2023-01-15 22:23:32,520 # gcoap: response Success, code 2.05, 46 bytes
2023-01-15 22:23:32,524 # </cli/stats>;ct=0;rt="count";obs,</riot/board>
> coap get [::1] foo
2023-01-15 22:23:34,763 # coap get [::1] foo
2023-01-15 22:23:34,763 # 2329
2023-01-15 22:23:34,765 # *** RIOT kernel panic:
2023-01-15 22:23:34,767 # FAILED ASSERTION.
2023-01-15 22:23:34,767 #
2023-01-15 22:23:34,775 # pid | name | state Q | pri | stack ( used) ( free) | base addr | current
2023-01-15 22:23:34,784 # - | isr_stack | - - | - | 512 ( 200) ( 312) | 0x20000000 | 0x200001c8
2023-01-15 22:23:34,793 # 1 | main | running Q | 7 | 1536 ( 1072) ( 464) | 0x200006c0 | 0x2000095c
2023-01-15 22:23:34,802 # 2 | 6lo | bl rx _ | 3 | 1024 ( 328) ( 696) | 0x200036c0 | 0x200039c4
2023-01-15 22:23:34,810 # 3 | ipv6 | bl rx _ | 4 | 1024 ( 460) ( 564) | 0x20001294 | 0x20001574
2023-01-15 22:23:34,819 # 4 | udp | bl rx _ | 5 | 512 ( 300) ( 212) | 0x20003e98 | 0x20003f9c
2023-01-15 22:23:34,828 # 5 | coap | bl anyfl _ | 6 | 1112 ( 704) ( 408) | 0x20000e38 | 0x200011c4
2023-01-15 22:23:34,837 # 6 | nrf802154 | bl anyfl _ | 2 | 896 ( 288) ( 608) | 0x20001a90 | 0x20001d54
2023-01-15 22:23:34,843 # | SUM | | | 6616 ( 3352) ( 3264)
2023-01-15 22:23:34,843 #
2023-01-15 22:23:34,844 # *** halted.
2023-01-15 22:23:34,844 #
```
#### This PR
```
$ make BOARD=microbit-v2 -C examples/gcoap flash term
[...]
make: Entering directory '/home/maribu/Repos/software/RIOT/examples/gcoap'
/home/maribu/Repos/software/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"
2023-01-15 22:22:27,842 # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
coap get [::1] /.well-known/core
2023-01-15 22:22:40,042 # coap get [::1] /.well-known/core
2023-01-15 22:22:40,046 # gcoap_cli: sending msg ID 25182, 23 bytes
2023-01-15 22:22:40,050 # gcoap: response Success, code 2.05, 46 bytes
2023-01-15 22:22:40,054 # </cli/stats>;ct=0;rt="count";obs,</riot/board>
> coap get [::1] foo
2023-01-15 22:22:43,858 # coap get [::1] foo
2023-01-15 22:22:43,862 # ERROR: URI-Path must start with a "/"
2023-01-15 22:22:43,866 # usage: coap <get|post|put|ping|proxy|info>
```
### Issues/PRs references
None
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht
### Contribution description
This PR provides
- the tinyUSB DFU and DFU Runtime support and
- the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images.
~This PR includes PR #18983 for now to be compilable.~
### Testing procedure
1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example
```
BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash
```
and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode:
```
dfu-util --list
```
3. Flash a first application using the following command:
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0
```
and check that the application starts and is seen as upgradable:
```
dfu-util --list
```
4. Restart the node in bootloader DFU mode by:
```
dfu-util -e
```
Flash a second application, for example
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1
```
and check that the second application starts and is seen as upgradable:
```
dfu-util --list
```
### Issues/PRs references
~Depends on PR #18983~
19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn
### Contribution description
Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release.
I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK.
### Issues/PRs references
#19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice).
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chrysn <chrysn@fsfe.org>
Executing the shell command with an URI-Path that doesn't start with a
slash results in an assertion error while composing the client side
message. This is suboptimal user experience, so add an explicit check
for a valid URI-Path and a dedicated error message.
17066: sys/irq: Add C++ wrapper using RAII r=maribu a=jenswet
### Contribution description
This adds a C++ wrapper around the `irq.h` API. The wrapper uses RAII to accomplish a convenient and bug resistent use.
A little background: I'm currently writing my master thesis on using C++ for embedded development, at the working group that `@maribu` is part of. For that I will try to add better C++ support to several parts of RIOT and then do some benchmarking and metrics to compare it with the C implementation. For example, I also plan to add a wrapper around i2c, a std::cout drop-in replacement and probably some more about networks or threads.
### Testing procedure
I've added a unit test to verify that the IRQ wrapper calls the original `irq` functions as expected. As C++ and wrapper testing isn't done much so far in this project, I've added two additional headers to ease testing:
1. #17076 - fake functions framework, already merged
2. As there is no framework for C++ unit tests yet, I've added something for this too. Unfortunately the existing frameworks like GoogleTest, CppUTest or CppUnit don't easily compile for embedded or are difficult to integrate in to the RIOT build process. That's why I wrote some (simple) helper functions and macros inspired by the above frameworks. That allows to create C++ tests based on a fixture class with set up and tear down methods. It also allows some simple assertions and is easily extendable for other use cases. It wraps some of the fff functionality too.
Both of this is obviously not required for the initial reason of this PR. But I'd like to provide unit tests for the features that I suggest to introduce where possible. So I'd appreciate some feedback on that too. If you'd prefer a PR without or different tests please let me know.
You can run the test `irq_cpp` locally or on the CI to test the implementation.
Please feel free to give feedback or suggest improvements!
Co-authored-by: Jens Wetterich <jens@wetterich-net.de>
17460: pkg/arduino_adafruit_sensor: add Adafruit Unified Sensor Driver as package r=benpicco a=gschorcht
### Contribution description
This PR provides the [Adafruit Unified Sensor Driver](https://github.com/adafruit/Adafruit_Sensor) as package.
There are a number of Adafruit sensor drivers which all use a common base class `Adafruit_Sensor` from the [Adafruit Unified Sensor Driver](https://github.com/adafruit/Adafruit_Sensor). To support such drivers, the Adafruit Unified Sensor Driver is provided as package.
Adafruit sensor driver for ST LSM9DS0 will be provided as separat PR as package for demonstration and testing.
PR #12518 will be rebased for testing to have an Adafruit sensor driver for a sensor for which there is a native driver in RIOT.
### Testing procedure
Use a board that provides the `arduino` feature and flash
```
BOARD=... make -C tests/pkg_arduino_adafruit_sensor flash test
```
PR #12518 can be used as a more complex test for using the package.
### Issues/PRs references
Prerequisite for PR #12518
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18763: sys/tiny_strerror: add missing error codes r=benpicco a=maribu
### Contribution description
When double-checking the error codes provided by newlib by default (without magic defines, such as `__LINUX_ERRNO_EXTENSIONS__` or `__CYGWIN__`), some where still missing in `tiny_strerror()`. This adds the missing ones.
This in turn showed that three errno codes were missing in the avr-libc compat `errno.h`, which are added as well.
### Testing procedure
Murdock should double check that the added errno codes indeed are defined by default.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19146: cpu/esp32: fix and improve UART initialization r=benpicco a=gschorcht
### Contribution description
This PR fixes issue #19138 that was introduced with PR #19100. It contains the following changes to fix the problems and to improve the UART initialization:
- If `LOG_LEVEL` is greater or equal 4, such as in `tests/log_printfnoformat`, the ESP-IDF config function called for the GPIO pins of the UART will output the configuration with `printf` before the `_GLOBAL_REENT` structure is initialized. This causes a crash during system startup. Therefore the initialization by `syscalls_init` must be called by `earlier in the startup procedure.
- Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pinsused by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
- To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
- To avoid a several msec long LOW pulse resulting in some garbage during the UART initialization, the TX line is set to HIGH and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output.
The PR requires a backport to 2023.1
### Testing procedure
The following tests should work with this PR:
- [ ] `tests/log_color`
- [ ] `tests/log_printfnoformat`
- [ ] `tests/sys_arduino`
### Issues/PRs references
Fixes#19138
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19071: boards/rpi-pico-w: initial support for rpi pico W board r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds initial RIOT OS support for the Raspberry Pico W - the Raspberry Pico with a Wifi/Bluetooth Infineon CYW 43439 module (*).
The code is based on PR #15822 and contains changes associated with small differences between RPi Pico and Pico W. The most important is that LED0 is connected to the CYW 43439 module and without PIO (PR #17425) cannot be used (RP2040 and CYW 43439 are connected together using SPI and Pico SDK utilize PIO to program SPI). Current LED0 implementation is similar to one for `native` board and prints appropriate texts on STDIO.
(*) Currently network connectivity not implemented.
### Testing procedure
Flash sample program and look at doc:
```
make doc
xdg-open doc/doxygen/html/group__boards__rpi__pico__w.html
```
### Issues/PRs references
Based on PR #15822.
Needs PR #17425.
Additional doc:
[Raspberry Pi Pico and Pico W](https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html)
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
The TX line is set and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output to avoid a several msec long LOW pulse resulting in some garbage.
Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pins used by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
If LOG_LEVEL >= 4, such as in `tests/log_printfnoformat`, the ESP-IDF config function called for the GPIO pins of the UART will output the configuration with `printf` before the `_GLOBAL_REENT` structure is initialized. This causes a crash during system startup. Therefore the initialization by `syscalls_init` must be called earlier in the startup procedure.
19141: shell/rtc: Fix out of bounds access; document error behavior r=maribu a=chrysn
### Contribution description
### Testing procedure
Should be trivial enough, especially as the difference is hard to spot interactively.
On native, run the default example (and wait for the traffic to settle).
Then, run
```
> rtc poweron
> rtc settime 2022-01-01 00:00:00
> rtc settime 2022-99-01 00:00:00
```
Both still work, but the latter doesn't access unassigned memory any more
### Issues/PRs references
This fixes an issue that was submitted anonymously.
Co-authored-by: chrysn <chrysn@fsfe.org>
With b30efeeb65 a warning was introduced when using `make term` without
the proper toolchain installed (e.g. when using BUILD_IN_DOCKER, but
`term` outside of the docker). This removes this warning
19050: boards/common/cc26xx cc13xx: clean up and fix flash configs r=benpicco a=maribu
### Contribution description
- Add support for XDS110 debugger via `OPENOCD_DEBUG_ADAPTER=xds110`
- Clean up OpenOCD configs in `boards/common/cc26xx_cc13xx`
- No longer hardcode the debugger to xds110, but use `OPENOCD_DEBUG_ADATER ?= xds110`
- Add support for cc13x0, cc13x2, cc26x0
- `boards/cc2650*`: drop custom OpenOCD config in favor of shared one
- add variables needed to support flashing with `PROGRAMMER=jlink`
- allow specifying a custom OpenOCD command to bring the device to a halt state, as the default `reset halt` (which causes a second reset) is causing issues with the ICEPick JTAG routers in the CC26xx - CC13xx devices
- Use `halt` instead of `reset halt` for CC26xx / CC13xx boards in OpenOCD to avoid issues in flashing
### Testing procedure
```
make BOARD=cc2650-launchpad -C examples/default flash
```
Should now work. The same should still work for other cc26xx cc13xx boards.
### Issues/PRs references
Partially fixes: https://github.com/RIOT-OS/RIOT/issues/18750
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
