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>
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>
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.
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>
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.
`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>
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
18869: cpu/sam0_common/periph: Fix compilation with LLVM r=benpicco a=Teufelchen1
Related to #18851
This fixes an unused function error when compiling the gnrc_networking_mac example using LLVM as toolchain.
The fix works by only including the function when it is actually needed.
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19031: cpu/stm32/periph_timer: implement timer_set() r=benpicco a=maribu
### Contribution description
The fallback implementation of timer_set() in `drivers/periph_common` is known to fail on short relative sets. This adds a robust implementation.
### Testing procedure
Run `tests/periph_timer_short_relative_set` at least a few dozen times (or use https://github.com/RIOT-OS/RIOT/pull/19030 to have a few dozen repetitions of the test case in a single run of the test application). It should now succeed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This fixes test failures in tests/periph_timer_short_relative_set.
Note: This differs a bit from the implementation in e.g. nRF5x or STM32
in that it always briefly pauses the timer. The issue is that when
running the timer can take a few ticks to actually react to the new
compare target. So even if the previously written target is still in
the future, the timer may not fire anyway. Pausing the timer while
setting and setting the target at least one higher than the current
count reliably triggers the IRQ.
19074: cpu/esp8266: build the SDK bootloader from source r=benpicco a=gschorcht
### Contribution description
This PR is a takeover of PR #17043, which is rebased to the current master and includes some corrections that became necessary after rebasing.
**Copied from description of PR #17043:**
We had four versions of pre-built bootloaders for the esp8266 with different settings of logging and color logging. These bootloaders were manually built from the SDK and shipped with RIOT-OS source code. However there are more settings that affect the bootloader build that are relevant to the app or final board that uses this bootloader. In particular, flash size and flash speed is important for the bootloader to be able to load an app from a large partition table at the fastest speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the bootloader. The boot ROM will normally start at a baud rate of 74880 (depending on the crystal installed), so it might make sense to keep the UART output at the same speed so we can debug boot modes and bootloader with the same terminal.
This patch builds the `bootloader.bin` file from the ESP8266 SDK source code. The code is built as a module (`esp8266_bootloader`) which at the moment doesn't generate any object code for the application and only produces a `bootloader.bin` file set to the `BOOTLOADER_BIN` make variable for the `esptool.inc.mk` to flash.
The code needs to be compiled and linked with custom rules defined in the module's Makefile since the `bootloader.bin` is its own separate application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the `$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier for applications or board to provide their own bootloader binary if needed.
As a result of building the bootloader from source we fixed the issue of having a large partition table.
### Testing procedure
Use following command to flash the application with STDIO UART baudrate of 115200 baud.
```
BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
Connect with a terminal programm of your choice (unfortunatly `picocom` and `socat` don't support a baudrate close to 74880), for example:
```
python -m serial.tools.miniterm /dev/ttyUSB0 74880
```
On reset, the `esp8266-esp-12x` node shows the ROM bootloader log output
```
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 6152, room 16
tail 8
chksum 0x6f
load 0x3ffe8008, len 24, room 0
tail 8
chksum 0x86
load 0x3ffe8020, len 3408, room 0
tail 0
chksum 0x79
```
as well as the second-stage bootloader built by this PR (`ESP-IDF v3.1-51-g913a06a9ac3`) at 74880 baudrate.
```
I (42) boot: ESP-IDF v3.1-51-g913a06a9ac3 2nd stage bootloader
I (42) boot: compile time 11:25:03
I (42) boot: SPI Speed : 26.7MHz
...
I (151) boot: Loaded app from partition at offset 0x10000
```
The application output is seen as garbage since the `esp8266-esp-12x` uses 115200 as baurate by default.
To see all output at a baudrate of 74880 baud, you can use the following command:
```
CFLAGS='-DSTDIO_UART_BAUDRATE=74880' BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
If the application is built without options, the ROOM bootloader output will be 74880 baud and the second stage bootloader and application output will be 115200 baud.
### Issues/PRs references
Fixes issue #16402
Co-authored-by: iosabi <iosabi@protonmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19078: cpu/esp32: define FLASHFILE_POS r=benpicco a=gschorcht
### Contribution description
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
This PR is a prerequisite for the `periph_flashpage` implementation PR #19079.
### Testing procedure
Flashing a ESP32x SoC should work with `FLASHFILE_POS=0x20000`, for example:
```
USEMODULE=esp_log_startup FLASHFILE_POS=0x20000 BOARD=esp32-wroom-32 make -j8 -C tests/shell flash
```
The bootloader output should give `00020000` as offset for the `factory` partition
```
I (75) boot: Partition Table:
I (78) boot: ## Label Usage Type ST Offset Length
I (84) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (91) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (97) boot: 2 factory factory app 00 00 00020000 000199b0
I (104) boot: End of partition table
```
and
```
I (125) esp_image: segment 0: paddr=00020020 vaddr=3f400020 size=02140h ( 8512) map
```
during the load of the image.
### Issues/PRs references
Prerequisite for PR #19079
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19077: cpu/esp32: configurable linker scripts r=benpicco a=gschorcht
### Contribution description
This PR provides configurable linker scripts for ESP32x SoCs.
Using the vendor `memory.ld.in` file and a `sections.ld.in` file instead of the static versions of these files, from which the actual used `memory.ld` and `sections.ld` are generated using the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to define a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Note for the review: The `memory.ld.in` files are now simply copies of the manufacturer's `memory.ld.in` files. However, it is not possible to use the vendor's `memory.ld.in` files directly, because they have to be extended further on, e.g. for the `periph_flashpage` implementation.
This PR is prerequisite for the `periph_flashpage` support in PR #19079.
### Testing procedure
Green CI.
### Issues/PRs references
Prerequisite for PR #19079
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Using `sectoins.ld.in` instead of a static `sections.ld`, from which the actual used `sections.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom section layout.
Using the vendor `memory.ld.in` instead of a static `memory.ld`, from which the actual used `memory.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
19064: native: Remove code used for __MACH__ target r=benpicco a=Teufelchen1
### Contribution description
This PR removes code that was used to support macOS as native target.
macOS / `__MACH__` is no longer supported by RIOT on master.
### Testing procedure
If murdock is happy, that should be enough.
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
