This is still currently a hack to hardcode it as the value can be deduced
from the `BOARD_MODULE` daughter board name.
But it requires more cleanup and could come in a separate step.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
This commit adds an example application showcasing SUIT draft v4
firmware updates.
It includes a test script suitable for local or CI testing.
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Francisco Molina <femolina@uc.cl>
I basically didn't work on `emb6` since 2016 and adapting to the newest
version would mean some major overhaul. However, the development at
their end seems to be stalled [since March 2018][emb6-develop] as well.
All this speaks for deprecating this package.
[emb6-develop]: https://github.com/hso-esk/emb6/tree/develop
The board is deprecated, no need to ignore this board anymore here.
Having the `arduino` and `periph_pwm` features is now required for all
boards using 'arduino-atmega' (as it was except for that board).
If this should change in the future, it should be defined either in each
arduino board, in another board common, or per CPU_MODEL.
Remove the workaround for clang 3.6.2 that did not support
'cortex-m0plus'.
clang 3.8 was already supporting it according to the PR introducing the check.
clang >=3.8 is avaible since ubuntu-xenial and debian-stretch.
The current ubuntu-bionic has clang 6 and debian-buster clang 7.
This removes overwriting 'CPU_ARCH'.
Printing the 'Received ...' string takes a short while and it is possible
that data is received while the string is printed. It seems however that
NimBLE does not like to be without a mbuf ready for taking data while
receiving something, as this seems to lead to a memory leak somehow. Now
changing the order of actions inside the _on_data() function fixes this.
Without this change an attacker would be able to stop the emcute server
by sending a crafted packet triggering this branch. The solution is
using `continue` instead of `return`.
Add a script saving all applications and boards dependency resolution
variables and also aggregated files to compare between both dependencies
handling.
It is slow but should dump everything.
Add a 'dependency-debug' and a 'DEPENDENCY_DEBUG=1' option for
'info-boards-supported' to save some variables used when resolving
dependencies.
Print some some 'sorted' variables to simplify comparing the actual value
when the parsing order changed.
This should help tracking changes introduced when refactoring the
dependency parsing.
