This fixes issues with `make compile-commands`, as this by default
generates clangd/LLVM compatible flags. Without `TARGET_ARCH_LLVM`
exported, this will fall back to `TARGET_ARCH`, which is different
for LLVM and GCC.
19791: makefiles/arch/riscv.inc.mk: speed up toolchain detection r=benpicco a=maribu
### Contribution description
- Use a sane (a.k.a. simply expanded) variable for the `$(TARGET_ARCH)` instead of an insane (a.k.a. recursive expended) variable - The toolchain detection will now happen only once, rather than each and every time `$(TARGET_ARCH)` is referenced
- Use a single call to `which` rather than one per possible target triple
Fixes https://github.com/RIOT-OS/RIOT/issues/19788
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
The MSP430 vendor files already provide macros containing register
constants and symbols (provided via linker scripts) containing addresses
of peripheral registers. So lets make use of that rather than
maintaining a long list of constants.
- Use a sane (a.k.a. simply expanded) variable for the `$(TARGET_ARCH)`
instead of an insane (a.k.a. recursive expended) variable
- The toolchain detection will now happen only once, rather than
each and every time `$(TARGET_ARCH)` is referenced
- Use a single call to `which` rather than one per possible target
triple
Fixes https://github.com/RIOT-OS/RIOT/issues/19788
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
GCC 12 gives out of bounds warnings when the resulting address is out
of bounds of what GCC assumes to be the valid address space. It seems
that by default the address 0x0 is not considered valid (which would
be a NULL pointer and typically not mapped in a userspace behind an MMU
scenario), but in fact is valid on bare metal hardware. At least on
AVR and MSP430 this needs to be set. On many Cortex M MCUs 0x0 is also
a valid address (e.g. often the flash is mapped there), but seemingly
for them `--param=min-pagesize=0` is already the default. In any case,
it won't hurt to set it explicit for them as well.
An `INSERT AFTER` directive no longer can refer to a different linker
script included with `-T path/to/script.ld`. Instead, this adds wrapper
linker scripts that just `INCLUDE` the three individual linker scripts.
This way, the xfa.ld can safely refer back to sections defined in
the vendor linker script.
For some reason, this approach cause the exact issue it fixes for
binutils 2.40 with the binutils in the CI. We stick with the old
linker flags with binutils prior 2.40 to be compatible with both
conflicting behaviors.
The best approach would be to come up with something that works across
different versions of binutils; but no such solution materialized.
With RISC-V being a relatively young toolchain, a lot of inconsistencies
between different toolchains are to be found that differ in the target
triple and the flags supported. This build system performs run-time
tests to detect the toolchain and supported flags.
With `BUILD_IN_DOCKER=1` issues arise, as this checks are performed
outside of the docker container. However, the host may have no RISC-V
toolchain installed or a different toolchain, so there is little reason
in performing this detection then. Instead, a hard coded target triple
and supported flags are provided when using `BUILD_IN_DOCKER=1`.
Use -misa-spec=2.2 on newer toolchains, which allows passing the same
-march value to both the linker and the compiler even when binutils and
GCC support difference ISA specs.
A backward incompatible change in the RISC-V resulting in instructions
previously included by rv32imac to only be available with
rv32imac_zicsr. All RISC-V CPUs supported by RIOT are hence either
considered as rv32imac (from the old ISA spec point of view) or as
rv32imac_zicsr (from the new ISA spec point of view). This adds a
simple test if GCC understands rv32imac_zicsr and uses it then as march,
but uses rv32imac as march if not.
This flag disables all builtin functions provided by the compiler as
well as disabling all optimizations and error checking related to
standard C library functions. If you're using a C library which
conforms to the ANSI C standard, you want to leave these compiler
features enabled.
Signed-off-by: Keith Packard <keithp@keithp.com>
For RISC-V and Cortex-M-not-3, triples are known and have worked in some
configuration, but do not work at the moment and stay disabled until the
reference platforms (native, M3) have been established well.
The xfa.ld script is incompatible with binutils > 2.35.2 and results
in firmwares that wont boot. Sadly, I couldn't figure out an elegant
way to fix the issue. Instead, I modified the linker script provided
by binutils to also include XFA.
Introduce XMEGA EBI driver. This enable EBI for use with all memory
supported by the device and peripherals. It include support to SRAM,
SDRAM, LCDs or any other external bus access.
Note: This feature only works for A1/A1U series, which are, the series
with EBI hardware.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
The current script doesn't allow change script path and name.
Add LDSCRIPT_COMPAT_PATH and LDSCRIPT_COMPAT_NAME default
values to allow a unique path inside atxmega folder.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Atmel AVR-8 CPU was reworked to accomodate variants like ATxmega.
This rename to atmega.inc.mk to avr8.inc.mk to be compliant with
new directory structure.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
This requires -nostartfiles to be only passed to the linker, not the
compiler, as it is a linker flag and passing it to the compiler causes a
clang warning to be emitted.
Additionally, clang does not seem to support `-mcmodel=medlow` and
`-msmall-data-limit=8` but these options do not seem strictly necessary
to me anyhow thus they are deactivated conditionally when using clang.
Split out Gunar Schorcht's clever approach to provide thread safe malloc for
AVR into a system module and make AVR depend on this. This allows other
platforms to also use this.
