19212: shell/rtc: use rtc_tm_normalize() to sanitize input r=benpicco a=benpicco
19360: gcoap: make use coap_build_reply() in gcoap_resp_init() r=benpicco a=benpicco
19401: shell/cmds: add genfile command r=benpicco a=benpicco
19645: sys/isrpipe: Replace xtimer with ztimer_usec r=benpicco a=MrKevinWeiss
### Contribution description
Getting ready for the xtimer dep.
### Testing procedure
Green murdock, there is no explicit test for isrpipe but since it runs xtimer compat it should operate the same.
### Issues/PRs references
19720: tests: remove unnecessary use of floating point r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
17091: USBUS: Add URB support r=benpicco a=bergzand
### Contribution description
This commit adds support for URBs (USB Request/Response Blocks). These
allow for submitting multi-transfer sized buffers with USBUS handling
the individual usbdev xmits. Multiple URBs can be queued at once for a
single endpoint and USBUS will handle them in the order of submission.
OUT endpoint URBs must always consist of a whole number of full-sized
transfers (N x MaxEndpointSize). They will automatically finish after
the endpoint received a transfer less than the endpoint size.
IN endpoints can be arbitrary-sized and do not have to consist of a
whole number of full-sized transmissions. They support a flag to
indicate that the last transfer in the sequence must be less than a full
sized transfer (USBUS_URB_FLAG_AUTO_ZLP) and this adds a zero length
transfer at the end of the transmissions if the last transfer was equal
to the maximum transfer size.
URBs can be cancelled, but if the URB is already being processed it will
be cancelled after the current transmission within the URB is finished.
If it is still in the queue it will immediately be removed from the
queue.
### Testing procedure
- `tests/usbus_cdc_ecm` should still work. Testing one of the usbdev-supported platform should be sufficient here.
### Issues/PRs references
Needs #17064
18148: sys/flash_utils: helpers to store data in flash r=benpicco a=maribu
### Contribution description
This helpers that allow storing, accessing, and working with data in flash that works for both classical Harvard architectures (which do not map flash also into the address space) as well as modern Harvard architectures and von-Neumann architectures.
With this, `examples/default` again runs on the Arduino Uno / Nano. Since this board is still the "entry kit" for many people to embedded hardware, it would be nice to support it with our default example.
### Testing procedure
`examples/default` should run and work on ATmega boards (especially ATmega328P and ATmega32U4 based boards) as well on all other boards now.
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This allows automatically moving format strings to flash, provided that
code previously compiled fine with `-Wformat-nonliteral` (which in RIOT
is the case due to `-Wformat=2`).
17045: sys/coding: add XOR based coding module r=benpicco a=benpicco
19243: cpu/gd32v: add periph_gpio_ll and periph_gpio_ll_irq support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_gpio_ll` and `periph_gpio_ll_irq` support for GD32VF103. Level triggered interrupts are emulated.
`periph_gpio_ll_irq` could be split off from this PR as a separate PR if necessary.
### Testing procedure
Use any GD32V board and connect PA0 -> PB0 and PA1 -> PB1 where PA is the output port and PB the input port. With these connections `tests/periph_gpio_ll` should work.
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio_ll flash term
```
If necessary, change the input and output pins by setting the environment variables and connect the corresponding pins, for example for `seeedstudio-gd32` PA1 -> PB8 and PA8 -> PB9:
```
PIN_OUT_0=1 PIN_OUT_1=8 PIN_IN_0=8 PIN_IN_1=9 BOARD=seedstudio-gd32 make -j8 -C tests/periph_gpio_ll flash term
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
This implements the XOR based error-correction code described by
Jürgen Fitschen (@jue89) at the RIOT Summit.
A parity byte is generated for each 3 payload bytes, then the payload array
is transposed by interpreting it as a 2D matrix with height of 3.
This is to reduce the chance of consecutive bytes ending up in the same
packet.
This allows to recover one in 3 lost data packets (if parity packets are received).
[0] https://summit.riot-os.org/2021/wp-content/uploads/sites/16/2021/09/s02-01.pdf
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>
