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>
19102: gh-actions: report release-tests result to Matrix r=maribu a=miri64
19128: boards: common: stdio_cdc_acm: let tests wait a bit for serial port r=miri64 a=miri64
19133: makefiles/utils/strings.mk: Fix version_is_greater_or_equal r=maribu a=maribu
### Contribution description
The Makefile function `version_is_greater_or_equal` is used to check if a version of GNU Make is at least the required one. However, it has the built-in assumption the version numbers have to format x.y.z, but Alpine Linux currently ships GNU Make 4.4. This results in `$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell, which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to printing `0` with the given padding, if the number given to print is empty.
### Testing procedure
Append
```Makefile
$(info A=$(call version_is_greater_or_equal,4.2.0,4.2.0))
$(info B=$(call version_is_greater_or_equal,4.2,4.2.0))
$(info C=$(call version_is_greater_or_equal,4.1,4.2.0))
$(info D=$(call version_is_greater_or_equal,4.1.9,4.2.0))
$(info E=$(call version_is_greater_or_equal,5.1.9,4.2.0))
$(info F=$(call version_is_greater_or_equal,5.0.0,4.2.0))
$(info G=$(call version_is_greater_or_equal,4.2.1,4.2.0))
$(info H=$(call version_is_greater_or_equal,4.3.1,4.2.0))
```
e.g. to `makefiles/utils/strings.mk`, build something and observe the info output.
This yields
```
A=1
B=1
C=
D=
E=1
F=1
G=1
H=1
```
for me and does not complain about invalid `printf` invocations.
### Issues/PRs references
None
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The Makefile function `version_is_greater_or_equal` is used to check if
a version of GNU Make is at least the required one. However, it has
the built-in assumption the version numbers have to format x.y.z,
but Alpine Linux currently ships GNU Make 4.4. This results in
`$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell,
which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to
printing `0` with the given padding, if the number given to print is
empty.
19129: boards/seeedstudio-gd32: fix HXTAL clock in Kconfig r=miri64 a=gschorcht
### Contribution description
This PR fixes the wrong default value of `CLOCK_HXTAL` in Kconfig introduced with PR #19109. It was accidentally set to the default value of 80 MHz instead of 8 MHz.
### Testing procedure
```
python3 dist/tools/compile_test/compile_like_murdock.py -a tests/shell -b seeedstudio-gd32 -j8
```
Without the PR the command gives:
```
tests/shell seeedstudio-gd32 FAIL: Kconfig hash mismatch
```
WIth the PR the compile test should pass:
```
tests/shell seeedstudio-gd32 PASS
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19122: boards/qn9080dk: Improve doc and add J-Link support r=benpicco a=maribu
### Contribution description
- document that the QN9080DK has an alternative firmware for the debugger/programmer that supports J-Link
- allow selecting the debugger firmware via parameter / environment variable
- add `JLINK_DEVICE` parameter to allow flashing via J-Link
### Testing procedure
- read the doc generated by the CI
- run `make flash BOARD=qn9080dk QN9080DK_JLINK=1` and `make flash BOARD=qn9080dk QN9080DK_JLINK=0`
- Confirm that in the former case flashing uses J-Link (if installed) or OpenOCD using the jlink interface (if J-Link is not installed)
- Confirm that in the second case (`QN9080DK_JLINK=0`) flashing uses OpenOCD and the dap interface.
- I tested this with the actual hardware, but it is sufficient to just check if the invocation of the flashing script is sane
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19125: dist/tools/esptools/export.sh: fixes IDF_TOOLS_PATH default setting r=benpicco a=gschorcht
### Contribution description
This PR re-adds the setting of the default value of the variable `IDF_TOOLS_PATH` which was accidentally removed with PR #18385.
The `IDF_TOOLS_PATH` variable is used by the ESP-IDF to define the path where the Espressif toolchain is installed. Reusing this variable to set the path of the toolchain in RIOT allows the use of an existing Espressif toolchain if it has already been installed with ESP-IDF. If the variable is not defined it is set to `${HOME}/.espressif` as described in [documentation](https://doc.riot-os.org/group__cpu__esp32.html#esp32_local_toolchain_installation):
```
if [ -z ${IDF_TOOLS_PATH} ]; then
IDF_TOOLS_PATH=${HOME}/.espressif
fi
```
Unfortunatly were these 3 lines be removed in `dist/tools/esptools/export.sh` accidentially with #18385 so that it became necessary to set this variable manually. If the variable was not set, the `dist/tools/esptools/export.sh` script didn't work for the Espressif toolchain installed with the companion script `dist/tools/esptools/install.sh`.
### Testing procedure
```
dist/tools/esptools/install.sh esp32
. dist/tools/esptools/export.sh esp32
```
Without the PR, the export doesn't work, with the PR it works.
### Issues/PRs references
Fixes PR #18385
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Typically, OpenOCD is already performing a reset on connect. A
`reset halt` to bring the target to a `halt` state for flashing will
result in the device going through a second reset cycle. This can be
problematic with some device, such as the CC26xx MCUs. For these
devices, an `OPENOCD_CMD_RESET_HALT := -c 'halt'` will avoid the second
reset that is causing the issues.
Place common OpenOCD configs for the different cc13xx and cc26xx
families in boards/common/cc26xx_cc13xx/dist and automatically select
the correct one based on the (prefix of the) value of `$(CPU_MODEL)`, if
`OPENOCD_CONFIG` was not specified and no custom `openocd.cfg` is
located in the board's `dist` folder.
The `cc2650-launchpad` and `cc2650stk` have been adapted to use the
common config instead.
This adds the configuration to allow choosing the XDS110 used in
cc13xx-launchpad and cc26xx-launchpad boards via the
`OPENOCD_DEBUG_ADAPTER` variable.
19123: pkg/esp8266_sdk: fix version string generation r=kaspar030 a=gschorcht
### Contribution description
This PR (hopefully) fixes the problem of different binary hashes for the same application in subsequent compilations.
Patching a package creates a new HEAD of the package repository. Using `git describe --tag` to generate a version string used for the ESP8266 bootloader therefore generates a different version string for each new compilation, which in turn results in different hash values of the binaries for the same application in subsequent compilations in CI. To use the commit in `git describe --tag` for commit used by the package, the commit has to specified in the command.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Patching a package creates a new HEAD of the package repository. Using `git describe --tag` to generate a version string used for the ESP8266 bootloader therefore generates a different version string for each new compilation, which in turn results in different hash values of the binaries for the same application in subsequent compilations in CI. To use the commit in `git describe --tag` for commit used by the package, the commit has to specified in the command.
17810: drivers/slipdev: implement sleep states r=benpicco a=benpicco
18348: sys/net/gnrc/pktbuf_static: make use of alignas() r=maribu a=maribu
### Contribution description
Since we are now using C11, we can make use of `alignas()` provided by `<stdalign.h>` to make the alignment code easier to read.
### Testing procedure
I didn't expect this to change binaries, but is safes 4 bytes. `elf_diff` shows that the compiler (at least GCC 11.3.0) was not able to detect that `gnrc_pktbuf_static_buf` was just an alias for `_pktbuf_buf`. That makes sense since it would be hard without LTO to rule out external writes to `gnrc_pktbuf_static_buf`, unless one would have added a `const` (to the pointer, not to the data the pointer points to).
The [output of `elf_diff`](https://mari-bu.de/pr_18348_gnrc_pktbuf_static_elf_diff.html) looks otherwise quite unscary.
Also:
```
$ make BOARD=nucleo-f767zi -C tests/unittests/ tests-pktbuf flash test
make: Entering directory '/home/maribu/Repos/software/RIOT/tests/unittests'
Building application "tests_unittests" for "nucleo-f767zi" with MCU "stm32".
[...]
Welcome to pyterm!
Type '/exit' to exit.
READY
s
START
.............................................
OK (45 tests)
make: Leaving directory '/home/maribu/Repos/software/RIOT/tests/unittests'
```
### Issues/PRs references
None
19120: CI: seperate check-labels and check-commits workflows r=maribu a=kaspar030
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
- document that the QN9080DK has an alternative firmware for the
debugger/programmer that supports J-Link
- allow selecting the debugger firmware via parameter / environment
variable
- add `JLINK_DEVICE` parameter to allow flashing via J-Link
19115: boards/hip-badge: fix doc rendering r=benpicco a=benpicco
19116: makefiles/cargo-targets.inc.mk: Fix RISC-V target r=kaspar030 a=maribu
### Contribution description
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.
### Testing procedure
```
make BOARD=hifive1b -C examples/rust-gcoap
```
Fails on `master` with a recent RISC-V toolchain, but hopefully compiles with this PR.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19109: cpu/gd32v: fix and extend Kconfig clock settings r=benpicco a=gschorcht
### Contribution description
This PR fixes the following issus of the clock configuration which led to highly deviating peripheral clocks so that the UART interface was not usable in my case:
1. Setting the `RCU_CTL` register just to the IRC8M bit also removes the IRC8M calibration and trim adjust value in this register. Therefore IRC8M calibration and trim adjust value have to be preserved and the IRC8M has to be set.
2. `CLOCK_HXTAL` is a value and not a flag, so that shifting to the left changes anything in the register but does not set the PLLSEL bit. `RCU_CFG0_PLLSEL_Msk` has to be used instead to set the PLLSEL bit.
3. `CONFIG_BOARD_HAS_HXTAL` is used to indicate that the board has an HXTAL connected. If the HXTAL is present, it is used as PLL clock source. But if the HXTAL is not present, the half IRC8M clock should be used as PLL clock source and must not be disabled at the end of clock settings. Using IRC8M clock as PLL clock source also requires another PLL multiplication factor.
Issues 1 and 2 led to the problem that IRC8M was used without calibration instead of HXTAL. With the fixes, the GD32V is working with as well as without HXTAL correctly.
Furthermore, the Kconfig configuration has been extended. It is now possible to configure the HXTAL frequency as well, since the GD32VF103 allows HXTAL clocks from 3 MHz to 25 MHz. This has currently been added directly to the board's Kconfig, as it is currently the only GD32VF103 board. It should be moved to a common Kconfig later when more GD32V boards are added.
### Testing procedure
`BOARD=seeedstudio-gd32 make -C tests/shell flash term` should still work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The configuration whether a HXTAL is present and what its clock frequency is will be added to Kconfig. Since it is the only GD32V board at the moment, the configuration is added to the Kconfig of the board, but should be moved to a common Kconfig later when more GD32V boards are added.
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.
19113: boards/native: Drop backward compatibility code for glibc <= 2.17 r=maribu a=maribu
### Contribution description
Even Debian [oldstable is now at glibc 2.28](https://packages.debian.org/source/buster/glibc), so it is safe to assume that nobody needs this anymore.
This also fixes garbage on the terminal on musl systems, where `ldd --version` is not supported (and output on `stderr` was not redirected to `/dev/null`).
### Testing procedure
The CI will check if this breaks the `native` board.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Even Debian oldstable is now at glibc 2.28, so it is safe to assume that
nobody needs this anymore.
This also fixes garbage on the terminal on musl systems, where
`ldd --version` is not supported (and output on `stderr` was not
redirected to `/dev/null`).
19112: cpu/riscv_common/periph_timer: Fix timer_clear() r=benpicco a=maribu
### Contribution description
Previously, timer_clear() was a no-op, resulting in spurious IRQs from already canceled timeouts. This fixes the issue.
### Testing procedure
```
$ make BOARD=hifive1b flash test -C tests/periph_timer
[...]
Welcome to pyterm!
Bench Clock Reset Complete
ATE0-->ATE0
OK
AT+BLEINIT=0-->OK
AT+CWMODE=0-->OK
Help: Press s to start test, r to print it is ready
READY
s
START
main(): This is RIOT! (Version: 2023.01-devel-773-g441b69)
Test for peripheral TIMERs
Available timers: 1
Testing TIMER_0:
TIMER_0: initialization successful
TIMER_0: stopped
TIMER_0: set channel 0 to 5000
TIMER_0: starting
TIMER_0: channel 0 fired at SW count 3164199 - init: 3164199
TEST SUCCEEDED
```
(In `master`, the test fails with a spurious IRQ.)
### Issues/PRs references
https://github.com/RIOT-OS/RIOT/issues/18976
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19090: boards/hamilton: Add minimal doc r=benpicco a=maribu
### Contribution description
The doc of the board is still suboptimal, but at least an image to identify what board this is and a link to further information is a starting point.
### Testing procedure
The static tests will do.
### Issues/PRs references
None.
19111: boards/common/nrf52: Fix detection of JLinkExe r=kaspar030 a=maribu
### Contribution description
For nRF52 J-Link was intended to be preferred as programmer over OpenOCD when both are available, but falling back to OpenOCD when JLinkExe is not found in `$PATH`. However, there was call the shell missing to actually detect `JLinkExe`.
### Testing procedure
E.g. `make BOARD=nrf52840dk -C examples/default flash` should use J-Link again as default when both are installed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
