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.
The devfg driver loads the PL with a bitfile image. The driver can also
support scrubbing.
These drivers are from Patrick Gauvin <pggauvin at gmail.com> and a thread
on the devel list: https://lists.rtems.org/pipermail/devel/2017-May/017705.html
The general optclkbootcpu option is targeted at all ARM QEMU BSPs, but
is not actually linked in to the build tree. This links it in as
expected and removes a redundant and stale copy in the realview PBX BSP.
This removes the headers imported from the embeddedsw repository in
favor of a much thinner shim. This also removes the complicated build
system configuration necessary to support use of these headers. The
primary reason for removal is that certain external Xilinx libraries
also require use of these headers and this causes version mismatches and
header conflicts that can be avoided.
- Add support for four new ports, UART2-UART5.
- Add build options to allow console device configuration.
- Segregate device-specific definitions from the device family files. X macros
are used to maintain a single source of truth and have the configuration
done at compile-time
- Add raspberrypi_uart_init() to make it convenient for users to install uart
devices
Close#5130
Co-authored-by: Ning Yang <yangn0@qq.com>
This removes the xilinx and lp64 identifiers from the ZynqMP BSPs and
updates those names throughout the build system. The xilinx identifier
is being removed because it is implied by zynqmp and lp64 is being
removed because it is the default for AArch64.
This also renames grp_zu3eg.yml to grp_hardware.yml to more accurately
reflect its purpose.
Updates #5119
Now that minimum.exe is minimum.norun.exe, the tester will not attempt
to run this sample test and will therefore not categorize it as a
failure since it includes no output. BSP-level test configurations for
this test can now be removed since those configurations only existed to
prevent it from being run.
