Provide missing GCC atomics helpers as part of BSPs where GCC
does not know how to provide it since the CPU's ISA has no
atomic instructions. The implementation provided in
bsps/shared/atomics/__atomic_test_and_set.c should work
on any single core CPU.
The BSPs that need thie function tend to have older cores. This
is the list of BSPs:
arm - csb336, csb337, csb637, edb7312, gumstix, kit637_v6, lpc24xx_ea,
lpc24xx_ncs_ram, lpc24xx_ncs_rom_ext, lpc24xx_ncs_rom_int,
lpc24xx_plx800_ram, lpc24xx_plx800_rom_int, lpc32xx_mzx,
lpc32xx_mzx_stage_1, lpc32xx_mzx_stage_2, lpc32xx_phycore,
rtl22xx, rtl22xx_t, smdk2410
m68k - av5282, mcf5329
mips - jmr3904
moxie - moxiesim
nios2 - nios2_iss
riscv - grv32i, grv32im, niosvc10lp, noel32im, rv32i, rv32im,
sparc - ut699
GCCC 14 introduced a linking warning about not knowing which
__sync_synchronize implementation to use. The BSPs impacted
are updated in this commit. The suggested correction is to
use -specs to pick up a GCC specific specs file which changes
__sync_synchronize to the desired implementation
__sync_synchronize_MECHANISM. Using this solution ties
the code to GCC 14+ since the spec files are not in GCC 13.
This solution maps __sync_synchronize to a RTEMS specific
__sync_synchronize implementation which avoids using of a
GCC extension and requiring GCC 14+,
Closes#5268
This updates the AArch64 Raspberry Pi BSP to use the watchdog to perform
the system reset instead of attempting to use the PSCI reset which isn't
present on the Raspberry Pi platform.
This reworks the linker script configuration to be more comprehensible
and to remain within the 1GB guaranteed available on all Pi4 systems and
accounting for the memory dedicated to the GPU and the memory dedicated
to the low level firmware.
The following files will be installed during SPARC/GRLIB builds:
- bsps/include/grlib/apbuart-regs.h
- bsps/include/grlib/gptimer-regs.h
- bsps/include/grlib/irqamp-regs.h
- bsps/sparc/include/grlib/io.h
Fix issue #5231
The Motorola MC68040 did not completely implement IEEE754 in hardware.
The FPSP code was required to complete the support. With no more
MC68040 BSPs in RTEMS, this code can be removed.
Updates #5031
Some pkg-config variants perform transformations on the --libs options.
This may lead to completely broken linker options. Provide the LDFLAGS
as a variable. Remove "Ldflags:" since this is an unsupported field.
Update #5169.
This commit adds support for CTU CAN FD controller. The controller
can be initialized from BSP by ctucanfd_initialize() function call.
It also implements the dynamic redistribution of hardware transmission
buffers to CAN stack priority classes in order to avoid possible
priority inversion.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Co-authored-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
This commit adds a support for a simple virtual CAN controller. This
controller can be used to test CAN stack functions and serves as an
inspiration for further controller implementations.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Co-authored-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
This adds support for common full-featured CAN/CAN FD stack to RTEMS.
The API is provided in form the form of the POSIX character driver with
each CAN controller (chip) registered as node into “/dev”
namespace.
The stack utilizes FIFO queues (also called edges) organized
into oriented edges between controller side and application side.
Edges, responsible for message transfers from application to controller
and vice versa, can have different priorities and function as priority
classes.
The stack provides run time configuration options to create new
queues with desired priority, direction and filter, making it
suitable for various applications requirements. There is also a
possibility to configure controller’s characteristics (bit rate,
mode, chip specific ioctl calls). Both blocking and nonblocking mode
is supported.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Co-authored-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
When compilation and linking are performed separately, some platforms
(i.e. RISC-V) may require that ABI flags are provided during the linking
step as well as the compilation step.
This moves the management console implementation into its own file so
that BSPs which do not need it do not carry the code around with them.
Closes#5120
This adds generic JFFS2 interworking code that allows JFFS2 to be used
on top of any flashdev backend. It currently only supports NOR flashdev
backends.
Test the proper serialization of explicit thread priority changes (for
example rtems_task_set_priority()) and thread priority changes carried
out by thread queues (locking protocols such as priority inheritance).
With RTEMS_DEBUG enabled, the new test case fails with an assertion. It
is fixed in a follow up commit.
Update #5159.