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
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
>>
>>
>
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…
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