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

Table of Contents

2026-06-03

Attended

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

Agenda

  • CMake Build System Structure and Platform-Specific Files
  • Meta-openamp PR
  • What is OpenAMP’s policy for AI generated code?

Decisions/conclusions

  • First step would be to remove vendor-specific cmake files from libmetal/openamp & move to system reference. Then we can think about second step of making a generic example to build the libraries for CI test & maybe third step could be how to execute on-target.

Action items

  • Tanmay: Begin migration of AMD-specific CMake platform files from Libmetal to the OpenAMP System Reference.
  • Arnaud, Andrew, Beleswar: contribute ST & TI platform files (respectively) to system reference.
  • Bill, Mark: Review https://github.com/OpenAMP/meta-openamp/pull/52
  • All: Review Bill's upcoming PRs for compatibility with latest LTS and 2026.04 recipes
  • Tanmay, Nathalie: Continue discussion and policy development for AI-generated code on the OpenAMP TSC list
  • All: Review and provide feedback on porting guide documentation.

Notes

  • CMake Build System Structure and Platform-Specific Files
    • Current Situation:
      • Demos have been moved out of library repositories.
      • There is a need to clarify how to handle CMake build system files, especially platform-specific configurations.
      • Discussion on whether to remove CMake folders from library repositories and centralize them elsewhere.
    • Key Questions Raised:
      • Should CMake build system files be referenced from the system or kept within each library?
      • How to issue native CMake commands to build libraries and demos efficiently?
      • Should platform-specific CMake option files be migrated to a central system reference repository?
    • Consensus and Recommendations - Templates and Reusability:
      • Generic Examples:
        • Generic CMake platform files (e.g., for Linux user space, generic GCC cross-compilation) should remain in the library repositories.
        • These serve as templates and CI (Continuous Integration) test targets.
      • Platform/Vendor-Specific Files:
        • Platform-specific files (e.g., for Microblaze, ZynqMP, STM32) should be moved to the OpenAMP System Reference repository.
        • This approach avoids cluttering the library with numerous vendor-specific files and provides a clear structure for users.
        • Each vendor can contribute their own CMake files to the system reference.
      • Build System Integration:
        • The build system should be able to search both the system reference and the library for configuration files, using the system reference first, then falling back to the library.
        • This structure supports both upstream (open-source) and downstream (vendor-customized) builds.
      • First step would be to remove vendor-specific cmake files from libmetal/openamp & move to system reference. Then we can think about second step of making a generic example to build the libraries for CI test & maybe third step could be how to execute on-target.
  • Handling of Build System Dependencies and Yocto Integration
    • https://github.com/OpenAMP/meta-openamp/pull/52
      • Ben pushed some internal commits so we can get parity. Believe Xilinx uses scarthgap Yocto branch
      • Bill: PR is probably OK. We have more work to do
        • Another LTS has published since.
        • We should also be testing with OpenAMP 2026.04 (if using 2025.04 then your config needs to pin that)
      • Ben: Internal nightly builds are not pulling from upstream meta-openamp, but we'd like to & this PR is delta for our latest setup. We have some bbappend and some other layers and dynamic layer pickup to provide preferred version.
      • Ben: In a few months, will send a PR to strip out the system DT workflow vendor-specific stuff in meta-openamp, which will clean up the vendor stuff for AMD Xilinx. This is the first step for that.
      • Bill: Will review meta-openamp PR52. Will submit some PRs for compatibility with latest LTS and 2026.04 recipes & will need reviews from system reference participants
    • Dependency Management:
      • Concerns about dependency loops when using OpenAMP System Reference as a central repository for build files.
      • Solution: Use multiple checkouts or submodules in build recipes (e.g., Yocto), allowing libraries and demos to reference the necessary files without circular dependencies.
    • Yocto/Meta OpenAMP:
      • Discussion on updating and maintaining Yocto recipes for OpenAMP and related libraries.
      • Ensuring that internal builds track upstream changes and remain compatible with the latest LTS (Long-Term Support) releases.
      • Plans to clean up vendor-specific content in Meta OpenAMP, especially for Xilinx/AMD, to streamline maintenance.
  • Policy and Concerns Regarding AI-Generated Code
    • Issue Raised:
      • Should AI-generated code be accepted in OpenAMP and related projects?
      • Legal concerns about the provenance of AI-generated code and compatibility with open-source licenses.
    • Current Practices and Suggestions:
      • Some projects (e.g., Zephyr, Linux) require contributors to declare if code was AI-assisted and specify the model/version used.
      • The DCO (Developer Certificate of Origin) must be signed by a human, even if AI was used.
      • Policy suggestion: The contributor submitting the pull request is responsible for the code, regardless of AI assistance.
      • Recommendation to discuss and formalize this policy at the TSC (Technical Steering Committee) level, leveraging practices from other open-source projects.
  • Documentation and Porting Guides
    • Ongoing Work:
      • Efforts to improve and review porting guides and documentation for OpenAMP.
      • Request for community review and feedback on new documentation pull requests.
      • Aim to clarify and streamline the process for porting OpenAMP to new platforms.

2026-05-20

Attended

  • Ed, Nathalie, Ben, Arnaud, Tanmay, Bill

Agenda

  • 2026.04 release topics
  • Libmetal PR365
  • OpenAMP GitHub organization
  • Zephyr
  • Topics for next meeting

Decisions/conclusions

  • Arnaud will wait until end of week to tag system reference & openamp-docs for 2026.04 release
  • OK to do the release with or without https://github.com/OpenAMP/openamp-docs/pull/89 (let's see if Sipke weighs in on the PR)
  • Using GitHub release milestones is helpful to prioritize reviewer bandwidth

Action items

  • System reference PRs: Ed will look at 107 & 98 this afternoon. Arnaud will review 98
  • Ben: Investigate feasibility of using symlinks for device lookup and document findings
  • Ben: Update the pull request with thoughts on incorporating the “UIO” bus type and fallback mechanism. Notify stakeholders (e.g., Tanmay, Bill, Arnaud) via Discord when ready
  • AMD: Consider potential reintroduction of VFIO support in libmetal
  • Arnaud: will clean up by closing out old release milestones
  • Folks who don't have a profile photo should upload some image to replace the default Github pixelated icon
  • All: Review v0.2 draft of OpenAMP security policy
  • Nathalie: Put on agenda for next call
    • Cmake build system in openamp & Libmetal library. How can we get rid of it since demos no longer in those libraries. Can we use cmake from system reference instead.
    • (smaller audience) Updating OpenAMP contributor & external collaborator lists
    • v0.2 draft of OpenAMP security policy

Notes

  • OpenAMP docs
    • Once Bill gets go-ahead, the project needs to be updated
    • Bill tested over the weekend
    • Ubuntu & Python update doesn’t seem to conflict w/ Sipke's changes
    • 22.04 will go out of maintenance next year, so jump to 26.04
    • Arnaud: Impact on open-amp & libmetal?
    • Bill: When release the documents, will build from the tags, which won't have this or the deletions -> should be OK. OK to make this part of the 2026.04 release & can remove the unnecessary files in system reference & libmetal for next release, should not cause problems. Will give 1 day to see if Sipke
    • Arnaud will wait until end of week to tag system reference & openamp-docs for 2026.04 release
    • PRs for maintenance branches of libraries are not yet handled correctly, the main procedure should work
    • OK to do the release with or without https://github.com/OpenAMP/openamp-docs/pull/89
  • System reference release
    • Tanmay would like to wait to tag until end of week b/c have some PRs would like to put in (107 and 98)
      • Ed will look at 107 & 98 this afternoon. Arnaud will review 98
      • 98 fixes some compiler warnings. Tanmay addressed the requested changes.
      • Arnaud tagged both for the release
  • Libmetal PR365
    • Key points:
      • Current workflow issues:
        • Libmetal currently uses platform devices, which are not scalable and lack control over naming
        • UIO devices (created by Linux) provide a more standard, platform-agnostic approach
        • Existing workflow traverses platform devices and binds to UIO, which is fragile and assumes UIO is enabled
      • Proposed improvements:
        • Transition to using UIO device names defined via Linux device tree (DT) properties for improved scalability and consistency
        • Introduce a “UIO” bus type in libmetal to distinguish device types by bus name (e.g., UIO, VFIO, platform)
        • Maintain backward compatibility by keeping the platform device workflow as a fallback
      • Symlink exploration:
        • Symlinks may help map UIO devices to user-friendly names, but require further investigation
        • Could reduce complexity in libmetal, though some library changes may still be needed
      • Future considerations:
        • VFIO (previously removed from libmetal) may be more relevant for PCIe device support
        • Kernel maintainers prefer VFIO over UIO due to extensibility and security considerations
    • Key takeaways:
      • Using UIO device names via DT properties simplifies device management and aligns with Linux standards
      • Introducing a “UIO” bus type enables extensibility, including potential future VFIO support
      • Backward compatibility with platform devices is important to avoid disrupting existing workflows
    • Action items:
      • Investigate feasibility of using symlinks for device lookup and document findings
      • Update the pull request to incorporate the “UIO” bus type and fallback mechanism
      • Notify stakeholders (e.g., Tanmay, Bill, Arnaud) via Discord to review the updated pull request
      • Explore potential reintroduction of VFIO support in libmetal
  • Any other release topics?
    • Using GitHub release milestones is helpful to prioritize reviewer bandwidth
    • Arnaud will clean up by closing out old release milestones
  • GitHub project maintenance:
    • Will remove Tammy from contributor list since Siemens has changed focus & her role changed.
    • Will see if can add Sipke as external collaborator.
    • Can review at end of next call w/ smaller audience
  • Zephyr
    • Arnaud got help w/ review of his PR via Discord ping. Maintainer approved PR & Iulia merged it. Release is merged in Zephyr.
  • Next meeting:
    • Cmake build system in openamp & Libmetal library. How can we get rid of it since demos no longer in those libraries. Can we use cmake from system reference instead.
    • Nathalie put OpenAMP contributor bandwidth constraints into LLM for guidance + combined some content from v0.1 draft to come up with v0.2 draft of security policy

2026-05-06

Attended

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

Agenda

  • Open PRs
  • Proposal for draft security policy

Decisions/conclusions

  • System-reference PR 101 will not be in v2026.04 release
  • System-reference PR 102 Should not add script if allowing use of UIO devices directly could happen through libmetal
  • Open-amp PR 681 has agreement that should have this move to libmetal, which will provide stub if HW has no cache
  • OpenAMP isn't currently resourced to be a Steward, but should publish a security policy that sets expectations. Given how OpenAMP is consumed, secrecy & embargo period aren't necessary.

Action items

  • Tanmay to update release notes regarding Zephyr demos on ZynqMP which may face issues due to code not yet upstream
  • All: look for examples of other projects using GitHub "Security and quality" tab so we can understand how others are using it (https://github.com/OpenAMP/open-amp/security)
  • Nathalie to draft a revision of security policy proposal based on our discussion & post it to a new tab in Arnaud's google doc
  • Arnaud to grant Nathalie editor access to security policy draft google doc

Notes

  • Arnaud has to test some of Andrew's patches before merging
  • System Ref 94
    • Ben & Tanmay working on it
  • Zephyr demos on ZynqMP may face some issues
    • Lot of stuff needs to get upstreamed still -> no urgency to merge
    • Can Tanmay use OpenAMP staging branch? It hasn't been updated in a long time. Will just update release notes.
  • System reference 104 & 105 are urgent for reviews
    • Readthedocs build failed on apt-get update - Arnaud will try to restart it through a force update
  • System reference 101 in draft
    • Arnaud will remove from v2026.04 release
  • 102
    • Ben has made the fixes in a local but wanted OK from Arnaud to remove the config from the Linux side
    • Ben will add to the PR & Arnaud can take a look
    • OpenAMP & System DT based on Lopper flow. Linux side is different -> can query DT & use it to configure your app. Would have a script that parses DT & uses that to generate a config, which simplifies Linux side app.
      • Ben will add a commit to the PR
      • Tanmay: Could allow use of UIO devices directly?
      • Ben: That's a 1st update for libmetal library
      • Tanmay: Better to not add the script if it will go away
  • Open-amp PR 681
    • Andrew: Has build time flag that ifdef's out all the cache maintenance operations. Even if on coherent platform - lower level will NOP it out.
      • Think metal cache should have ifdefs & let libmetal decide -> move device specifics to libmetal
    • Tanmay: cache is optional HW & is the only one that is left out via compile time option -> enforces API on every developer or user who doesn't have cache HW. UART is different than caceh maintenance. Libmetal lets youconfigure in app where the log will be diverted, so should still provide cache option. OK to stub out & keep cache option. If we remove the cache config from open-amp
    • Andrew: Cache operations are part of the API & if you don't have them, you stub them out & then compiler just removes them.
    • Bill: When we compile open-amp library, are we including a libmetal header that is platform specific anyway? IF so, then, there is not runtime penalty to stub out.
    • Arnaud: We have cache macros & dep on cmake config then may be empty or call libmetal cache API. So you decide for open-amp library if you want to use cache or not.
      • Think Andrew's point is valid, it's HW configuration, so should be managed in libmetal b/c is HW adaptation layer. Code removed by compiler if not at libmetal
    • Bill: Buy Andrew's argument, but not understanding why cmake becomes more complex w/ the patch?
    • Andrew: Ignore the patch - had some mind changing & now we debate if should remove them all.
    • Arnaud: Enable/disable cache in open-amp or move to libmetal?
    • Andrew: It's already in libmetal & if HW doesn't have it the stubs are already empty
    • Tanmay: We tried to introduce mailbox for similar reason in libmetal but it was rejected b/c probably belongs to the platform driver. So why can't we move cache ops to platform driver?
    • Arnaud: You need cache coherence in middle of virtio management, so need some open-amp code. Can't fully delegate to platform, need an API.
    • Tanmay: Only needs this if cache HW is there
    • Bill: You need to mark the place in the code where the cache operation should be. If you don't have a cache, that becomes nothing at compile time.
    • Arnaud: Today, we have macro. Could make it call libmetal API
    • Tanmay: If platform doesn't have cache, why do they need to provide stubs & current option doesn't work?
    • Bill: It's simpler if you define an API that does nothing on platforms that don't need it. It's a platform concern, so should be defined by libmetal.
    • Arnaud: Same functionality in fact. But downside is that some impact in Zephyr build chain.
    • Andrew: We'd have to go through deprecation process
    • Arnaud: Today works in open-amp but would be cleaner to have it in libmetal
    • Bill: All these PRs are 2026.10?
      • Arnaud: Yes. Will be in 2027.04 Zephyr release & may impact NuttX too
    • Arnaud: Include done by open-amp in cache.h
      • Tanmay: OK, then agree. Libmetal is by default providing the stub. But still have to configure libmetal w/ dcache option. We are not completely removing the option & just moving it. Wanted to give developers choice to turn on/off cache & by default provide stub
  • Open-amp PR682 seems to be stuck
    • Arnaud has to test it
  • EU CRA
    • Is it a reasonable assumption that OpenAMP be steward?
      • Bill: Project is too small to take on Legal risk. We should tell ppl that we have a process to address issues best-effort, otherwise the member fees have to go up. OpenAMP TSC should com eup with stance on it.
    • Arnaud: Is it possible for project to not be steward?
      • Bill: Think possible
    • Tanmay: Does safety certified = security supported?
      • Bill & Ed: No
    • Secrecy
      • Nathalie: Bill had proposed during Board meeting that security issues filed in GitHub as issues. In the doc, posted a comment w/ link to another project that does that (i.e. not secret reporting)
      • Ed: Long timelines for consumption, so no embargo period would make sense
      • Arnaud: Likely consumer of OpenAMP would fix directly in their product & then might submit vulnerability report to OpenAMP
    • GitHub has a way to publish security advisories -> need to look into that more
    • Nathalie to draft a revision of security policy proposal based on our discussion & post it to a new tab in Arnaud's google doc
    • Arnaud to grant Nathalie editor access to security policy draft google doc

2026-04-15

Attended

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

Agenda

  • PRs
  • OpenAMP April feature freeze & release

Decisions/conclusions

  • System Reference PR 101: Make the /dev names for the links more usable with prefix instead of having 2 symlinks. Tanmay to start with this & later can pursue creating links w/ the remote proc name
  • Udev rules are so you can provide defaults & end user can provide higher priority rule file that overrides the defaults
  • OpenAMP issue 679: Let's see what Sunil comes back with
  • OpenAMP granular cache management flags had been removed to simplify the code since we thought no one was using it. TI had missed raising AM62 use case (big Arm + MCU).
  • Let's default to Zephyr 4.4 in OpenAMP 2026 April release unless we hit issues in testing

Action items

Notes

  • https://github.com/OpenAMP/openamp-system-reference/pull/102
    • Ben has to do a little more development before rebase
  • https://github.com/OpenAMP/openamp-system-reference/pull/101
    • Tanmay has converted to draft for now
    • Think still need 2 symlinks b/c need to map device name w/ channel symlink
    • If used readlink, would have to go through all files in /dev to find which device the symlink is mapped to, unless there is a way to know the reverse direction
    • Arnaud: Not aware of way to do in opposite dir. Think have to parse to find link.
    • Bill: Was it in the first symlink?
    • Tanmay: In 1st but app is only supposed to use 2nd symlink, which only has channel name & not device name. When want to unlink, need to know which to unlink when device gets destroyed. Would otherwise have to search
    • Bill: Doing readlink of rpmsg.* should not be too bad. It should either start with rpmsg prefix or be in an rpmsg directory e.g. can't start it with /dev/tty or hd0
    • Arnaud: When you have a device removed, you can go through all the dev link & check if they are dead links & remove.
    • Bill: Think should only remove the ones that you created, not the ones that user created - may want to show as bad symlink until it comes back up again.
    • Bill: If it was rpmsg0 that is being removed, you remove all the ones pointing to rpmsg0
    • Tanmay: Becomes a standard?
    • Bill: De facto, good to have a good example & rules may get tweaked over time
    • Make the /dev names for the links more usable with prefix instead of having 2 symlinks
    • Arnaud: No generic way to do this
      • Tanmay: Agree
    • Bill: Udev rules are so you can provide defaults & end user can provide higher priority rule file that overrides the defaults
    • Tanmay: Thought about having duplicate RPMsg link name w/ incremental number if link already available & let upper level protocol decide if link is correct for them or not. Apps can iterate over the links & decide if it is correct endpoint for them. Don't care which core created the channel name.
    • Bill: Having a number if it's not unique is fine, wouldn't be giving unprivileged user enough info to differentiate which one they want b/c need more info from sysfs which you don't have access to.
    • Tanmay to start with this & later can pursue creating links w/ the remote proc name
  • https://github.com/OpenAMP/openamp-system-reference/pull/100
    • Think hit another bug in Linux
    • Trying to do with remote is when see vdev status 0 from remote, we stop polling & recreate all the RPMsg channels
    • Use case: Repeat attach, detach. Attach to remote processor & supposed to work.
    • Linux supposed to set something in resource table & poll on vdev status until remote sets status to 0
    • Tanmay: Do we need to maintain backward compatibility with current behavior of Linux?
      • Arnaud: It's a bug if Linux doesn't respect virtio spec, so don't need to maintain compatibility with bug
    • Arnaud: When you attach linux, you make a copy of the resource table, you start virtio & RPMsg, then after you detach, Linux will overwrite the resource table with the copy & contains status with 0 automatically. Virtio spec says driver should inform through the transport layer the device it wants to reset (detach mechanism) then device/coprocessor should put status to 0 and then ACK the detach. Then Linux should cross check the status is 0 and overwrite resource table w/ copy
    • Bill: So upstream has no functional way to detach & reattach so nothing to preserve?
    • Arnaud: Linux is violating virtio spec b/c should not set status to 0
    • Tanmay: How are other vendors doing attach-detach-reattach? May break existing firmware?
      • If new mechanism available, follow new mechanism
      • If not available, then do what used to do (breaking the spec)
    • Arnaud: OpenAMP should not support the legacy behavior (bug) of Linux. Should discuss with Linux remoteproc maintainer & only consider it if they require us to implement that.
    • Tanmay will notify Mathieu in the cover letter of the patch relating to System Reference PR100 (vdev) that Linux setting status to 0 is violation of virtio spec
    • Tanmay: If we implement new mechanism, then existing firmware may break
    • Arnaud: ST uses attach & detach, but don't reattach when reboot Linux. Cortex M boots first and shuts down last.
    • Tanmay: When we boot in sync is fine, but some systems can be configured to boot independently
    • Tanmay: When implement, do we need to load, reload clean resource table on detach?
      • It's remote's responsibility when it sees the detach instruction from Linux it should reload clean resource table & set status to 0
    • What happens to vring addresses across detach? There could be 2 cases & believe the 2nd one is what happens:
      • Resource table provides vring addresses
      • Resource table has placeholder 0xFFF… and Linux populates the addresses
    • Andrew will take a look at this PR & comment from TI perspective
  • https://github.com/OpenAMP/openamp-docs/pull/82
    • Tanmay will take a look
  • https://github.com/OpenAMP/open-amp/pull/680
    • Tanmay will take a look
  • https://github.com/OpenAMP/open-amp/issues/679
    • TI board -> Could Andrew help test it?
    • Did anyone test the driver side with cache?
    • Andrew: think should happen on any board but most don't enable cache
      • Tanmay: Our baremetal & FreeRTOS demos use cache & we implemented the libmetal interfaces & that works so not sure if anything missing on OpenAMP software stack
    • Ben: Could MPU affect payload sending?
      • Arnaud: Have not seen on Cortex-A side w/ MMU. Think is cache issue, not sure if in Zephyr or in OpenAMP itself
    • Tanmay:
      • Arnaud: There is one with MCU-MCU and no remoteproc virtio used & no cache managemetn for host part (rpmsg driver) so it's not tested yet
    • Andrew: Have been intending to add back the more granular cache management flags (were previously removed for some reason & were useful)
      • Arnaud: Had removed to simplify b/c no one had said they needed it
      • OpenAMP granular cache management flags had been removed to simplify the code since we thought no one was using it. TI had missed raising AM62 use case (big Arm + MCU).
    • Arnaud: Hypothesis: Coming from buffer (not vrings) but need someone to check
    • Andrew: We are trying to do Zephyr on big Arm core + libmetal + OpenAMP + caching, which is kind of unique. Not sure if specific to us, or it's because this is the first time someone is trying this
    • Let's wait to see what Sunil replies
  • Feature freeze at end of this week
    • Arnaud will do non-regression test in last week of April
    • Would like folks to test on their platforms
  • What version of Zephyr for this release?
    • Arnaud will test with master
    • System Reference & OpenAMP docs will target to release May
    • Zephyr 4.4 got released today
      • Today, the CI builds with master, so it is building with 4.4
    • Tanmay to confirm which of Zephyr 4.3 or 4.2 has GIC safe config for R5 in split mode
    • Zephyr has moved to April & Oct release cycle -> we probably will merge OpenAMP release just after Zephyr release so OpenAMP 2026.04 will be in Zephyr October release. Might be interesting to try latest Zephyr release unless we hit issues in testing.
    • Arnaud will set Zephyr version to 4.4 for the stable testing
  • Tanmay: For ZynqMP we have a workaround for Zephyr demo & wondering if can have patch in OpenAMP staging. Tanmay will work with Ben to figure out if it's upstream.
    • Tanmay to file GitHub issue in System Reference & point to the patches that are needed for ZynqMP workaround for Zephyr demo
  • Next meeting: Discuss Arnaud's proposal for 1st draft of OpenAMP security policy

2026-04-08

Recording link

https://amd.zoom.us/rec/share/PRPutbHhmT9fahVwGjtKSg942F7pREAXkkmrXyvi_JnDSdxBruevGrJZUCYpS4g.k4Y-Dfz6fastv2f8 (Passcode: $y=%f6i&)

Attended

  • Arnaud, Ben, Ed, Tanmay, Nathalie, Stefano, Bill

Agenda

Decisions/conclusions

  • Tanmay's udev rules demo is in the right direction & is going into examples area, so it can evolve over time
  • OpenAMP needs to decide what we want our security policy to be & publish it so that people know how to report & what to expect when a vulnerability is reported. It can be much simpler than what Xen has.

Actions

  • (DONE) Tanmay will think through how to solve the duplicate names in udev rules implementation
  • (DONE) Nathalie to review what Tomas presented last week on System DT & sync w/ Stefano
  • (DONE) Ed to review https://github.com/OpenAMP/libmetal/pull/357

Notes

  • Tanmay: RPMsg Udev rules demo
    • AI summary:
      • RPMsg communication without root via UDEV automation
        • Addresses the need for user‑space apps to communicate with remote processors without root
        • Uses UDEV rules to create RPMsg devices with user‑space permissions
        • Automatically runs scripts when RPMsg devices appear
        • Creates channel‑name–based symlinks so apps don’t need device details or sudo
      • Symlink design and configuration considerations Two symlinks are used to preserve device‑to‑channel mapping information
        • Bill suggested using the DT node name tied to virtio as a stable unique identifier
        • Avoids reliance on device creation order
        • Translation/configuration should live in a user‑tweakable location (e.g., /etc, not binaries)
      • Handling duplicate names and unnamed static endpoints
        • Duplicate channel names and unnamed endpoints were identified as open issues
        • Options discussed: device‑name–based naming or a placeholder like “None”
        • Tanmay agreed to further explore solutions
        • Vendor‑specific rules may vary, but common scripts should be shared
        • Providing examples lets downstream users customize as needed
    • Udev rules set up to execute scripts for various cases
    • Symlinks set up for endpoints
    • Autoboot feature: All the devices will be set up automatically under /dev & apps set up w/ channels for user who is part of rpmsg group & can do rw directly without needing sudo/root privileges
    • Need to know which channel is mapped to which device for removing devices
    • Arnaud: Why do you have to symlink?
      • Tanmay:
        • If destroy current RPMsg EP device rpmsg0, have to unlink the symlink as well
        • How to know this symlink is mapped to a given RPMsg device? Udev event will be generated after all the info is gone -> have another symlink that keeps the device info available
      • Bill: Could use readlink to access the text of the symlink, might be cleaner
    • Bill: Where does rpmsg-openamp-demo-channel name come from?
      • Tanmay: Through a name service announcement of the remote processor
    • Bill: What if 2 announce same name?
      • Tanmay: Wanted to discuss. User must enforce unique channel names. Also, "." used to separate channel name vs. endpoint, but name string can't use "."
      • Bill: if they're always there, you can take the last 2 dots & middle dots in the name don't matter. Can parse.
    • Bill: This is great work & has been on to-do list for years
    • Bill: Since we're creating symlinks anyway - would prefer if called rpmsg-openamp-demo-channel-1 or similar. Or, could map/give translation table.
    • Tanmay: How does app know which one to communicate to?
      • Bill: Usually, if you have 2 R5s you are assigning different tasks to each R5. This adds more info. You could also do *.unique-channel-name, but having actual device name would be better
    • Tanmay: If RPMsg0 device is already available, kernel will keep incrementing # for next devices. What if we pre-pend channel number
      • Bill: But, won't give you physical topology.
    • Bill: You can cat the remoteproc0/name to get the DT info
      • Ben: Reads part of the reg & could have duplicate?
      • Bill: DT spec requires unique stuff after the @
      • Arnaud: Create name that is DT-dependent, so app must know address
      • Bill: could have a translator script under udev rules that could accommodate different DTs that map to R50
    • Bill: Don't want non-binaries in /usr/bin -> either in etc or /usr/share
      • User-tweakable custom configuration file -> better to put in etc
    • Arnaud: for /dev/rpmsg0, 1 can create static endpoint w/ source & destination, but not necessary to provide a channel name (you'd have to check) - suggest to try experiment
      • Bill: What placeholder name to use when creating symlink?
      • Tanmay: Suggest to use device name
      • Arnaud: Or not create symlink b/c no service name
      • Bill: Or use "none"
    • Tanmay: Scripts can stay common, but rules may be vendor specific?
      • Bill: Prefer to keep as much as possible common
      • Arnaud: Can provide reference & see if ppl customize it
      • Bill: Distros often just take the example & run with it
    • Tanmay will think through how to solve the duplicate names
    • This is a good way to go & is going into examples area, so it can evolve over time
  • PR 94
    • Ben has updated the README
    • Tanmay will check & provide input & notify Arnaud when ready for review
  • PR 102
    • Ben will work through GitHub discussion with Arnaud
  • System DT
    • Nathalie to review what Tomas presented last week & sync w/ Stefano
  • Stefano: EU CRA
    • AI summary
      • Limited EU CRA impact, but a security contact is needed
        • Open source projects like OpenAMP are largely exempt
        • Actionable item: establish a security contact (e.g., GitHub issues)
      • OpenAMP should publish a simple, transparent security policy
        • Define how vulnerabilities are reported and handled
        • Pre‑disclosure lists were rejected as overly complex
      • Further discussion required
        • Direction agreed, details to be finalized
        • Topic deferred to the next meeting
    • Security updates need to be provided & applied in a timely matter
    • OSS projects typically have wide exceptions b/c we don't ship a product -> typically EU CRA applies to the deliverable that gets deployed
    • Does OpenAMP ship binaries? System Reference only provides example reference binaries, so not much EU CRA would apply
    • Would need to have a security contact where ppl can report security vulnerabilities to
      • In Board meeting, we had discussed having it in GitHub issues b/c no pre-disclosure requirement
    • OSS project should have a security policy: Document in public: What steps will OpenAMP take (or not take) when security issue is reported?
      • Do we keep it a secret?
      • Do we pre-disclose it to anyone?
      • When we have a fix, how does it get delivered?
      • On which version, should we apply the fix?
      • What is security-supported & what is not? Not everything needs to be security supported
      • Bandwidth is a challenge, so difficult to uphold commitments to turnaround time
      • OpenAMP is a small code base, so expect not many vulnerabilities will be reported
    • Arnaud: Does Stefano have an example of security policy description?
      • Stefano: https://xenproject.org/about/security-policy/ Xen is pretty sophisticated b/c has pre-disclosure list for large deployers to protect themselves against attackers. Pre-disclosure list takes extra work b/c also need to vet the pre-disclosure list members. Don’t think OpenAMP needs pre-disclosure list.
      • Embargo means how long it's kept secret by the project before telling anyone
        • Vulnerability researcher wants to resolve & publish as fast as possible
        • Researcher can publish it on their own ahead of the embargo date & force Xen's timeline
        • Would mean we need a security team reporting list
        • Bill: Even if you don't have a disclosure list, you can work up your fix to the problem before it's made public
        • Would have to be careful about public-viewable CI results for testing the fix
    • Arnaud: There is no pre-disclosure list common to all projects?
      • Stefano: Closest is Linux distro security list
    • Ed: We don't even know who our customers are b/c OpenAMP is shipped with other things, so we are multiple levels of indirection away
    • Arnaud: Disclosure list could be the members?
      • Stefano: Also need to decide in security policy if it is OK to disclose to rest of your company
    • Stefano: Transparency of the policy is more important than the actual decisions
  • April Feature Freeze

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
  • (OBSOLETE) Bill to invite Daniel from NXP to OpenAMP Discord to see if he can help with testing on NXP for release
    • Iulia will help with the testing for release for NXP
  • (DONE) 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

  • (DONE) 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
  • (DONE) 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
  • (DONE) 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

  • (DONE) 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
  • (DONE) 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** ⚠️