Failing to provide any of the required features can provide a message
such as:
There are unsatisfied feature requirements: periph_uart|periph_lpuart
This can be confusing and may hide the actual. E.g. above message
was generated when using SPI on the `msb-430` and `stdio_uart`. However,
the MSB-430 board *does* provide `periph_uart`, so this looks like a bug
in the feature resolution. This changes the failure mode of
`FEATURES_REQUIRED_ANY` to just pick the first of the alternatives
given if none of the alternative is usable, which gives in the example
the following message instead:
The following features may conflict: periph_spi periph_uart
Rationale: Both SPI and UART are provided by the same USART
peripheral
The output is less surprising and can provide non-obvious reasons
why `FEATURES_REQUIRED_ANY` failed to pick a feature. The downside is
that the alternatives are no longer visible. However, that output
likely was so confusing this might be for the best.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Before we disabled the warning about RWX segments only for picolibc,
but this issue is popping up on more and more toolchains (looking
at MSP430 and RISC-V). Other than on `native`/`native64`, there is no
MMU to enforce whatever permissions the segments contain anyway.
(And writing to ROM with regular store instructions will not be possible
even without the need for an MMU.)
So let's just globally disable this warning, unless building for
`native` and `native64`.
The legacy `riscv-none-embed` target triple is incorrect and the
toolchain using it has long been obsolete. With our CI no longer
using the obsolete toolchain, there is no need to handle that one
anymore.
The CI now uses `riscv-none-elf` over the previous (and technically
incorrect) `riscv-none-embed`. In addition, we no longer probe for
host toolchains with the incorrect target triple, as the source
providing it has long declared the toolchain with the incorrect
triple as obsolete.
This adds mspdebug as package, similar to EDBG, so that the
programmer/debugger is build from source.
This has the advantage that we can indeed provide patches of our own.
The first patch fixes a bug with the CPU detection of `mspdebug` in
combination with the Olimex MSP430-JTAG-TINY-V2. The second adds the
`--expect-id <CPU_NAME>` argument.
The RIOT integration is updated to directly make use of the
`--expect-id` parameter. No more spending time debugging why firmware
the firmware for the `olimex-msp430-h2618` doesn't run when flashed on
the `olimex-msp430h1611` hardware :D
