OpenAMP System Reference Meeting Notes 2026 - OpenAMP/openamp-system-reference GitHub Wiki

Table of Contents

2026-03-25

Attended

  • Tanmay, Ed, Arnaud, Tomas, Dan, Bill, Nathalie, Beleswar

Agenda

  • Tomas: greater uptake of System Devicetree via openamp-system-reference
  • April Feature Freeze
  • Zephyr topics
  • OpenAMP docs improvement project topics
  • 2026 task tracker / individual updates
  • EU CRA.
  • Wishing Tomas a happy retirement

Decisions/conclusions

  • Open to exploring how to use System DT for ST, VxWorks, Zephyr
  • AMD welcomes feedback about System DT from other vendors as they try to use it
  • Zephyr rpmsg multiservice demo is broken for ZynqMP platform & might still be in next OpenAMP release
  • Let's push EU CRA topic out to when Stefano can join, since he has experience from Xen. May 2025 Embedded Recipes talk by Greg KH was very relevant and https://www.bestpractices.dev/en badging checklists can help us assess how secure OpenAMP is

Action items

  • Stefano to ensure ZynqMP gets addressed eventually for SystemDT flow
  • Bill take a look at https://github.com/OpenAMP/openamp-system-reference/pull/101
  • Tanmay: Will adapt makefile to be able to specify udev install folder
  • Arnaud to update Zephyr for next OpenAMP release & notify system reference group to review the PRs
  • Bill to invite Daniel from NXP to OpenAMP Discord to see if he can help with testing on NXP for release
  • Nathalie to send meeting series for Daylight Savings

Notes

  • Tomas: greater uptake of System Devicetree via openamp-system-reference
    • System DT as one true source for configuration across multiple domains
    • AMD has fully integrated System DT into Yocto for next release
    • Very helpful for OpenAMP when you have things shared & can set up in 1 place and then it just flows through Yocto (or other infrastructure), so that each OS/system gets the info it needs
    • Not sure how accessible this could be for other systems, but think System Reference group could be a great way for getting this demonstrated in other architectures + give feedback about System DT to AMD
    • AMD OpenAMP team is now reporting into Stefano, who also owns virtualization
  • Arnaud: AMD can generate DT for Zephyr w/ OpenAMP multi-services project + Linux part?
    • Tomas: Yes, in our upcoming release, building Zephyr within Yocto rather than West + generating #defines for baremetal
    • Tanmay: For the platforms newer than ZynqMP
    • Tomas: Need to remind Stefano to ensure ZynqMP gets addressed eventually for SystemDT flow
  • Arnaud: Do we have example from AMD? Could we use AI to adapt to other platforms by inputting vendor DT and see if could get out a system DT and infer the Lopper stuff ?
  • Tanmay: Had not introduced System DT example into System Reference until now because didn't have public database of System DT for different boards until now, and spec was still being worked out for different OS & targets. So, now that this is public, will write up steps for using this whole flow for Baremetal & FreeRTOS to start. Later hopefully for Zephyr & ZynqMP. When the SystemDTs not public, would've had to use Xilinx-specific tools to generate.
    • Arnaud: Baremetal & FreeRTOS will be more tricky b/c more vendor-specific, but Zephyr has more common
    • Tomas: VxWorks can use DT (looks a little different), but could be interest to see if could get a VxWorks DT out of this b/c have lots of customers who use VxWorks. Would be great to see this become a standard
    • Dan: Think we're aligned. Been trying to find the right demo platform.
    • Tomas:
      • Stefano looking at how you define what's available for Xen / hypervisor
      • Starting to look at how to use Lopper to do this
      • Want this to be accessible & make other vendors successful to adopt System DT so it can become a true industry standard
      • Feedback from other vendors would be great to make sure nothing is missing
    • Arnaud:
      • ST has a tool similar to Lopper for generating the DT for MCU and MPU SoC
    • Tomas:
      • Think it's important for the DT & System DT to be standard & OK to have different tools (analogy C language & different compilers)
      • Think Bruce would love to have other companies participate in Lopper to make it more usable for other devices
      • For our customers, one of the hardest things is getting the configuration right, so having 1 true source will significantly simplify how you use
  • Nathalie: Next steps for SystemDT?
    • Tanmay + Ben will be working on it for System Reference
    • We can invite Bruce to the meeting if others want to get help with Lopper
  • April release feature freeze
    • Tanmay: Could Bill take a look at https://github.com/OpenAMP/openamp-system-reference/pull/101
      • Apps should be able to use without root privileges
      • Yocto can take care of where to install the scripts & udev rules. This is just an example
      • Arnaud: Perhaps could have a make install that would install the binaries & udev?
      • Tanmay: Will adapt makefile to be able to specify udev install folder
      • License: Use the SPDX identifier instead of copy/pasting the license text
      • Not sure if will make it into April release, but will try (system reference has a bit longer than libmetal & open-amp) - system ref targets ~May
  • Bill: What is plan for Zephyr update for release?
    • Arnaud made the update last release b/c had to do it for non-regression tests. Can do Zephyr update for upcoming release. But am maintainer of openamp libmetal module, so will need help from reviewers.
    • Bill: Would be good to have cross-testing on NXP. Should reach out to Daniel.
    • Arnaud will post to Discord when ready for review
    • Bill to invite Daniel to OpenAMP discord
  • Tanmay: Latest Zephyr: rpmsg multiservice demo is broken for ZynqMP platform since 4.2
    • Internal Zephyr team working on Cortex-R trying to add various drivers
    • Think it will be broken for next OpenAMP release
    • Build should work, but execution not working
    • Arnaud: Haven't tried on ST for a while, so don't know if working for ST
  • Let's push EU CRA topic out to when Stefano can join, since he has experience from Xen
    • Arnaud:
      • Greg KH recording was very interesting -> May have to manage Open Source Steward role
      • His presentation also mentions https://www.bestpractices.dev/en OpenSSF badging, which can be a good entry point, but takes work to make things better. Would be good to evaluate before exposing the score to everyone, so we can gauge scope
  • Wishing Tomas a happy retirement
    • Thanks for championing the reboot as a Linaro Community Project in 2019
    • Tomas trying to set up OpenAMP to be more successful after his retirement b/c this area is super important but its value is underestimated by many

2026-03-11

Attended

  • Ben, Tanmay, Mark, Arnaud, Beleswar, Bill, Devarsh (TI)

Agenda

Decisions/conclusions

  • udev rules sufficient for this scenario, don't need capabilities
  • RPMsg OK for abstracting registers, but use virtio-msg for pixel data

Action items

  • Tanmay to explore udev rules and group permissions further and email updates to list.
    • Prepopulate udev rules to automate device creation and permission settings.
    • Create a dedicated RPMsg group during package installation, with permissions ready for admin or distro to add users.
  • Beleswar and Devarsh
    • Adopt Virtio Message: For tasks involving data buffers and media/GPU interactions, prioritize Virtio Message.
    • RPMsg for Specific Use Cases: Utilize RPMsg for low-footprint IPC and register interface abstraction.
    • Collaborate on Standardization: TI to consider proposing extensions for standardized bus messages to address lifecycle event communication.
    • Explore Dynamic Discovery: Investigate Rob Herring's dynamic device tree approach for future device discovery enhancements.

Notes

  • RPMsg IOCTL access without root permissions from Linux userspace
    • Tanmay's goal: Enable RPMsg communication without requiring root access for users, focusing on automating device permission changes and improving security. Bad that root was used to run all the apps before. All users being able to run apps is bad behavior too. Let's demonstrate the good behavior where only users belonging to a certain group can.
    • udev Rules:
      • Bill suggested using udev rules to automate device permission changes, eliminating the need for scripts.
      • Tanmay reached a solution where udev rules would execute scripts to change device permissions.
      • Bill emphasized that changing device permissions is a standard udev operation and recommended creating a user group for RPMsg access.
    • Group Permissions:
      • Arnaud and Bill discussed managing access via user groups, similar to ST's approach. ST has example in public code in Yocto layers.
      • Bill and Mark agreed that groups are suitable for this.
      • Capabilities might be necessary for more complex scenarios (e.g. containers) but would be overkill for this situation.
    • Attach-Detach Flow:
      • Tanmay expressed the need to avoid sudo access for attach-detach operations.
      • Bill suggested kernel enforcement to prevent even root from stopping the remote processor.
    • Symlinks and Topology Information:
      • Tanmay proposed using symlinks in udev rules to map RPMsg channels to devices, allowing apps to identify which symlink to open.
        • Symlink to RPMsg char device in udev rule w/ RPMsg channel name & endpoints -> app would know which symlink to open & could achieve RPMsg comm
      • Bill supported this idea, noting it as a common udev operation.
  • Standardization:
    • Tanmay to think through the approach and post updates to the discussion list.
    • In future, consider standardizing the approach across vendors, potentially integrating into meta-openamp.
  • Beleswar's questions:
    • We are having a few media use cases in TI where:
      • A. The MCU core owns the entire display controller, and Linux provides the data for the video pipelines to MCU.
      • B. The MCU core owns some of the video pipelines, and Linux owns the rest. In this case, MCU core has to announce which pipelines it controls, so Linux can assert the ownership of the rest dynamically.
    • Our initial thought was to introduce rpmsg-kms, but I am comparing it with virtio-msg here. I am wondering if virtio-msg can solve the following problems:
  1. How do we handle communication of lifecycle events (suspend/resume/shutdown) across the processors? What if the MCU shuts down, how to we tear the virtio device in Linux?
  2. What would be the way to discover devices dynamically in virtio-msg? In ST's demo for virtio-msg-i2c, the devices & bus were enlisted in the device tree, but we want to make the same Linux work with multiple firmwares which can handle variable display pipelines and/or assert ownership of the controller as well?
  3. How do we handle the SoCs in which we have a single MCU which is doing other things also. Does it make sense for the firmware to implement a rpmsg implementation for IPC, and a separate virtio-msg implementation for device sharing where it could be done by just one?
  4. Lastly, will OpenAMP have a virtio-msg implementation for firmware as well? (I see Arnaud's response going in this direction)
  • Discussion on Beleswar's questions:
    • Virtio Message vs. RPMsg:
      • Preference for Virtio Message: Bill Mills emphasized the preference for using Virtio Message over RPMsg for media and GPU-related tasks to avoid reinventing the wheel.
      • Lifecycle Events: Discussion on handling lifecycle events like suspend, resume, and shutdown. Virtio Message supports ungraceful hot plug and unplug, but graceful shutdown is not yet scoped out.
      • Device Communication: Beleswar Padhi raised concerns about communicating device shutdowns from MCU to Linux. Bill Mills mentioned provisions exist but examples are not worked out.
    • Use Case A and B:
      • Use Case A: Generic and vendor-independent, suitable for Virtio Message.
      • Use Case B: Specific to TI's display controller, involves static partitioning and device management. Bill Mills suggested using RPMsg for abstracting register interfaces but not for media or GPU data transfer.
    • Dynamic Device Discovery:
      • Device Tree Utilization: Bill Mills discussed using Device Tree for discovering buses and devices, with potential for dynamic discovery in future implementations.
      • Resource tables were mentioned as a possible method for discovering buses, although examples are not yet available.
      • Rob Herring's Dynamic Device Tree: Mentioned as an experimental solution for dynamic device discovery.
      • Rob's presentation from Linux Plumbers 2023
    • Next Steps:
      • Adopt Virtio Message: For tasks involving data buffers and media/GPU interactions, prioritize Virtio Message.
      • RPMsg for Specific Use Cases: Utilize RPMsg for low-footprint IPC and register interface abstraction.
      • Collaborate on Standardization: TI to consider proposing extensions for standardized bus messages to address lifecycle event communication.
      • Explore Dynamic Discovery: Investigate Rob Herring's dynamic device tree approach for future device discovery enhancements.

2026-02-25

Attended

  • Ed, Arnaud, Bill, Dan, Nathalie

Agenda

  • Recent PRs
  • 2026 task tracker / individual updates

Decisions/conclusions

  • OpenAMP has been pretty quiet for PR traffic recently. Let's decide Monday before next call if we should cancel that instance if there's not much activity.

Notes

  • Recent PRs
  • 2026 task tracker / individual updates
    • If anyone is going to Embedded World, the WindRiver booth will have a robot giving away chocolates :)
  • If not much activity next week, we might be able to skip next call. Let's decide on the Monday before next call.

2026-02-11

Attended

  • Arnaud, Ed, Tanmay, Nathalie, Ben

Agenda

  • RPMsg IOCTL access without root permissions from Linux userspace - Openamp-system-reference - lists…
  • Recent PRs
  • OpenAMP docs improvement project topics
  • 2026 task tracker / individual updates

Decisions/conclusions

  • Continue RPMsg IOCTL access discussion with more folks
  • Let's use shell block in documentation for other OpenAMP repos to make reproducing easier for reader

Action items

  • Tanmay to look into the Linux kernel patch for -1 -> Linux allocate next endpoint & see if makes sense to try to upstream it
  • Nathalie: Put RPMsg IOCTL access topic on agenda for next meeting, since we have folks OOO, unless resolved on mailing list
  • Tanmay to ping Arnaud when ready for him to review system reference PR94
  • Arnaud can create ticket for Sipke to work on making shell block change in other OpenAMP repos
  • Ed & Tanmay to review the outstanding docs PRs

Notes

  • Tanmay: RPMsg IOCTL access without root permissions from Linux userspace - Openamp-system-reference - lists
    • Is there way for RPMsg apps in user mode. Today, using sysfs -> needs root privileges, which is not secure
    • Should we have rules for how RPMsg apps should access RPMsg devices?
    • Arnaud: ST solved by adding subgroup w/ privilege associated w/ the group. Agree, should document rules somewhere
    • Tanmay: Still requires a user intervention. Maybe could automate w/ udev & just pass in device node. Working on a script & need to test it. Can create udev rule for channel, which will use RPMsg utilities to create RPMsg devices & use device in user mode w/o root privileges. Each vendor may want to do differently, but should document set of rules for secure way.
    • Arnaud: Will also be true for /dev/rpmsg* devices
    • Tanmay: IOCTL doesn't give us file descriptor today, but don’t know which device was actually created. Saw patch to Linux kernel that might be relevant to us - if we could execute IOCTL, could solve problem. Then user doesn't have to worry about which device was created. W/ many devices, hard to know which to use to talk to a particular endpoint. Tanmay using static endpoint w/ fixed address. Use name, start & end to find device.
    • Arnaud: Should associate name to your endpoint device address when you create it
    • Tanmay: Not allocating next endpoint, getting -1
    • Arnaud: Believe -1 should trigger name service announcement to remote device or else a bug… don't recall details
    • Tanmay: Shouldn't Linux kernel allocate next endpoint?
    • Arnaud: Limitation in Linux today - remote device should respond w/ address. Patch not yet upstreamed.
    • Tanmay to look into the Linux kernel patch for -1 -> Linux allocate next endpoint & see if makes sense to try to upstream it
    • Nathalie: Put this on agenda for next meeting, since we have folks OOO, unless resolved on mailing list
  • Recent PRs
  • Any Zephyr topics? No
  • OpenAMP docs improvement project topics?
    • Contractor renewal nearly complete
  • 2026 task tracker / individual updates
    • Tanmay: Also worked on libmetal refactor & the PRs are merged

2026-01-28

Attended

  • Bill, Arnaud, Nathalie

Agenda

  • Recent PRs
  • Libmetal release 2025.10.1
  • OpenAMP docs improvement: contractor renewal is stuck in Linaro accounting. Bill M & Bill F are following up.

Decisions/conclusions

  • Agreed w/ Arnaud's plan to only tag libmetal with 2025.10.1 and don't need to tag the other repos

Action items

  • Arnaud will check openamp-system-reference PR83 to see if OK to proceed with Ed's earlier approval or if want Ed to review the changes that came in after

Notes

2026-01-14

Attended

  • Arnaud, Ed, Andrew, Ben, Nathalie, Bill, Dan

Agenda

  • Recent PRs
  • Any Zephyr topics? None.
  • OpenAMP docs improvement project topics
  • 2026 task tracker / individual updates

Action items

  • [DONE] Nathalie to give Sipke heads up about entity change
  • Nathalie to dig up the old budget tally & send to Bill F
  • Dan will rephrase some of the tasks to reflect 2026 plan

Notes

  • Recent PRs
    • https://github.com/OpenAMP/openamp-system-reference/pulls
      • https://github.com/OpenAMP/openamp-system-reference/pull/83
        • Has 2 approvals & can be merged
      • https://github.com/OpenAMP/openamp-system-reference/pull/92
        • Needs reviewers
      • https://github.com/OpenAMP/openamp-system-reference/pull/93
        • Needs reviewers
    • https://github.com/OpenAMP/openamp-demo/pulls
      • No open PRs
    • https://github.com/OpenAMP/openamp-docs/pulls
      • https://github.com/OpenAMP/openamp-docs/pull/79
        • Sipke to address small change requested by Ed & then need 1 more approver
        • Andrew will add his approval to the PR
      • https://github.com/OpenAMP/openamp-docs/pull/80
        • Arnaud approved
        • Needs at least 1 more review
        • Apply same to other OpenAMP repos?
      • https://github.com/OpenAMP/openamp-docs/pull/81
        • Arnaud approved
        • Needs at least 1 more review
    • https://github.com/OpenAMP/open-amp/pulls
      • https://github.com/OpenAMP/open-amp/pull/675
        • Arnaud submitted for CI improvement
        • Needs reviewer
    • https://github.com/OpenAMP/libmetal/pulls
      • https://github.com/OpenAMP/libmetal/pull/350
        • Branch conflicts need to be resolved
      • https://github.com/OpenAMP/libmetal/pull/354
        • This is the 2025.10 version of PR350
        • Arnaud will perform non regression tests before merging and add the v2025.10.1 tag
        • Target: beginning of next week
      • https://github.com/OpenAMP/libmetal/pull/355
        • Needs reviewer
  • OpenAMP docs improvement project topics?
    • Nathalie to give Sipke heads up about entity change
    • Nathalie to dig up the old budget tally & send to Bill F
  • 2026 task tracker / individual updates
    • Review 2025 Won’t Do & Deferred items to see if we should delete them
    • Dan's Won't Do items don't make sense any more w/ virtio-msg
    • Dan will rephrase some of the tasks to reflect 2026 plan
Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️