cpu/esp*,pkg/esp*: fix compilation with GCC 12.2.0 and newlib 4.x

[maribu]

Contribution description

Some trivial compilation fixes. These won't change generated binaries for older versions of GCC, but fixes compilation for newer versions that are a bit more pedantic in regard to types.

Testing procedure

Generated binaries should not change.

Issues/PRs references

• Depends on and includes cpu/esp_common/periph_uart: fix call to _uart_set_mode #18720

[riot-ci]

Murdock results

❌ FAILED

8066eba cpu/esp8266: fixes for compilation with GCC 12.2.0

Build failures (9)

Application	Target	Toolchain	Runtime (s)	Worker
examples/nimble_gatt	esp32-wroom-32	gnu	12.40	mobi7
examples/nimble_heart_rate_sensor	esp32-wroom-32	gnu	4.69	beast
examples/nimble_scanner	esp32-wroom-32	gnu	10.39	mobi7
tests/nimble_autoconn_gnrc	esp32-wroom-32	gnu	4.34	beast
tests/nimble_l2cap	esp32-wroom-32	gnu	4.43	beast
tests/nimble_l2cap_server	esp32-wroom-32	gnu	7.88	beast
tests/nimble_rpble_gnrc	esp32-wroom-32	gnu	10.07	beast
tests/nimble_statconn_gnrc	esp32-wroom-32	gnu	10.14	mobi7
tests/shell_ble	esp32-wroom-32	gnu	4.68	beast

Artifacts

This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.

There are many more compilation issues that I want to add to this PR. I should have added a WIP label :/

[gschorcht]

Wow, from where did you get this GCC version for ESP32? The official ESP32 GCC version is still 8.4.0.

[maribu]

It is hand baked; I'm intending to provide the packages for Alpine once they work as I hope for.

For Arch Linux 12.2.0 is already available via the AUR: https://aur.archlinux.org/packages/xtensa-esp32-elf-gcc

[gschorcht]

It is hand baked; I'm intending to provide the packages for Alpine once they work as I hope for.

In the past I also compiled the toolchain (GCC version 5.2.0) especially for RIOT using crosstool-ng. I had also tried it with GCC version 8.4.0 while upgrading the RIOT port to ESP-IDF version 4.4. But I had a lot of trouble with the ESP-IDF when the settings in crosstool-ng were not exactly the same as used by Espressif, especially regarding the retargetable locking, the thread model and the POSIX threads. Therefore, I am really glad that we are now using the toolchain as provided by the vendor.

Therefore, the question is whether it wouldn't be better to use the same GCC version as the vendor uses for the SDK? It is not our task to fix compile problems with newer GCC version in the SDK.

For Arch Linux 12.2.0 is already available via the AUR: https://aur.archlinux.org/packages/xtensa-esp32-elf-gcc

If I interpret the comment correctly, the Arch Linux gcc 12.2 for xtensa esp32 is intended for bare metal implementations and not for use with ESP-IDF.

[gschorcht]

Is this really an issue or just a cleanup?

[maribu]

It is an issue: uint32_t can also be unsinged long on 32 bit systems - and apparently is here. This causes GCC to complain about mismatching type and format specifier.

[gschorcht]

Ok, I see. In former GCC versions using %u and %x was working since uint32_t is unsigned int on Xtensa-based ESP32x SoCs.

[maribu]

This is too much WIP to be rushed into the next release anyway. So lets give other PRs the CI time instead.

[gschorcht]

I have cherry-picked the commits for ESP8266 and tried to compile it with the latest toolchain version provided by Espressif. Unfortunatly it seems that they use POSIX threads so that the linking process fails because of unknown references to pthread_* 😟

In the toolchain version I provided, I disabled the POSIX threads. But this version becomes pretty old now. So the question is how we should continue with the toolchain for ESP8266. The options are:

1. build and provide the latest version with crosstool-NG without POSIX threads
2. use the latest version from Espressif and provide a pthread library as the SDK does
3. use the Ubuntu toolchain version (Ubuntu 22.04 comes with xtensa-lx106-elf version 10.3 and the picolibc)

Option 1 would have the advantage that we can control the settings when building the toolchain. When thinking about option 2, I'm wondering whether we could compile the SDK code directly from SDK source in furture as we do for ESP32. But this would require a lot of work. Option 3 would only work on native Ubuntu systems or in riotdocker.

[gschorcht]

Too bad, Ubuntu 22.04 doesn't provide a libstdc++-dev package for xtensa-lx106-elf.

[maribu]

@gschorcht has already fixed theses issues, so this is no longer relevant