Openamp-rp February 2026

openamp-rp@lists.openampproject.org

3 participants
4 discussions

[OpenAMP/openamp-system-reference] 5f1103: examples: legacy_apps: machine: fix Linux CMake bu...

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: 5f1103ee95f9c293a62185b36e0e311b2d4c0933 https://github.com/OpenAMP/openamp-system-reference/commit/5f1103ee95f9c293… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2026-02-17 (Tue, 17 Feb 2026) Changed paths: M examples/legacy_apps/machine/CMakeLists.txt Log Message: ----------- examples: legacy_apps: machine: fix Linux CMake build issue When PROJECT_VENDOR is not set it is treated as an empty string in the path ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_VENDOR}/CMakeLists.txt. Since examples/legacy_apps/machine/CMakeLists.txt exists, the condition evaluates to true even though PROJECT_VENDOR is not defined. Fix this by explicitly testing that PROJECT_VENDOR is defined before checking for the vendor-specific CMakeLists.txt. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Commit: 3eec8f826a2f7fd5b3028bfdbe8253e00ec87f0c https://github.com/OpenAMP/openamp-system-reference/commit/3eec8f826a2f7fd5… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2026-02-17 (Tue, 17 Feb 2026) Changed paths: M examples/legacy_apps/cmake/options.cmake Log Message: ----------- examples: legacy_apps: machine: enable WITH_EXAMPLES by default The purpose of legacy_apps is to provide examples, so it makes sense to have this configuration enabled by default. This also fixes a compatibility issue with legacy scripts used, for instance, in the open-amp CI. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Compare: https://github.com/OpenAMP/openamp-system-reference/compare/4bdabbb5b6aa...… To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

4 days, 11 hours

Re: [OA-syst-ref] RPMsg IOCTL access without root permissions from Linux userspace

by Shah, Tanmay

On 2/6/2026 2:13 PM, Mark Hatle wrote: > > > On 2/6/26 11:43 AM, Shah, Tanmay via Openamp-system-reference wrote: >> Hi all, >> >> I am working on remoteproc auto-boot feature. While working on this, I >> realized it should be possible to achieve RPMsg communication without >> root access given to the user. Existing demos doesn't support it, but I >> want to open discussion on how that can be achieved. >> >> One way discussed was, to use IOCTLS to create RPMSg devices, and I had >> open issue here: >> https://github.com/OpenAMP/openamp-system-reference/issues/50 >> >> I tried to modify echo_test[1] demo and use IOCTLS instead of accessing >> devices from sysfs directly, but that still need root access. >> >> My goal is to design following workflow for the RPMsg communication with >> the remote processor: >> >> 1. Linux device-tree has auto-boot property enabled. >> 2. During boot, driver parses auto-boot related properties, loads fw and >> boots rproc automatically (without user's involvement) >> 3. After boot, rproc firmware does name service announcement of RPMsg >> channels. >> 4. Linux creates RPMsg devices and ept based on above announcement. >> 5. Userspace apps uses RPMsg ioctls to create ept and rpmsg devices. >> 6. Userspace apps uses created devices for RPMsg communication with the >> remote processor. >> >> As per my testing, as of now step-5 and step-6 needs root access. >> Ideally userspace apps should be able to create/read/write/close rpmsg >> devices without root access (for security purposes). >> >> Is there any other way this problem is solved? I appreciate your input. > > This is a 'capabilities' issue. If a user needs to be able to do > something (like run an app that communicates to another app), but it's > too dangerous to give them full system root access, you'd define > appropriate capabilities and then grant the user JUST the capabilities > they need. > > i.e. you should be able to grand the ability to read/write/close to a > user. The create could require something else. So your app startup > becomes: > > User/app gets root (this setuid root on the app) > App runs, which creates the remote connection and makes it available > User/app drops root, and moved to user permissions with an appropriate > capability to use those interfaces in a 'safe' way. > > I explored more about this. I think we can write udev rule which will create devices automatically. Here is the example: https://github.com/andersson/rpmsgexport/blob/master/README I don't have much knowledge on writing udev rules, but I will explore and learn it. > As long as the app startup through dropping the perms is well audited, > it is of minimal security concerns. Then the remaining app activities > are 'safe' in that they are constrained. > > I have no idea offhand what capabilities that IOCTL should use, but > there should be a lot of information about this. This is what I would > exlore. > Sure I will explore more on IOCTL and user capabilities. There should be some way to allow user to operate on particular devices without root privileges. Thank you for all the information. Tanmay > --Mark > > >> Thank You, >> Tanmay >> >> >> References: >> >> [1] >> https://github.com/OpenAMP/openamp-system-reference/blob/main/ >> examples/linux/rpmsg-echo-test/echo_test.c >> >> >

1 week, 4 days

RPMsg IOCTL access without root permissions from Linux userspace

by Shah, Tanmay

Hi all, I am working on remoteproc auto-boot feature. While working on this, I realized it should be possible to achieve RPMsg communication without root access given to the user. Existing demos doesn't support it, but I want to open discussion on how that can be achieved. One way discussed was, to use IOCTLS to create RPMSg devices, and I had open issue here: https://github.com/OpenAMP/openamp-system-reference/issues/50 I tried to modify echo_test[1] demo and use IOCTLS instead of accessing devices from sysfs directly, but that still need root access. My goal is to design following workflow for the RPMsg communication with the remote processor: 1. Linux device-tree has auto-boot property enabled. 2. During boot, driver parses auto-boot related properties, loads fw and boots rproc automatically (without user's involvement) 3. After boot, rproc firmware does name service announcement of RPMsg channels. 4. Linux creates RPMsg devices and ept based on above announcement. 5. Userspace apps uses RPMsg ioctls to create ept and rpmsg devices. 6. Userspace apps uses created devices for RPMsg communication with the remote processor. As per my testing, as of now step-5 and step-6 needs root access. Ideally userspace apps should be able to create/read/write/close rpmsg devices without root access (for security purposes). Is there any other way this problem is solved? I appreciate your input. Thank You, Tanmay References: [1] https://github.com/OpenAMP/openamp-system-reference/blob/main/examples/linu…

2 weeks, 1 day

[OpenAMP/libmetal] 90d19d: libmetal: cmake: support machine less build

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: 90d19dc759c89220e04b987b4e00556506b8ad25 https://github.com/OpenAMP/libmetal/commit/90d19dc759c89220e04b987b4e005565… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2026-02-04 (Wed, 04 Feb 2026) Changed paths: M cmake/options.cmake M lib/system/freertos/CMakeLists.txt M lib/system/generic/CMakeLists.txt M test/system/freertos/CMakeLists.txt M test/system/generic/CMakeLists.txt M test/system/linux/CMakeLists.txt M test/system/zephyr/CMakeLists.txt Log Message: ----------- libmetal: cmake: support machine less build libmetal can be build without any machine support. It is possible that vendors implement machine specific interfaces outside of libmetal and link it with demos during build time. Hence, remove requirement to have MACHINE and PROJECT_MACHINE variables from the build system. If vendor prefer to choose 'template' machine, they can pass such option during cmake configuration. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Commit: 9c593d7a95d9381ee7d0934ae4c3a6f6311fb9be https://github.com/OpenAMP/libmetal/commit/9c593d7a95d9381ee7d0934ae4c3a6f6… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2026-02-04 (Wed, 04 Feb 2026) Changed paths: R lib/system/freertos/xlnx/CMakeLists.txt Log Message: ----------- lib: freertos: remove xlnx vendor directory This directory was removed and re-inroduced by mistake, and should not exists in the libmetal. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Commit: ece95f0e71811c44a4c23d9a1514f338ccf60c75 https://github.com/OpenAMP/libmetal/commit/ece95f0e71811c44a4c23d9a1514f338… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2026-02-04 (Wed, 04 Feb 2026) Changed paths: M lib/system/freertos/sys.h M lib/system/freertos/template/CMakeLists.txt R lib/system/freertos/template/sys.h M lib/system/generic/sys.h M lib/system/generic/template/CMakeLists.txt R lib/system/generic/template/sys.h Log Message: ----------- lib: system: template: remove template/sys.h for generic and freeRTOS Declare sys_irq_enable() and sys_irq_enable() directly in lib/system/@PROJECT_SYSTEM@/sys.h. This allows to declare the machine out of tree of the libmetal but also to support the in-tree template. [minor style fix by tanmay] Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Compare: https://github.com/OpenAMP/libmetal/compare/9196a664c425...ece95f0e7181 To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

2 weeks, 3 days

2026

2025

2024

2023

2022

2021

2020

2019

Openamp-rp February 2026