Skip to content

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

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

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 3 times, most recently from d10f1db to 5689383 Compare September 10, 2026 19:27
@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

Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
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.

Comment thread recipes-support/qcom-rtss-can/qcom-rtss-can_1.0.0.bb Outdated
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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Added for the compatible machines.
COMPATIBLE_MACHINE = "qcs9100-ride-sx|qcs8300-ride-sx|iq-9075-evk|iq-8275-evk"

@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?

@q-AnupKulkarni

Copy link
Copy Markdown
Author

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.

Handled it in the updated commit.

@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

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

Part of phase-2 and phase-3 timelines

Phase 2 | • RTSS Mailbox transition to upstream solution • Socket CAN migration Start | Q1'27
Phase 3 | • Upstream RTSS Mailbox, or RpMsg if throughput requirements are met. If RPMsg does not satisfy performance needs, both solutions will be maintained. • Evaluation of emerging VirtIO-based CAN efforts from the community to align Qualcomm's upstream direction. • CAN upstream-aligned solution | Q2-Q3'27

@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.

-SRCREV = "c7ba2c41bbca75699c44d1c9f25890b8efa0c9c1"
+SRCREV = "58d7a517e49d47ecccf055f00c1a0e60fe9448d9"

Did you again just moved the tag? Were you not told not to do it? Grrrrr!

@q-AnupKulkarni

Copy link
Copy Markdown
Author
-SRCREV = "c7ba2c41bbca75699c44d1c9f25890b8efa0c9c1"
+SRCREV = "58d7a517e49d47ecccf055f00c1a0e60fe9448d9"

Did you again just moved the tag? Were you not told not to do it? Grrrrr!

Had added to support few changes, non-critical changes. Reverting it back for now.
Will add once with few other changes, with tag updated after the initial PR is merged.

@lumag

Copy link
Copy Markdown
Contributor

Had added to support few changes, non-critical changes

That's fine, just tag them with new tags rather than using the old one.

@q-AnupKulkarni

Copy link
Copy Markdown
Author

Had added to support few changes, non-critical changes

That's fine, just tag them with new tags rather than using the old one.

Will add few more changes and add new tag after.
Please help review if any further changes are needed? Should I move the PR out of draft ?

@lumag

Copy link
Copy Markdown
Contributor

Should I move the PR out of draft ?

Only if it can be merged.

@q-AnupKulkarni

Copy link
Copy Markdown
Author

Should I move the PR out of draft ?

Only if it can be merged.

Yes.
Cuurrent github build is failing due to unaavailbility of the userspace mailbox drivers, but no errors were seen when adding those changes locally.
Tested on Rb8 and Rb4.

@q-AnupKulkarni
q-AnupKulkarni marked this pull request as ready for review September 30, 2026 05: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.

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

Copy link
Copy Markdown
Author

Local build is successful after taking the latest changes for mailbox umd recipes.

"

# The daemon is installed in this phase but is not automatically started.
# No systemd service is provided by this change. No newline at end of file

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This comments fits better on the commit message and keep the end of line.

qairt-sdk-hexagon-v75 \
qcom-fastcv-binaries-qcs8300-ride-dsp \
qps615-dlkm \
qcom-rtss-can \

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Please split this to a new commit and keep it sorted.

qairt-sdk-hexagon-v73 \
qcom-fastcv-binaries-sa8775p-ride-dsp \
qps615-dlkm \
qcom-rtss-can \

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

same

@lumag

Copy link
Copy Markdown
Contributor

Local build is successful after taking the latest changes for mailbox umd recipes.

THe build should succeed in the CI. Rebase on top of the trunk, if required.

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.

5 participants