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>
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>
19110: boards/hifive1b: minor improvements r=kaspar030 a=maribu
### Contribution description
- Cleaning up flash config
- Only defaulting to J-Link as flasher when actually installed
- Add TTY_BOARD_FILTER to more reliably select the TTY of the HiFive1b board
### Testing procedure
- Flashing should still work
- Flashing should prefer J-Link over OpenOCD when both are available
- Flashing should prefer OpenOCD over J-Link when J-Link is not found
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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`.
- OpenOCD and J-Link flash configuration can be provided
unconditionally, as those variables do not conflict with any others
- Only use J-Link as default flasher if actually installed
`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.
`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.
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.
19106: core/lib: Add macros/utils.h header r=aabadie a=maribu
### Contribution description
The macros CONCAT(), MIN(), and MAX() are defined over and over again in RIOT's code base. This de-duplicates the code by moving the macros to a common place.
### Testing procedure
Generated binaries don't change, as this only a de-duplication of macros that doesn't change their definition.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19099: dist/tools/usb-serial: Clean up legacy scripts r=aabadie a=maribu
### Contribution description
Refactor the old bash scripts to use `ttys.py` instead and update the documentation.
### Testing procedure
The pi fleet should still work without modification.
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/15814
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
18752: nanocoap_sock: deprecate nanocoap_get() r=benpicco a=benpicco
19100: cpu/esp_common: allow configuration of UART0 r=benpicco a=gschorcht
### Contribution description
This PR
- fixes the issue for ESP32 SoCs that UART0 signals can't be routed to arbitrary GPIOs and
- allows the configuration of the UART device used by the bootloader.
The UART interface and its configuration used by the STDIO are defined in RIOT using the define `STDIO_UART_DEV` and the configuration of the corresponding UART device in `periph_conf.h`.
However, the bootloader compiled directly in ESP-IDF uses its own definitions `CONFIG_ESP_CONSOLE_UART_*` for the UART configuration. To be able to use a consistent UART configuration in RIOT and the bootloader, e.g. to see the output of the 2nd stage bootloader, these `CONFIG_ESP_CONSOLE_UART_*` can be defined via a set of KConfig variables in RIOT (not yet implemented in Kconfig):
- `CONSOLE_CONFIG_UART_NUM` defines the UART device to be used by the bootloader and by `STDIO_UART_DEV`
- `CONSOLE_CONFIG_UART_RX` and `CONSOLE_CONFIG_UART_TX` define the GPIOs to be used by the bootloader and should be the GPIOs as defined in `periph_conf.h` for the corresponding UART device.
### Testing procedure
Any ESP32 node should still work with `stdio_uart` and the default configuration. To test an alternative configuration, use
```
CFLAGS='-DUART1_TXD=5 -DUART1_RXD=4 -DCONFIG_CONSOLE_UART_NUM=1 -DCONFIG_CONSOLE_UART_TX=5 -DCONFIG_CONSOLE_UART_RX=4' USEMODULE=esp_log_startup BOARD=esp32-wroom-32 make -C tests/shell flash
```
The bootloader output and the STDIO should be routed to UART1 at GPIO4 and GPIO5.
### Issues/PRs references
Prerequisite for PR ##18863
19104: tests/periph_uart: only exclude STDIO_UART_DEV if stdio_uart is used r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
The UART interface and its configuration as used by the STDIO is defined in RIOT using `STDIO_UART_DEV` and the UART configuration in `periph_conf.h`.
However, the bootloader compiled directly in ESP-IDF uses its own definitions `CONFIG_ESP_CONSOLE_UART_*` for the UART configuration. To be able to use a consistent UART configuration in RIOT and the bootloader, e.g. to see the output of the 2nd stage bootloader, these `CONFIG_ESP_CONSOLE_UART_*` can be defined via a set of KConfig variables `CONSOLE_CONFIG_UART_*`. Here the variable `CONSOLE_CONFIG_UART_NUM` is then also used as `STDIO_UART_DEV` and the variables `CONSOLE_CONFIG_UART_RX` and `CONSOLE_CONFIG_UART_TX` of the configuration in `periph_conf.h` should be used accordingly.
f
19095: boards/hamilton: Fix TMP00x parameters r=benpicco a=maribu
### Contribution description
The TMP006 driver has been renamed to TMP00x, as it (now) supports both TMP006 and TMP007 infrared thermopile sensors. However, the board configuration was never updated to match the new names. This fixes the issue.
### Testing procedure
Someone with the board could test if the TMP006 driver now starts to work again. Otherwise, it should be relatively straight forward to "test this by code review" (tm).
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
