Skip to content

qcom-rtss-can: add recipe for RTSS CAN userspace deamon - #3104

Draft
q-AnupKulkarni wants to merge 1 commit into
qualcomm-linux:masterfrom
q-AnupKulkarni:anupkulk/rtss_can
Draft

qcom-rtss-can: add recipe for RTSS CAN userspace deamon#3104
q-AnupKulkarni wants to merge 1 commit into
qualcomm-linux:masterfrom
q-AnupKulkarni:anupkulk/rtss_can

Conversation

@q-AnupKulkarni

@q-AnupKulkarni q-AnupKulkarni commented Sep 9, 2026

Copy link
Copy Markdown

Target milestone: qli-2.1 pull-request freeze

Background

The RTSS subsystem on Qualcomm SoCs includes a dedicated CAN controller that is not directly accessible from the Linux CAN stack. This recipe builds rtss_can, a userspace daemon that bridges that gap by routing traffic between Linux SocketCAN virtual interfaces and RTSS mailbox channels, allowing standard SocketCAN applications to communicate with CAN hardware managed by RTSS. The daemon depends on qcom-rtss-mailbox-umd for the librtss_mailbox interface and on linux-libc-headers for the SocketCAN kernel UAPI headers (linux/can.h, linux/can/raw.h).

PR dependency

#3084

Tracking

#3123

Testing

Default bootup verified on lemans and monaco targets.

Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated

@lumag Dmitry Baryshkov (lumag) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the decision during the RTSS meeting regarding CAN daemon?

Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated

@lumag Dmitry Baryshkov (lumag) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qcom-rtss-can: align recipe with Yocto conventions

No. Squash your commits. Fix your git setup.

@q-AnupKulkarni
q-AnupKulkarni force-pushed the anupkulk/rtss_can branch 2 times, most recently from bffbbb1 to d10f1db Compare September 10, 2026 19:27
daemon

The RTSS subsystem on Qualcomm SoCs includes a dedicated CAN controller
that is not directly accessible from the Linux CAN stack. This recipe
builds rtss_can, a userspace daemon that bridges that gap by routing
traffic between Linux SocketCAN virtual interfaces and RTSS mailbox
channels, allowing standard SocketCAN applications to communicate with
CAN hardware managed by RTSS.

The daemon depends on qcom-rtss-mailbox-umd for the librtss_mailbox
interface and on linux-libc-headers for the SocketCAN kernel UAPI
headers (linux/can.h, linux/can/raw.h).

Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
@q-AnupKulkarni

Copy link
Copy Markdown
Author

qcom-rtss-can: align recipe with Yocto conventions

No. Squash your commits. Fix your git setup.

Done

@q-AnupKulkarni

Copy link
Copy Markdown
Author

What was the decision during the RTSS meeting regarding CAN daemon?

Part of phase-1 deliveries

Phase 1 |
• User-space Mailbox IPC and UMD utilities• User-space CAN ↔ SocketCAN ↔ User-space daemon loopback (vCAN ↔ Mailbox ↔ RTSS)

Tracked here - #3123

DEPENDS = "glib-2.0 qcom-rtss-mailbox-umd linux-libc-headers"

SRC_URI = "git://github.com/qualcomm/rtss-can.git;branch=rtss-can.le.1.0;protocol=https;tag=v${PV}"
SRCREV = "50c719138277f8e1135e04fd4e9137446823e726"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit hash is not the tag, it should be qualcomm/rtss-can@78ba248.

LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=223037c4be0bfc6cf757035432adf983"

DEPENDS = "glib-2.0 qcom-rtss-mailbox-umd linux-libc-headers"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qcom-rtss-mailbox-umd not yet available, moving PR to draft.

-DSYSROOT_INCLUDEDIR=${STAGING_INCDIR} \
-DSTAGING_LIBDIR=${STAGING_LIBDIR}"

RDEPENDS:${PN} = "can-utils qcom-rtss-mailbox-umd can-utils-access"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can-utils is from meta-oe, needs to move to dynamic layers.

DESCRIPTION = "Userspace daemon acting as a gateway between SocketCAN \
applications and RTSS using the RTSS mailbox UMD libraries."

HOMEPAGE = "https://github.com/qualcomm/rtss-can"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it aarch64 only? If so, needs a compatible machine line.

@ricardosalveti

Copy link
Copy Markdown
Contributor

Functional gaps at runtime:

  • vcan is never available. The daemon needs the vcan module, but no meta-qcom kernel config enables CONFIG_CAN_VCAN, so the RRECOMMENDS is a no-op and the daemon fails at init.
  • Runtime deps are wrong. It omits the can-gw and rtss-mailbox kernel modules plus iproute2 and kmod for its shell-outs, while the bare can-utils entry is redundant since the only binary used is cangw from can-utils-access.
  • Nothing starts the daemon. The systemd unit from earlier revisions was dropped and upstream ships none, so the package installs a binary that never runs. Either ship a unit or state in the commit that phase 1 excludes auto-start.

Cleanups:

  • Dead build inputs. All three EXTRA_OECMAKE flags and the linux-libc-headers DEPENDS do nothing: the include vars duplicate what cmake.bbclass already provides, STAGING_LIBDIR is unreferenced upstream, and the headers come in via glibc.

@lumag

Copy link
Copy Markdown
Contributor

What was the decision during the RTSS meeting regarding CAN daemon?

Part of phase-1 deliveries

Phase 1 | • User-space Mailbox IPC and UMD utilities• User-space CAN ↔ SocketCAN ↔ User-space daemon loopback (vCAN ↔ Mailbox ↔ RTSS)

Tracked here - #3123

That's not what I meant. What is the agreed ETA for the in-kernel replacement driver?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants