This re-adds `RIOT_MCU` as alias for `RIOT_CPU` and marks it as
deprecated. That should make life easier for downstream apps that may
still use `RIOT_CPU`.
Adding this macro in the definition of a macro causes a warning about
the deprecation to be emitted when used (and a build failure with
`WERROR=1`). This is useful as no other means to deprecate preprocessor
macros are provided.
The macro will be defined empty for compilers that are not GCC or
clang.
This adds a `riotbuild-prefix.h` that is added to the `riotbuild.h`
and processed by Doxygen. It solves two problems:
1. The pre-defined macros where previously fully undocumented, but
may be useful to real world applications
2. It provides a place where backward compatibility aliases can be
added with a deprecation notice
The Makefile rule to regenerate model.h has been left in place, but
just adding the header to the test allows to build the application
without heaving emlearn installed, which is convenient for the CI.
Actual users of emlearn will like still want to generate the header.
We don't enable this on any other architecture.
-pedantic doesn't give us any more beneficial wanrings, only warns
about language extensions that are implemented by both GCC and Clang
anyway.
Since those are the only compilers we are targeting, we can just make
use of them to make our lives easier.
This explicitly spells out what informally has been the coding
convention for some time on preprocessor directives, making it
more transparent and easier to find.
This is particularly useful as the code base has at least three
different styles. Deducing what actually is the current policy
would require a details look at how the style has changed over
time, rather than being obvious from a quick `grep` over the
code base.
This formats the code to improve readability and apply the coding
convention. This is a whitespace only change that will not change
generated binaries.
Add some tests to verify that when creating or importing keys,
the usage flags PSA_KEY_USAGE_SIGN_HASH/PSA_KEY_USAGE_VERIFY_HASH
automatically set the usage flags PSA_KEY_USAGE_SIGN_MESSAGE/
PSA_KEY_USAGE_VERIFY_MESSAGE on the key.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Specifying the password of the SUIT private key on the command line
and thereby committing it to shell history is a security issue.
Instead ask for the password interactively when an encrypted private
key is used.
This makes it easier to work with encrypted keys and multiple keys.
The firmware binary can contain multiple public keys that are used
to verify the manifest.
The use case is that we want to include the production public key
in the debug build, so we can seamlessly update to the production
version without re-flashing the device.
If the public keys is always generated on the fly, this would still
require the production key password even for the debug build.
Instead if we store the (unencrypted) public key, we can always
include it in the debug build.
