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.
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
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>
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.
The `usbdev_synopsys_dwc2 driver` requires the `ztimer_msec` module and is therefore responsible for pulling it in. Therefore, the dependency on `ztimer_msec` can be removed here.
The definition in `pkg/esp32_sdk/Makefile.include` was evaluated by
`make` after the include paths were already set, resulting in
`ESP32_SDK_DIR` being empty in
INCLUDES += -I$(ESP32_SDK_DIR)/components
[...]
This in turn resulted in
cc1: error: /components: No such file or directory [-Werror=missing-include-dirs]
[...]
This file is an excerpt of STM32 header file `stm32/smsis/f7/include/stm32f767xx.h` since the ESP32x SoCs use the same Synopsys DWC2 IP core as USB peripherals.
Since `esp_can.h` is included by main `cpu/esp32/include/periph_cpu.h` after the include of the specific `periph_cpu_$(CPU_FAM)`, it is not necessary to include `esp_can.h` in each specific `periph_cpu_$(CPU_FAM)`.
With the improvements of the locking mechanism, thread safety of malloc/realloc/calloc/free is guaranteed. Module malloc_thread_safe is not needed any longer.
