newlib and picolibc already implicitly add the `0x` prefix for `%p` just
as glibc does, and some of our tests scripts depend on this.
(And subjectively, this looks better.)
This adds https://github.com/mpaland/printf/pull/90 on top of our
patches.
This avoids inconsistent output when external code gets linked in that
directly links against newlib's assert implementation (e.g. binary blobs
or packages that do not add `core/lib/include` to the include paths).
This also greatly benefits wrapping printf, as newlib's `__assert_func()`
directly links to internal printf functions of newlib.
Co-authored-by: crasbe <crasbe@gmail.com>
- `arch_64bit` depends on long long support (rather than just enabling
it by default), as otherwise `%p` will not work correctly
==> add hard dependency
- On 32 bit platforms support of printing long long is not almost free
==> do not enable long long on `arch_32bit` by default
- The ESP SDK contains binary blobs that already link against newlib and
mpaland-printf is not ABI compatible with newlib's stdio, it is only
API compatible.
==> mark mpaland-printf as incompatible to ESP MCUs
Co-authored-by: crasbe <crasbe@gmail.com>
This package seems to implement the [qDSA signature scheme][1], which
seemed to not have received the level of attention and scrutiny from the
crypto community one would expect before adopting it outside of lab
environments and experiments.
Hence, it might be better hosted on a repo that focuses exclusively on
research, rather than in a repo of a general purpose OS that is intended
to be used outside of lab environments as well.
[1]: https://link.springer.com/chapter/10.1007/978-3-319-70697-9_10
Currently PSA mac backends can only implement psa_mac_compute() from
the PSA crypto API, but not psa_mac_verify() and the associated
multi-part functions.
Extend the location and algorithm dispatchers to connect the above
PSA API functions to suitable backends. Also extend the MAC backend
API to allow backends to implement those additional functions. Due
to a design issue with the SE backend API (context size is dynamic,
thus requiring a memory allocation) only psa_mac_verify() can be
accelerated by SE backends.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Nimble still implements the legacy netdev API.
The `netdev_legacy_api` must be explicitly used, otherwise other network
drivers that use the new API will overwrite it also for nimble.
See #18426.
The `esptool.py` program is no longer installed as a RIOT package, but as a pure Python package, as published by Espressif. The installation takes place in a virtual Python environment in the `dist/tools/esptools/venv` directory. Therfore, there is no need to pull the GitHub repository and thus not necessary to install it as a RIOT package.
It makes no sense to have a separate `esp_ble_$(CPU_FAM)` feature for each ESP32x variant. The ESP32x has either a BLE controller or not. Therefore, a single common `esp_ble` feature is sufficient.
nimble_port_initialized` is false by default and is set to true as soon as
Adds a variable that indicates whether `nimble_port_init` has been called by `nimble_riot_init`, i.e. that the NimBLE stack has been initialized. The variable can be used to decide whether events from the low-level BLE controller driver should be forwarded to the NimBLE stack. It is necessary to avoid crashes in the case that the higher-prioritized thread of the low-level BLE controller driver starts sending events to the host before the NimBLE stack has been initialized by the lower-prioritized host thread.
BLE library for ESP32x implements its own version of `os_msys_init`, which is used by the BLE controller implementation for ESP32x and is implicitly called when the BLE controller is enabled.
BLE library for ESP32x defines its own `g_msys_pool_list` in binary libraries. To avoid multiple definitions, the definition of `g_msys_pool_list` is conditional here.
To be able to control whether `default_CSPNRG` is used or not during compilation, `define_RNG_default` is defined conditionally. This is needed for example to compile BLE for ESP32-H2.