To allow CPU specific definitions in `cpu.h`, `riscv_common/cpu.h` is renamed to ``riscv_common/cpu_common.h` and included in new `cpu.h` files for FE310 and GD32V.
19341: Picolibc updates r=benpicco a=keith-packard
### Contribution description
Minor updates to picolibc support for newer versions of picolibc, including 1.8.
### Testing procedure
Here's the current build result for a board I happen to have on my bench right now:
```
$ make -C examples/blinky BOARD=nucleo-f103rb FEATURES_REQUIRED=picolibc
...
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:319:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
319 | _READ_WRITE_RETURN_TYPE read(int fd, void *dest, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:351:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
351 | _READ_WRITE_RETURN_TYPE write(int fd, const void *src, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
...
```
### Description of changes
1. Fix the read/write return values (Picolibc 1.8 uses POSIX standard types now)
2. Add new symbols to linker scripts (Picolibc needs help dealing with TLS alignment)
3. Align stack and thread local storage block during thread setup.
19345: cpu/riscv_common: convert to uword_t usage r=benpicco a=dylad
### Contribution description
This PR makes use of `uword_t` type in a few places in `cpu/riscv_common`.
This should not have any effect on produced binaries.
### Testing procedure
CI should be enough.
### Issues/PRs references
Quickly adapt from #16994. It will help for 64 bits support one day ;)
Co-authored-by: Keith Packard <keithp@keithp.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Newer picolibc versions require some additional symbols defined in the
linker script to correctly manage alignment constraints on thread
local storage.
Signed-off-by: Keith Packard <keithp@keithp.com>
`addi` with 20 bit immediate does not have a compressed representation,
so using `jalr` with immediate offset uncompressed is smaller than using
`addi`+`c.jr`
Since commit 3a11b1fbd2 (#16972)
building RIOT applications with `BOARD=hifive1` causes the following
linker error to be emitted on my system:
/opt/rv32imc/lib/gcc/riscv32-unknown-elf/10.2.0/../../../../riscv32-unknown-elf/bin/ld:riscv_base.ld:220: warning: memory region `rom' not declared
This is due to the fact that the RISC-V linker script doesn't have a rom
memory region. While many other ARM-based boards have a rom memory
region defined in the linker script, the corresponding region name in
the RISC-V linker script is flash and rom is not declared as a memory
region hence the warning.
I think this was accidentally overlooked in
3a11b1fbd2. It is fixed in this commit by
replacing the rom region with the flash region. The linker script
identifiers (e.g. _srom and _erom) are not renamed.
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 handle_trap function is used internally by the trap_entry
implementation from the same file. However, the trap_entry
implementation calls handle_trap from inline assembly. This makes it
difficult for the compiler to infer that the handle_trap function is
used at all. This causes issues when LTO is enabled.
Without this patch compiling any RISC-V RIOT code with `LTO=1` causes
the following linker error:
/home/soeren/src/RIOT/cpu/riscv_common/irq_arch.c:134: undefined reference to `handle_trap'
/tmp/hello-world.elf.Nngidp.ltrans0.ltrans.o:cpu/riscv_common/irq_arch.c:134:(.text.trap_entry+0x34):
relocation truncated to fit: R_RISCV_GPREL_I against undefined symbol `handle_trap'
This commit fixes LTO support for RISC-V.
While at it, also mark the function as static as it is only used by the
trap_entry function from the same compilation unit.
read_csr() returns an unsigned long, not a uint32_t. This causes a
-Wformat warning to be emitted when compiling with clang. This commit
fixes the warning by changing the format string.
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.
