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

Table of Contents

2025-12-17

Attended

  • Tanmay, Arnaud, Bill, Nathalie

Agenda

  • Congratulations on 2025.10 System Reference release!
  • Recent PRs
  • Any Zephyr topics?
  • Compile OpenAMP docs improvement project wishlist
  • 2025 task tracker / individual updates
  • Happy holidays! Next meeting: January 14th, 2026

Decisions/conclusions

  • New rootfs with latest libraries for KV260? Target February so that it's updated in April release
  • We don't use checkpatch review on CI PRs

Action items

  • Tanmay will provide baremetal binaries when Bill is ready to update rootfs with latest libraries for KV260
  • Tanmay to create GitHub issue as reminder to add some documentation to tell how to include the Xilinx libraries, build libmetal & extension (libmetal PR350)
  • Ben to convert System Reference PR83 & PR87 to Draft PRs so that we will know when it is ready for others to look at
  • Bill will add approval to open-amp PR672 so Arnaud can merge
  • Nathalie to file a GitHub issue as a reminder for Arnaud to look at the GitHub Actions to account for not using checkpatch review on CI PRs
  • Nathalie to file GitHub issue: Find way to get more free space on GitHub runners for the Zephyr build -> assign to Bill to look at after he's done w/ 2025 virtio stuff
  • Nathalie: Put on agenda for February:
    • Safety certification of libraries
    • System reference: Updating rootfs to include latest libraries for KV260

Notes

  • Congratulations on 2025.10 System Reference release!
    • Docs, system-reference up-to-date now
    • New rootfs with latest libraries for KV260? Target February so that it's updated in April release
      • Tanmay will provide baremetal binaries when Bill is ready to update rootfs with latest libraries for KV260
  • Recent PRs
  • Any Zephyr topics?
    • CI: Do we have space in the docker image b/c SDK takes space?
      • https://github.com/OpenAMP/open-amp/blob/main/.github/workflows/continuous-integration.yml#L57
      • Separated Zephyr out to its own job? Not yet, to get around the space issue this time, Arnaud cleaned up the image just before running the build
      • Base VM layer has all the tools & then we run a container in it, but the container only gets what free space the VM had
      • We're using the generic GitHub runner image & the free tier, but running out of space. One option: Could use a custom Ubuntu image to expand free disk space for Zephyr - would cost a small amt of $ per month (probably <$5)
      • Nathalie to file GitHub issue: Find way to get more free space on GitHub runners for the Zephyr build -> assign to Bill to look at after he's done w/ 2025 virtio stuff
  • OpenAMP docs improvement project topics?
    • Arnaud created a wish list document. Let's list everything we want, regardless of who would be the most appropriate author & then we can discuss priorities and availability
    • Documenting AMD System DT flow?
      • With SDT, AMD can use all open source tools to generate BSP
      • Rootfs should include the firmware that is built using SDT flow
      • Baremetal firmware binaries build from Yocto: Can do that in a Xilinx full-stack way with EDF if Tanmay provides to Bill the target names to get the firmware images
      • This would be an improvement to what we have now
    • Intro to virtio-msg work?
      • Let's get to an aligned method using Zephyr before we put into docs
      • STM32 board sample is generic but not aligned w/ current specification & kernel
        • Could be interesting for split between libraries
      • Might have another vendor interested in Zephyr as driver side w/ console, net & block
      • Dan already pushed some code for driver side for virtio-mmio & would need updating before we fold it into the documentation
      • Xilinx QEMU & Sapphire 5050A platforms work, but nothing on ZynqMP yet
      • When we get Zephyr into the mix, would like to see it work on ZynqMP & Sapphire 5050A & STM32MP2
      • ST: Linux part not upstream yet -> Target 1H2026.
  • Next meeting: January 14th, 2026

2025-12-03

No notes?

2025-11-19

Attended

  • Tanmay, Andrew, Ed, Iulia, Nathalie, Bill, Arnaud

Agenda

  • 2025.10 release topics
  • Dec 3 meeting
  • Recent PRs
  • Zephyr topics
  • Docs topics
  • Individual status

Decisions/conclusions

  • Leave Dec 3 in calendar. Arnaud can lead & Tanmay can be Zoom host. If no topics, then Arnaud can notify folks by email/discord closer to the date.
  • With upstream Zephyr upstream support for STM32 MP25, OK to make PR for System Reference (even while Linux upstream is outstanding)

Action items

  • Arnaud will propose closer to the date if keep or cancel Dec 3 meeting based on # topics for discussion
  • Arnaud will tag 2025.10 System Reference & docs release when it's time
  • Arnaud will submit PR for STM32 MP25 to openamp-system-reference
  • All interested: Participate in IPM -> MBOX discussion on Zephyr GitHub https://github.com/zephyrproject-rtos/zephyr/discussions/99529
  • All: Think of your OpenAMP documentation priorities & bring to Dec 17 meeting
  • Nathalie: Put documentation initiatives prioritization on agenda for Dec 17 meeting

Notes

  • Dec 3rd: Keep or cancel? Let's keep it. Arnaud can run it. Tanmay will be available as secondary host.
    • Will discuss on Discord if want to cancel, closer to the date
  • https://github.com/OpenAMP/openamp-docs/milestone/1
    • All PRs in for 2025.10
    • 1 doc PR remains for 2026.04 release
  • https://github.com/OpenAMP/openamp-system-reference/milestone/1
    • Tanmay added 1 more PR & has to push an additional change
  • 2025.10 System Reference & docs release
    • Arnaud can tag
  • Iulia started Mailbox & IPM discussion on Zephyr project. Folks can go there to participate in the discussion
  • https://github.com/OpenAMP/open-amp/pull/630
    • Arnaud closed it & notified the requestor to reopen if needed
  • Zephyr topics
    • Arnaud pushed PR for support for STM32 MP25 board w/ Cortex-A35. Should push PR for openamp-system-reference w/ upstream Zephyr, before having upstream Linux that supports, or wait to also have Linux upstream support?
      • Bill: Preference is full upstream support, but this moves us towards 64-bit preference. If Linux will be upstream next release, then it's fine.
      • Arnaud: Want to finish remoteproc TEE
      • Bill: AMD has some code that only works on their FreeRTOS or baremetal, so can get started with PR. It's open enough to start.
      • Arnaud will submit PR with metal layer
  • OpenAMP docs
    • Will notify Sipke for 2026
    • Will put on agenda for Dec 17 about priorities for docs improvement
    • Need to improve how to integrate OpenAMP & libmetal for new platforms -> a guide for that
    • If other folks have needs they've identified, would be good if they can bring their ideas
  • Individual updates
    • Tanmay: Working on system reference demos

2025-11-05

Attended

  • Iulia, Tanmay, Andrew, Arnaud, Nathalie

Agenda

  • Iulia Q1CY26 coverage
  • 2025.10 release topics

Decisions/conclusions

  • IPM deprecation in Zephyr: will not add new IPM drivers, just mailbox. But not everyone is converted over yet - Andrew trying to motivate ppl to convert by having only IPM to mailbox wrapper & not the other direction.

Action items

  • All: Please prioritize openamp-system-reference & openamp-docs repo reviews so that we can release this month
  • Tanmay: Specify in upcoming PRs if it is intended for this release or next.
  • Iulia: Will have to check if IPM maintainer is responsive & if not, will talk to Carles or Anas to find out IPM deprecation schedule

Notes

  • Iulia colleague coverage for first few months of 2026
    • He's more involved in remoteproc / Linux, so might just attend Bill's call & not join System Reference
    • Will try to stay involved with Zephyr reviews in first few months
  • 2025.10 release topics
    • Please prioritize openamp-system-reference & openamp-docs repo reviews so that we can release this month. Have some open PRs in these repos still
    • Which ones in system-reference for this release?
      • Tanmay will push 1-2 more for demo release that will fix more things in FreeRTOS. Specify in PR if it is intended for this release or next.
  • Recent PRs
    • PR83: Don't need to release the Xilinx-specific cmake stuff in 2025.10. PR88 covered the bug fixes
    • PR89 is not needed for this release & still discussing the architecture & if it should go in.
      • Arnaud: Andrew made IPM to mailbox wrapper in Zephyr so you can have IPM redirected to mailbox driver
      • Tanmay: When we say IPM is deprecated, does it mean Zephyr will remove it at some point?
      • Arnaud: If you want to add new, need to use mailbox, you can no longer create an IPM driver
      • Iulia: Agree. Discussed w/ Carlo Caione. He said same: Will not add new IPM drivers, just mbox.
      • Tanmay: If IPM is deprecated, then should we still use IPM API in user space? If don’t want IPM at all in Zephyr binary, could introduce mailbox in user space. So eventually don't need the IPM infrastructure in binary.
      • Andrew: Not everyone is converted over yet. There are still some IPM-only platforms. Once everyone is converted over, we can then remove the framework.
      • Tanmay: Providing optional API to use mailbox from user space. If not now, may need this later.
      • Andrew: Maybe need shim from mailbox to IPM. Think not that many IPM platforms left. Maybe you should just get the Zynq platform converted over.
      • Arnaud: ST has IPM b/c upstreamed before mailbox & don't plan to convert unless decision to remove IPM.
      • Tanmay: Might get rid of ZynqMP from user space demo & just focus on Versal. This change provides option to use mailbox-only API from user space.
      • Arnaud: System reference sample could try to support both w/ config, even if not the case in Zephyr.
      • Tanmay: Will have to sync w/ Zephyr team. This change wouldn't hurt if it goes in eventually.
      • Andrew: You've got a bunch of switch cases to support both, you could either just support IPM or wait and switch over to mailbox. I would wait.
      • Arnaud: Maybe mailbox-IPM wrapper?
      • Andrew: Since deprecated, maybe we just use mailbox in applications, that might force ppl to convert.
      • Arnaud: Depends if want to be platform-agnostic or not.
      • Tanmay: May make a few ppl unhappy
      • Arnaud: May also force customer to rebase to new version
      • Tanmay: Which vendors are still using IPM? Since Carlo is no longer maintainer, whot to do?
      • Iulia: There are lots of other samples using IPM in Zephyr. So, would be a lot of effort to update all the samples. We can start w/ OpenAMP resource table samples with just a few boards to change to mbox, as proof of concept.
      • Arnaud: But then would no longer work for STM32
      • Tanmay: We'll enable the conversion driver, but at some point we'll have to move to mailbox API. Or, keeping both options will give vendors time to move from 1 framework to another
      • Andrew: Didn't want to make mailbox-IPM b/c want to have a migration path, but only in 1 direction
      • Arnaud: Should discuss in Zephyr Architecture meeting & decision addressed in Zephyr first
      • Iulia: Right now Zephyr is in release mode, so everyone is focused in bugfix
      • Andrew: Maybe can ask the IPM subsystem maintainer what their deprecation schedule is
      • Iulia: Will have to check if IPM maintainer is responsive & if not, will talk to Carles or Anas to find out IPM deprecation schedule
      • Arnaud: If STM32 is only one remaining that's blocked then will have to move it to mailbox, but if more then will be more complex
  • Zephyr
    • Arnaud updated with latest OpenAMP libraries release
    • Iulia tested on NXP boards & works
    • Should be in next Zephyr release in a couple weeks
    • Arnaud will merge the libmetal & open-amp module & update the Zephyr PR so that it's ready for merge
  • Individual updates
    • Tanmay working on latest system-reference & will create PR soon with fixes that is tested w/ latest library. FreeRTOS is working there on AMD-Xilinx platforms.
    • Tanmay working on making metal-log framework standard in demos. Today, Xilinx-specific API is being used, so standardizing to metal-log API & will create PR for this as well. Not required, but nice to have in 2025.10

2025-10-22

Attended

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

Agenda

  • Define a target for the system-reference and openamp-doc repos release
  • Non-regression testing for 2025.10 release
  • Other 2025.10 release topics?
  • Recent PRs
  • Any Zephyr topics?
  • OpenAMP docs improvement project topics?
  • 2025 task tracker / individual updates

Decisions/conclusions

  • System-reference release: Target 1 month after libraries release
  • We should leave open-amp PR 632 open

Action items

  • Ed will check if Vitis on Arm Linux is still not working & share details about the issue to Tanmay.
  • Arnaud & Tanmay to discuss in more detail in a new GitHub issue - Arnaud will file it
  • Tanmay will review libmetal PR 335 today

Notes

  • When should we release system-reference? Is it OK to do 1 month after libraries release?
    • Bill, Tanmay & Ben are OK with 1 month later
  • Non-regression testing for 2025.10 release
    • Target is to finish the tests for end of next week
    • Ed, Tanmay will test this week
    • Tanmay: Demos won't work until we release the libmetal-xlnx in 2025.2 (~Nov)
    • Ed: I can't currently build Xilinx b/c Vitis doesn't work on Arm Linux even with X86 emulation enabled. Checked support forums last time & they seemed to indicate that no one planned to fix it in Vitis.
      • Ed will check if Vitis on Arm Linux is still not working & share details about the issue to Tanmay.
    • Tanmay can build images if anyone else wants to try on KV260
    • Arnaud: For tests that are not possible, just tag it as such
  • Other 2025.10 release topics?
    • https://github.com/OpenAMP/libmetal/pull/346
      • Libmetal pull request to revert something that breaks on ST platform
      • Tanmay prefers not to have anything vendor-specific there
      • Arnaud not aware of others defining using template platform. We don't define our own b/c the template matches.
      • Maybe good to put a warning instead of deprecation, that it's an entry point to help develop your own machine
      • Tanmay: If we deprecate, could maybe move to system reference?
      • Arnaud: Would still need to implement some libmetal function
      • Tanmay: Could link during compile time. Libmetal can be complied as a library & doesn't need implementation. When building demo, then link the extension w/ the demo, so the demo will compile.
      • Arnaud: How to specify the machine in libmetal cmake? So, today you can't build libmetal w/o machine & have to add machine for your own platform, even if it's the dummy platform
      • Tanmay: Machine is Arm64 & not vendor specific?
      • Arnaud: It's a generic/baremetal, so need vendor specific
      • Arnaud & Tanmay to discuss in more detail in a new GitHub issue - Arnaud will file it
    • https://github.com/OpenAMP/libmetal/pull/335
      • Changes not in ahead of the freeze, so have tagged it for 2026.04 & will apply just after the release
      • Even if for next release, Arnaud would still like to complete reviews & merge this soon b/c the author is currently engaged
      • Tanmay will review libmetal PR 335 today
  • https://github.com/OpenAMP/openamp-system-reference/pull/82
    • Waiting for Iulia to confirm
    • Arnaud will add comments if have any
  • https://github.com/OpenAMP/openamp-system-reference/pull/83
    • Arnaud is waiting for feedback from Tanmay
  • https://github.com/OpenAMP/openamp-system-reference/pull/87
    • Arnaud will look at it after the 2025.10 release
  • https://github.com/OpenAMP/openamp-docs/pull/70
    • Arnaud provided suggestion for Sipke to address
  • https://github.com/OpenAMP/openamp-docs/pull/71
    • Arnaud suggested enhancements for Sipke to incorporate/improve upon
  • https://github.com/OpenAMP/openamp-docs/pull/72
    • Sounds like Sipke could use some clarity on what is desired for the update. He took a stab at it.
  • https://github.com/OpenAMP/open-amp/pull/632
    • CV-Bowen to come back with another PR in libmetal & then update open-amp PR 632, so we should leave open-amp PR 632 open
  • https://github.com/OpenAMP/libmetal/pull/343
    • Dchordia actions pending - needs to set up build environment
    • Will discuss registering for QNX license after release (is there a cost?)
    • e.g. for NuttX we don't do any tests. If not possible, could accept the porting layer for QNX without CI, but prefer to have CI
  • Any Zephyr topics? None
  • Any OpenAMP docs improvement project topics? None
  • Individual updates: none

2025-10-08

Attended

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

Agenda

  • Recent PRs
  • Any Zephyr topics?
  • OpenAMP docs improvement project topics?
    • Do we need to request OpenAMP Board to approve more funds for 1HCY26?
  • Any 2025.10 freeze topics? (Feature freeze 10/18)
  • 2025 task tracker / individual updates

Decisions/conclusions

  • Health check errors in 2 open-amp PRs are not related to the PRs themselves, so can ignore
  • As we go through the October release, raise issues in docs GitHub repo & in parallel seek Board approval for the docs contracting spend

Action items

  • Arnaud will rerun the CI to see if it resolves the health check issue in open-amp repo
  • (DONE) Nathalie to tag the author of PR 335 to let them know feature freeze is coming up 10/18
  • Andrew will add couple more patches to libmetal PR 287 to clarify the big picture that it would reduce the binary size
  • Iulia will send email to introduce NXP colleague to OpenAMP contributors

Notes

  • Recent PRs
  • Zephyr topics
    • None
  • OpenAMP docs project
    • Bill would like to seek Board approval for contracting extension into 2026 at 2 days/month but Bill & Arnaud will authorize specific work
      • Bill thinks a lot of demo write ups need to get updated & project members need to take the lead on those, but would like to see it get unified
      • As we go through the October release, raise issues in docs GitHub repo & in parallel seek Board approval for the docs contracting spend
    • Arnaud merged main-next branch to main
      • So Sipke can put PRs to main, unless it's a major refactoring
  • Feature freeze 10/18 topics
    • None
  • Individual updates
    • Arnaud: Docs done
    • Iulia: Don't think this task will be done soon due to upcoming leave. Colleague will join the openamp-rp meeting & maybe system reference. Will try to review openamp in Zephyr 1-2x/week, since in maintainer role.
      • Iulia will send email to introduce NXP colleague to OpenAMP contributors
    • Tanmay: No update on these tasks. Have task being discussed in openamp-rp call.

2025-09-24

Attended

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

Agenda

  • Active PRs for discussion
  • Any Zephyr topics?
  • OpenAMP docs improvement project topics?
  • Any 2025.10 freeze topics? (Feature freeze 10/18)
  • 2025 task tracker / individual updates

Action items

  • Tanmay will spend some time to learn the test framework to be able to review libmetal PR 335

Notes

  • https://github.com/OpenAMP/openamp-system-reference/pull/82
    • Ben's waiting for reviews
  • https://github.com/OpenAMP/open-amp/pull/661
    • Sipke gave thumbs up
    • Arnaud will send PR next -> main. Will add task to tracking sheet
  • https://github.com/OpenAMP/open-amp/pull/655
    • Iulia reviewed & Arnaud will merge
    • Tanmay will continue sending cleanup PRs to update docs in the repo
  • https://github.com/OpenAMP/libmetal/pull/287
    • Arnaud not convinced need this PR b/c doesn't fix anything & increase the footprint of the code & would like to see revision to move forward
      • Tanmay: Agree. OK to keep PR open until we see actual use case to see device use this ops. On Zephyr usually doesn't make sense to use metal device & ppl usually prefer to use Zephyr's device. If see someone trying to use it & overriding the bus ops or there's a demo, then can consider it.
      • Arnaud: In Zephyr, it's not recommended to use metal device.
  • https://github.com/OpenAMP/libmetal/pull/335
    • Arnaud: Intention is to make some generic tests to be able to test libmetal independent of the platform itself. Looks interesting & would like feedback from others. Could run these tests on Linux PC or in QEMU or AMD platform - may be useful for libmetal CI.
    • Tanmay: Would have to spend some time to learn the test framework
  • Any Zephyr topics? No
  • OpenAMP docs improvement project topics? No
  • Any 2025.10 freeze topics? (Feature freeze 10/18) No
  • Individual updates
    • Arnaud: Remoteproc OP-TEE: Discussion w/ Sumit (Linux key contributor). Does anyone plan to use OP-TEE for signing firmware
    • Beleswar: Still waiting for patch by someone else to be merged. It's in queue & just waiting for after 6.17 RC to complete to get into 6.18 kernel.
    • Bill: No updates
    • Dan: Virtio-msg in Linux device: Synchronizing to Bill's latest source trees
    • Iulia: NXP platform with M7 support done & will be in 2025.10 release. Arm32 core: M7 w/ Zephyr, A core w/ Linux
    • Tanmay: Still working on Attach on recovery feature fix in Linux Kernel RPMsg
  • Beleswar: Looking into virtio & had some questions
    • Trying to compare open-amp vs. Linux implementations
    • When we initialize the shared variables, are we putting all the descriptors in the used ring?
      • Today, yes.
    • Master put half buffer in used ring & half in available ring.
    • Communication master to remote & remote to master.
    • At initialization all the descriptor go in the memories & all the buffers are allocated. When you send message from remote to master, you request an available ring buffer & feed it & put it in used ring buffer & send kick to master.
    • Master initializes & allocates all the buffers & feeds the vrings with all the buffers.
    • Resource table specifies # of buffers but not size
    • Having a fixed number of messages & pre-populating them at init time is RPMsg-specific, but used & available in use of rings is standard virtio stuff (e.g. take a look at virtio-net)
    • Available, used, tx, rx are defined from the driver's perspective (Linux side)
    • Used buffer on RX means it has data in it
    • Used buffer on TX means I'm done, I've transmitted the data & can discard it now
    • Currently, when you're talking to Linux, you’re the remote
    • On Linux side, have a memory allocator, so can allocate & free buffers in a dynamic way
    • In OpenAMP, we have no memory allocator
    • Discussed buffer recycling mechanism…You need to differentiate between master & remote AND TX & RX (you have 2 queues).
    • Virtio spec is a good resource to understand virtio, but there's a bunch of stuff in there that RPMsg doesn't use b/c it's for small processors
    • There are also some presentations from Linaro Connect on YouTube that may help demystify

2025-09-10

Attended

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

Agenda

  • Pull requests
  • Docs project
  • Individual updates / task tracker

Decisions/conclusions

  • For Xiaomi pull request 632 in open-amp: Should be handled in libmetal. Would be good to find out if their use case is time-sensitive trace.
  • OpenAMP docs PR60 system diagram is a big improvement from what we had before & can be merged to main.
  • For OpenAMP docs: OK to merge incremental stuff to main & just have the big changes stage to main-next.
  • In AMD's Zoom configuration, it only seems to output transcript if it's activated during the meeting & explicitly saved, even though we get the automatic transcription notice at the start of the call.

Action items

Notes

  • Note: System Reference call is being extended to cover open-amp and libmetal libraries. The Thursday RP call will focus on kernel.
  • Xiaomi https://github.com/OpenAMP/open-amp/pull/632
    • Want traces in circular buffer, similar to ftrace, to be able to debug race conditions, see if called API, etc.
    • Arnaud thinks need more traces in RPMsg. Do we need to address in libmetal or have specific function for ring buffers in open-amp library?
    • Tanmay: Can add more logs w/ existing framework. Don't see requirement for introducing whole new function for metal trace. Can use RPMsg debug option & debug level functionality or metal debug. If they want to log into RAM they can use trace buffer functionality. From Linux side, they can retrieve those logs. Don't have to have to differentiate between UART & trace buffer.
    • Arnaud: So we'll let Xiaomi implement their own metal logs.
    • Ed: Issue is that metal log is inherently text based (involves printf & fair bit of computation for something that might be timing sensitive). Prior experience doing kernel-level trace debug w/ timestamps & couple bits of payload - that can be very quick & examined offline & turned into text when needed. So, that is a use case. Not sure if Xiaomi is dealing w/ time constrained environment.
    • Arnaud: So you store ID & then you have parser convert to text, or some compressed trace. Would be difficult to address in the library. Requirement is to be able to trace the API, so should do in own environment when calling wrapper in NuttX.
    • Ed: Don't know that we could do in a good generic way in open-amp or libmetal, but it could be a valid use case that is different from logs.
    • Arnaud will reply on the PR
    • Tanmay: Or maybe they can implement metal log handler based on log level. Could introduce a log level called time sensitive that would not log on UART.
    • Arnaud: May be parallel traces here. In libmetal would need 2 levels of traces: what we have today outputting to serial port & another for time sensitive traces. Could introduce specific log that is out of the log level for sensitive & say need to set libmetal configuration to output it. 1st step may be to update the PR to say what is missing in the RPMsg layers. Today, the PR is only to introduce trace callback & not really use it.
    • Tanmay: Could this slow down our current SW stack if introduced permanently?
    • Arnaud: Would be disabled by default. But would slow down if enabled & especially if in text format. Let's continue discussion on the PR.
    • Tanmay: Think each platform & project would need implementation. Could provide callback in libmetal & user can implement however they want.
    • Arnaud: Yes, main point is it should be done in libmetal.
  • Docs improvement project
  • Individual updates
    • Andrew: no update
    • Arnaud: no progress. Some discussion on maing liss wrt OP-TEE remoteproc between Qualcomm & Arm. That could help to integrate it in Linux.
    • Bill: call docs tagging done
    • Dan: No update
    • Tanmay: Done 19. Dong some demo changes to accommodate new plugin we developed. For Oct release, Xilinx demos (especially baremetal & freeRTOS) will be broken b/c plug-in is in embeddedsw which is going in 2025.2 release that goes out in November. Until that plugin is released, the demos won't work. Will provide instructions to compile the plugin. #26 done, merged lots of downstream patches. Next #4 - have to revive a patch from Xiaomi. Also working on attach on recovery feature in Linux kernel. In test
    • Arnaud: We can put something in release notes.
    • Ed: No update. Will get caught up on what system-reference is up to.

August holiday break, no calls

2025-07-23

Attended

  • Tanmay, Dan, Iulia, Arnaud, Ben, Nathalie, Beleswar, Bill

Agenda

  • Recent PRs
  • Zephyr topics
  • OpenAMP docs topics
  • Task tracker
  • Reducing redundancy between System Reference and RP call
  • Manish's question on Discord about Raspberry Pi

Decisions/conclusions

  • A platform would be considered "officially supported" if it has an OpenAMP Zephyr demo.
  • OpenAMP-RP call will become kernel focused

Actions

  • (DONE) Nathalie: Cancel Aug calls. Resume in alternate weeks to RP call starting Sept 10. Invite Ed.
  • (DONE) Bill: Reply to Manish on Discord
  • (DONE) Beleswar: Add task to task tracker

Notes

  • Recent PRs
  • Any Zephyr topics?
  • Should we invite Ed to this meeting and make RP just about kernel and/or move the calls to alternate weeks? The only additional attendees Thur are Ed & Matthieu
    • Bill can't move RP b/c Virtio-msg call is on Thurs
    • Or, we can just merge them into 1
      • Might not get enough time to discuss kernel, userspace, demos?
        • RP rarely uses the full hour
    • Drop Aug System Ref & Pick up Sept 10. Add Ed to invitation & let him know RP is optional for him b/c kernel focus.
  • OpenAMP docs improvement project topics? No updates since we only have Sipke 2 days/month.
  • Discord: Manish asks if OpenAMP officially supports Raspberry Pi. Would “official support” = has a system reference platform, so not “officially”?
    • If a platform has a Zephyr demo, then we'd consider saying that's officially supported
    • Bill will reply - what Manish is trying is hard to do without a hypervisor
  • 2025 task tracker / individual updates
    • Beleswar will add his task to the tracker. Waiting on a kernel dependency

2025-07-09

Attended

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

Agenda

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

Notes

2025-06-25

Attended

  • Tanmay, Ben, Nathalie, Arnaud, Iulia

Agenda

Actions

  • (DONE) Nathalie to follow up with Linaro about docs contract signature (OpenAMP Board approved the spend already)

Notes

  • Ben & Arnaud to discsuss: “[RFC] Proposal to add mailbox interface” sent to openamp-rp list --> Need Bill & Andrew for the call, maybe discuss for tomorrow
  • Recent PRs
  • Anything else to discuss for OpenAMP docs improvement project?
    • Sipke contract renewal is pending Linaro signature
  • Any Zephyr topics?
    • Arnaud has to review a patch for Iulia. Will try to look at it tomorrow.
    • Resource table update is merged.
    • Code freeze is this Friday for 4.2. They asked about updates for libmetal & open-amp & let them know that Arnaud already made the updates for 2025.04.
    • ST pushed support for STM32MP2 coprocessor in Zephyr for 4.2 -> will try to get into OpenAMP System Reference for next OpenAMP release. Bill interested in this b/c Cortex-A35 which is arm64.
    • ST looking into system with cortex-A & cortex-M running Zephyr w/ OpenAMP. Could be a nice topology to show & test remoteproc part of OpenAMP in Zephyr to load co-processor via OpenAMP remoteproc framework. Cortex-A loading Cortex-M. Have not started this work, but would like to.
    • Zephyr static vring example shows communication between 2 processors without remoteproc vdev or remoteproc virtio, just RPMsg layer & static memories w/ vring & buffers.
    • NXP
  • 2025 task tracker / individual updates
    • Tanmay: Looking at Xiaomi patch: Dynamic buffer allocation or fixed size buffers?
      • Arnaud: Dynamic would be nice, but would be quite complex. Will need to manage memory region w/ DMA allocation.
      • Tanmay: Makes more sense to have static buffer size w/ virtio config space then. Will raise in tomorrow's call. Aiming to send new revision soon

2025-06-11

Attended

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

Decisions/conclusions

  • Architecture overview diagram: we should lead w/ main being Linux kernel b/c that's what most ppl do.

Action items

Agenda

Notes

  • How vendors handle firmware requesting carveouts to Linux in attach case
    • Beleswar:
      • Remote processor booted by bootloader
      • Why do we need to have rproc_handle_carevout?
      • If processor is started by bootloader, it would have already parsed its resource table & carveouts & IOMMU mapping. Why do we need to do this in the attach case? Will zero stuff out.
      • Do other vendors use?
    • Tanmay: We don't handle IOMMU. On Linux side we have vrings and buffer. Believe this will zero out all those regions & probably try to use it.
    • Beleswar: See you have the carveouts statically in the DT, then not problem. Same with TI case, K3, we don't this part of code. In newer device, we will hit this part of code. Do other vendors announce this carveout
    • Tanmay: Maybe Qualcomm
    • Arnaud: Not ST
    • Iulia: NXP has own attach function that doesn't use carveouts. We have memory regions in DT.
    • Bill: Not sure if Qualcomm supports late attach, suspect not. You may be the first one encountering this problem.
    • Beleswar: Was discussing w/ vendor. maybe no other
    • Bill: IOMMU mappings won't survive between __ and __. Think can't fully null out this function
    • Beleswar: Bootloader doing IOMMU mapping. Store page tables in reserved memory in DDR. Pass reserved memory to Linux DT when starting Linux, so it is still reserved. Then don't need to do the mapping.
    • Bill: Then what happens if you reload new Firmware when kernel is running. Think you want to make this function aware of if you're doing attach or not. If you do attach, then skip the zero. May still be some more work to do. Think that's cleaner than modifying DT dynamically to sync w/ resource table, which might change at runtime. You're pointing out that this function needs to know that some of its work isn't appropriate when you do attach. Would be bold to say not applicable to any vendor at any time.
    • Nathalie: Pratapc from Qualcomm is on OpenAMP RP list
    • Bill: They don't participate. Suggest on kernel mailing list w/ RFC. Would get Bjorn Andersen's attention - the other maintainer besides Mathieu & Bjorn is at Qualcomm
  • Arnaud: Documentation architecture diagrams - Based on last proposal from Sipke: https://raw.githubusercontent.com/OpenAMP/openamp-docs/26ee69935f7ea2b77e999559a0e03e5a2a1b7de1/images/architecture/overview-architecture.svg , I would like to propose this version: https://drive.google.com/file/d/1utHiL9iwFz1SY4uNVcsNq0GVOpEoPOUv/view?usp=drive_link
    • Tried to update the boxes on remote side to have OpenAMP that rely on libmetal to access w/ peripherals
    • Removed the RPC - not really used today, so prob shouldn't go in arch overview
    • Put resource table on remote side
    • On Main side: not sure if proposal matches w/ expectations or if you prefer first one
      • Bill: Arnaud's is improvement. Would not try to show the main side being the open-amp library or the kernel on same diagram. Think we should lead w/ main being Linux kernel b/c that's what most ppl do. Get rid of OpenAMP & libmetal on main side & just talk about kernel. These diagrams are forming the initial understanding, s,o start w/ the simple case. Later can show that open-amp is capable of being main side & can do in a separate diagram if we want to show it.
      • Arnaud: Limitation on main side between kernel & user space?
      • Bill: Yes & maybe showing application interacting w/ dev-rpmsg in intro diagram.
      • Tanmay: Should we make Linux kernel main block & virtio-rpmsg in that?
      • Bill:
        • 1: Delete libmetal
        • 2: delete OpenAMP/Linux kernel -> everything inside Linux kernel
        • 3: Labels on arrow should go above arrow
      • Arnaud:
        • 4: Rework the main part to make it a picture of the Linux implementation & label it main/Linux
        • 5: Application box with /dev
        • Should check in .svg files
    • Arnaud: Don't want to put too much detail in Linux about IVI b/c later may have net-ivi, filesystem-ivi depending on virtio device driver we support. Can just limit to application & separating userspace from kernel.
    • Bill: Today, we have 3-node version of diagram & will come up with good picture 2-node diagram here. Then we kind of repeat the same diagram under other sections where we highlight a particular element. Not sure if those are necessary… would vote to delete the other diagrams.
      • Arnaud: Could have overview diagram & then could focus on each part. e.g. remoteproc based on ELF loader, rpmsg w/ virtio device & remoteproc virtio transport & virtio-msg.
      • Bill: Concern about more diagrams to maintain
      • Arnaud: OK to go with 1 diagram.
  • https://github.com/OpenAMP/openamp-system-reference/pull/76
    • Arnaud implemented some code to explain what see to manage suspend and resume of applications. Waiting for feedback from Ben. Easier to discuss w/ code than with words
    • Ben will look at it on Friday & test and reply back.
  • https://github.com/OpenAMP/openamp-system-reference/pull/77
    • It's a draft PR that depends on libmetal PR that removes Xilinx code
    • We'll discuss during tomorrow's RP call with Ed
    • This shows how will modify after xlnx bsp will be out of libmetal & how it would affect demos. Will make the transition as smooth as possible - hoping will still work for ppl using old libmetal
  • https://github.com/OpenAMP/openamp-docs/pull/45
    • Arnaud: We have some documentation in OpenAMP repo in doc folder. Can't recall if we decided to move to openamp-docs repo instead of staying in open-amp library. Would help to have reference to the code in the .rst file. Sipke proposed to move to openamp-docs and add breathe references. Should we migrate docs from open-amp to openamp-docs?
    • Bill: The API in the headers above the functions should stay
    • Arnaud: We keep all the doxygen generated (headers, structures) and move the architecture & design docs in open-amp to openamp-docs & link to readthedocs to access the documentation.
    • Bill: OK with that. Wonder what shape that documentation is in… it's hidden in reference section. It will probably take work to get it up to a higher standard if we put it in the main section.
    • Arnaud: Maybe let Sipke do it in openamp-docs branch & then we decide.
    • Bill: For integration, will need links from main documentation to doxygen generated info.
    • Arnaud: Agree. With breathe we don't point directly to the dox
    • Bill: Can go full in on Breathe & have TOC for reference. Are you suggesting that?
    • Think that Sipke references in one of the data structures & put it inline in the main docs, as one example. Think it would take a lot of work to re-do this to work that way.
    • Arnaud: Think he's done more than 1 example
    • Bill: Need a meeting w/ Bill & Arnaud & Sipke to discuss this topic
    • Bill: If Sipke can do a full breathe conversion in 2/days mo in a couple mo, but don't think will be that easy
  • https://github.com/OpenAMP/openamp-docs/pull/60
    • This is the arch diagram that we discussed earlier
    • Andre's comments will go away w/ Arnaud's updated diagram
  • https://github.com/OpenAMP/openamp-docs/pull/61
    • Bill & Arnaud already sync'd on this one
  • Zephyr
    • Arnaud pushed 2025.04 release on Zephyr but there is no more maintainer able to review & merge it.
      • Iulia tested on NXP board & commented. Can ping Benjamin to help move it forward.
      • Arnaud to put the OpenAMP 2025.04 update PR on Zephyr PR-help channel on Discord & contact Benjamin
    • Iulia proposed some time ago to become maintainer but haven't submitted the PR yet
    • Iulia: Can merge in libmetal together?
      • Arnaud: Will check, think maybe not for libmetal

2025-05-28

Attended

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

Agenda

Decisions/conclusions

  • Libmetal is abstraction interface & common API, designed with open-amp in mind
  • If Libmetal is a little bit lacking, can propose to extend it with the necessary features

Action items

  • (DONE) Ben & Beleswar to send Bill their Discord IDs
  • (DONE) Bill to add Ben & Beleswar to our Discord
  • Ben to split up the libmetal PR 332 to be addressed feature-per-feature & demo-per-demo
  • Bill will handle readthedocs for OpenAMP 2025.04 release
  • (DONE) Arnaud will provide commit ID to Bill for 2025.04 release of OpenAMP docs repo
  • (DONE) Dan will add tasks to the task tracking sheet
  • (DONE) Iulia will ask Arnaud on Discord & can do the update to have Zephyr use 2025.04 open-amp
  • Tanmay will open PR in system-reference and Ben will send new libmetal demo
  • Nathalie: Help Iulia get access to task tracking sheet

Notes

  • https://github.com/OpenAMP/libmetal/pull/332
    • Arnaud: Thought were not going to extend application for specific machine (maintain legacy ok)
    • Ben: Not adding new application. It is a big PR. Can split it up. It's extending support & robustness.
    • Arnaud: Looks like a lot of C files added (e.g. ipi-mb.c)
    • Ben to split up the libmetal PR 332 to be addressed feature-per-feature & demo-per-demo
  • Bill: Thought we were going to do similar to open-amp where we moved the applications to system reference. Is there an old PR to move them?
    • Tanmay: By Sergei, who's not at AMD. Thinking is to preserve the commit history where we upstream the code first, then move between repos.
  • Andrew: TI had some updates & new demos & we held off until it got moved to system reference & then will continue. These look new & independent - could be made in new location? TI platform support, fixes, new demos for libmetal is being held back.
    • Tanmay: Could add platform support regardless of demos. We want to update existing demos to pending changes.
    • Andrew: You're updating & adding, TI would like to do same if allowed.
  • Arnaud: Should we only accept demos that are multi-platform w/ platform layer to adapt the demo? Should we have specific repo (similar to Zephyr) 1-per platform?
  • Andrew: Wouldn't we want to move the platform agnostic demos to system-reference too, not libmetal?
    • Arnaud: There is a new PR on libmetal 335 for demos & tests for libmetal IPI. This is model that we could have on system-reference to have generic libmetal demo using libmetal API w/ implementation for different platforms
    • Andrew: Looks like unit tests?
    • Arnaud: Same principle
    • Andrew: Tests are fine, but demos have to be platform-specific b/c you run on a platform. Using libmetal as abstraction layer
    • Arnaud: But the top-level API should be common
    • Ben: Could we have stub reference that is template-platform specific w/ an AMP focus? Guessing TI would also have a host & remote w/ some simple libmetal demo?
    • Andrew: OpenAMP demo is best for showing libmetal, so would want to put the demos in higher layers. Not much value in doing libmetal standalone, it's built to run OpenAMP.
    • Ben: Can ignore my suggestion :)
  • Arnaud: Who else uses libmetal without OpenAMP, just AMD?
    • Andrew: TI doesn't use libmetal standalone. Have demos & were going to push to libmetal, but held off
    • Tanmay: Our demo uses libmetal in a standalone fashion.
    • Andrew: How are the standalone demos useful for AMD?
    • Ben: AMD sees requests for OpenAMP & also requests for a lighter weight solution, which is standalone libmetal
    • Tanmay: We are doing b/c we have use case w/ libmetal used standalone w/ Linux and other RTOSes.
  • Andrew: Should example of standalone libmetal go in system reference?
    • Tanmay: Yes, do want to move it there. Learned when moving from open-amp to system-reference, it's hard to upstream other features & lose commit history b/c different directory structure. Would like to modify the existing demos where they live & then move everything over at some fixed point.
    • Andrew: To have downstream consistency? Assume the downstream is public if user wanted to get the history.
    • Arnaud: Could you have model where everything specific to platform his hosted by vendor & in system-reference we have West .yml that points to vendor repo for platform-specific stuff. Then we could expose each platform implementation & system-reference is the entry point. Each vendor supports its own.
    • Andrew: libmetal becomes pure interface & each vendor has its own downstream? Could work.
    • Bill: Zephyr & FreeRTOS have enough abstraction to make portable. Bare metal is problem.
    • Arnaud: FreeRTOS is still problematic b/c have to set up mailbox
    • Tanmay: Have been able to remove xilinx dirs, would like to maintain some downstream repo in BSPs that implement libmetal interfaces. Will be pushing patches. Maybe there is a way that we can develop demos that will operate only on libmetal devices or open-amp devices & each BSP will overwrite the device ops based on their needs. Libmetal doesn't currently have device ops, but could do.
  • Andrew: Libmetal is that abstraction interface & common API. We can't go the other way & put TI demos into libmetal. Putting libmetal interface in our BSP works better.
    • Tanmay: How to make sure makes same for all BSPs?
    • Bill: Testing & header files. Header files tells how it should be implemented. Don't need runtime indirection. Maybe some flavors of libmetal need to be defined w/ platform header that tunes the libmetal header (full vs. lightweight version). Issue is we only have 1 vendor's example. Would be great to have TI & AMD examples, then we can see what's common & what's different.
    • Andrew: We have & tried posting a hint of it a couple years back. The interfaces were fine, didn't need specialty platform stuff, but had to re-do under the hood. We kept the headers & under the hood got changed.
    • Bill: Libmetal for Zephyr is fairly common & provides value
    • Andrew: Yes, it's what we're using
    • Bill: FreeRTOS - depends how much of the ecosystem you pull in
    • Ben: For baremetal, we have xlnx in core in library. So would have xlnx & ti subdirectories?
    • Bill: Xilinx directory in libmetal should disappear. Should be in vendor dir or system reference. Could write the demos in a portable fashion where they sit in system reference & show libmetal & rely on vendor-supplied BSP for the low-level hooks. 3 pieces: library, portable demos, vendor implementation.
    • Tanmay: For now, will maintain xilinx dir as part of Xilinx BSP, but if we move to system-reference, it's not a hard task. Will send a PR to remove xilinx directory. Need to make sure infrastructure to build the demos is available in the Xilinx BSP first to remove from libmetal.
    • Bill: Can we do it first?
    • Arnaud: Adding vendor lower layer can be difficult even if in system-reference. We could have several thousand lines of code that are just for the porting layer for each platform.
    • Bill: Tanmay has in Xilinx BSP
    • Arnaud: Will be good to see it in PR before taking decision
    • Bill: If you can write a demo that shows libmetal & exercises the API in a particular way without being super-vendor-specific - would be interesting to have in openamp-system-reference.
    • Arnaud: Ben's work on OpenAMP FreeRTOS demo is going this direction. PR #76: See last 3 commits
      • Generic subfolder
      • Machine subfolder
    • Arnaud: Baremetal & FreeRTOS have some task defined. We try to have demo as platform agnostic & vendor specific.
    • Ben: So machine/synqmp_r5 -> TI could have machine similarly
    • Andrew: The last few things would be good candidates to go into libmetal & abstract away those last bits like IRQ init
    • Ben: Don't disagree. Libmetal has certain type of init. It's OK if you only have set of global interrupts, but GIC mapping interrupts to CPUs doesn't quite fit.
    • Andrew: So, extend it. If we need more in libmetal, let's add it.
  • Documentation
  • Anything outstanding for 2025.04 besides docs release?
    • System reference builds
    • Demo builds
    • Container update
    • Bill will try to make update
  • Tanmay submitted DT work for 6.12 new bindings
    • Bill will take a look
  • #46 has 2 reviews, good enough to merge -> Arnaud can merge when he gets back
  • Dan
    • Can use improved driver support to run Edgar's demo
    • Need to get rid of proxy
    • Bill was saying would replace one of the instances of Linux w/ Zephyr
    • If Dan's stuff works, can re-use in Bill's demo
    • Dan will add tasks to the task tracking sheet
  • Iulia
    • Zephyr has 2024.10 open-amp. Should update to latest release. June the next release cycle starts b/c testing
      • Andrew: Agree
      • Bill: Makes sense. They usually get updated in Zephyr after our release, so they're due.
    • Iulia will ask Arnaud on Discord & can do the update to have Zephyr use 2025.04 open-amp
    • Bill: Zephyr changes open-amp, they don't take as-is
      • Iulia: Yes, have to be careful not to miss some file
  • Tanmay will open PR in system-reference and Ben will send new libmetal demo
  • Nathalie: Help Iulia get access to task tracking sheet

2025-05-14

Cancelled due to Linaro Connect that week

2025-04-30

Attended

  • Tanmay, Iulia, Dan, Bill, Nathalie, Arnaud

Agenda

Decisions/conclusions

  • You can see the doc generation in the GitHub action of the PR
  • Arnaud plans to release the libraries & system reference on Mon/Tue next week, if no blocking issues
  • Labour Day in Europe tomorrow -> Bill will cancel RP call tomorrow
  • 8 May is a holiday in France
  • Cancel the call in 2 weeks

Actions

Notes

  • Arnaud plans to release the libraries & system reference on Mon/Tue next week, if no blocking issues
    • If any blocking issues, email Arnaud to ST or gmail address
  • Non regression tests tracking sheet
    • Tanmay plans to update the sheet by tomorrow for the Xilinx & Zephyr. Build is passing. 6.12 upstream only kernel and system reference. Also testing Rob's latest patches (memory regions).
    • Mathieu asked for feedback on Rob's patch, so Tanmay can Ack after testing
    • Iulia ran the RPMSG multi service test demo on 8M+ with 4.1 Zephyr and all updates and 6.12 NXP Linux. Made some changes in DTS, so would use 6.14 kernel. From OpenAMP perspective, it's all good.
    • Bill won't get a chance to do those tests. Were nice to haves
  • Arnaud reviewed Andrew's PR for Zephyr and it is not blocking for the release
  • https://github.com/OpenAMP/openamp-system-reference/pull/64
    • Ben is not working on it right now. Either Ben or Tanmay will address in next release
  • https://github.com/OpenAMP/openamp-docs/pull/46
    • Only last 2 commits need to be reviewed b/c rest are from rebase
    • Arnaud would like to see that we don't duplicate info between OpenAMP website and the docs page and the repo
    • Nathalie to file a GitHub issue to flesh out the system-reference README to include contribution guidelines
  • https://github.com/OpenAMP/openamp-docs/pull/49
    • Andrew answered in the PR, so we can merge it
    • Arnaud will merge it in main
  • https://github.com/OpenAMP/openamp-docs/pull/54
    • Targeting the release
    • Docker image page isn't getting properly generated. This fixes that.
      • Bill will review the Docker page
    • All the other pages appear to generate the same
  • https://github.com/OpenAMP/openamp-docs/pull/56
    • Needs a second review
    • Tanmay will review
  • You can see the doc generation in the GitHub action of the PR
  • https://github.com/zephyrproject-rtos/zephyr/pull/89016
    • We have 2 reviews. Arnaud will ping the maintainer next week if he doesn't merge it.
    • IPC, MBOX, OpenAMP: Iulia raised this problem with not getting reviews & slow adoption. Asked if Zephyr guys can add ppl. They indicated that Iulia can add herself as maintainer or collaborator. Iulia can also add Arnaud as collaborator (no time to be maintainer). Will ping Arnaud in Discord.
  • Docs project
    • Breathe for docs generation: After the release
    • Bill probably won't get a chance to look at it until after Connect
    • Arnaud will try to ramp up on Breathe
    • Will we completely restructure to rely on it, or just add a bit of flavor? Bill would like to define a clear goal for what we intend to do with Breathe when we integrate it. Can discuss w/ Sipke.
    • Doxygen is generating the documentation, then Breathe is going to the reference of structure and function.
      • Bill & Arnaud are OK with this level of integration. Probably don't want to restructure.
  • Individual updates
    • Arnaud
      • Waiting for Bjorn & pinging him to review. Will discuss with Mathieu.
      • Bill: Someone from Qualcomm is presenting at Connect about a secure remoteproc. Conflict of interest?
    • Dan
      • Updating virtio support in OpenAMP w/ latest Zephyr & latest OpenAP playing nice together & doing legacy virtio. That's the first step to introduce 1.0+
    • Tanmay
      • Working on testing the release right now
  • Cancel the call in 2 weeks

2025-04-16

Attended

  • Tomas, Tanmay, Dan, Arnaud, Iulia, Nathalie, Bill

Agenda

Decisions/conclusions

  • Need to discuss if should backport any Zephyr patches & update the OpenAMP docs to introduce the board for demos.

Action items

  • (DONE) Bill will make a PR for updating open-amp CI for Zephyr known good version
  • (DONE) Bill to add Beleswar to the openamp-rp call
  • Nathalie: Ask Beleswar for github account
  • Nathalie to start email thread with Andrew & Beleswar about enabling Beagleplay in 2025.04 release & we can discuss having them file the Zephyr bug for back-port
  • (DONE) Arnaud will consolidate into release candidate on Tuesday & will send an email to let people know to start non-regression tests and include a spreadsheet to track

Notes

  • Looks like https://github.com/zephyrproject-rtos/zephyr/pull/85617 got merged. Does it mean TI Beagleplay made it into 2025.04 OpenAMP release?
    • Arnaud: It's merged. This should be enough to enable TI board now as a reference board. But, that version of Zephyr might not be in the OpenAMP release (we are using 4.1). Need to discuss if should backport any Zephyr patches & update the OpenAMP docs to introduce the board for demos.
    • Iulia: If we create a bug w/ tag and backport for 4.1 label, might be able to ask Anas or Carles. Can be considered a bug b/c without it the larger board won't work.
    • Nathalie to start email thread with Andrew & Beleswar about enabling Beagleplay in 2025.04 release & we can discuss having them file the Zephyr bug for back-port
  • PRs
  • Anything else to discuss for OpenAMP docs improvement project?
    • Removing open-amp application: Arnaud will bring up in the openamp-rp call. Ed prefers to wait for after the release & need to decide together.
  • OpenAMP CI
  • Release
    • Deadline is Friday for PRs
    • Arnaud will consolidate into release candidate on Tuesday & will send an email to let people know to start non-regression tests and include a spreadsheet to track
  • Updating GitHub org membership
    • Need to add Iulia to collaborators on open-amp repo (she is in the org)
    • Can maybe move Andrew and Tammy to external collaborators & swap in Iulia and Beleswar
    • Nathalie: Ask Beleswar for github account

2025-04-02

Attended

  • Dan, Iulia, Nathalie, Arnaud, Andrew

Agenda

Decisions/conclusions

  • This release: TI BeaglePlay, Zephyr 4.1
  • After release: Breathe for docs

Actions

Notes

  • Iulia: Will we update in system reference the Zephyr version to 4.1?
    • Bill had tried the newer versions in CI
    • Arnaud suggests to submit PR, which will trigger CI
    • Iulia will push PR
  • Andrew & beagle play
  • Sipke's PRs
    • Stable enough to merge into main branch for the release
    • Arnaud was leaving them open to give more chance for ppl to review & will merge late next week. Deadline to review is Thur of next week
    • Breathe will be addressed after the release
  • Andrew
    • Instead of AI64 R5 will attempt Beagle Play for this release -> added line item
  • Arnaud
    • CI task is done
    • Add task for removing application
  • Dan
    • No updates
  • Iulia
    • Need Arnaud's review on 2 PRs in Zephyr for OpenAMP resource table sample for i.MX8ULP
    • Iulia to share the link in discord

2025-03-19

Attended

  • Arnaud, Iulia, Nathalie, Bill

Agenda

Decisions/conclusions

  • Bill will update the demos for this release
  • Bill will update the kernel to 6.12 (Yocto is using & it's LTS for this year)
  • Let's use newest Zephyr 4.1 for this release, we know it builds OK
  • Let's focus on NXP DSP support for April release, M will come later
  • Would be good to get a global review of the updated documentation. Can target end of May for docs release incorporating Sipke's work since it is more up-to-date.

Action items

  • (DONE) Iulia to ping Arnaud when Zephyr PR is ready to review
  • (DONE) Arnaud will send a PR to remove the applications from open-amp & can either include in this release or add it just after the release.
  • Tanmay to reply on Arnaud's PR if removing the applications from open-amp now will impact the AMD Yocto CI
  • (DONE) Nathalie and Bill to discuss OpenAMP sticker order for spring conferences via email or Discord

Notes

  • NXP board has address translation from driver to device
    • Arnaud had advised not to use reg property
    • Trying to use DMA ranges but it is not in Zephyr
    • Iulia to ping Arnaud when Zephyr PR is ready to review
  • Anything to discuss ahead of 4/18 feature freeze for v2025.04 release?
    • Only remaining OpenAMP & libmetal PRs are in stale state
    • Expect may receive a few PRs prompted by this week's feature freeze email
    • Bill will update the demos for this release
    • Virtio-msg: Not ready yet
    • Virtio-mmio + QEMU demo would be cool to show
      • The pieces we need should be in place
      • Zephyr running on A53 on QEMU using Virtio-mmio
      • Arnaud: Will Dan's work be sufficient, or need doorbell?
        • Bill: We have what we need. Don't need doorbell/mailbox. Can do w/ the way MMIO works & will have IRQ.
      • TBD if will have to build Zephyr from a branch for this demo
    • Bill will update the kernel to 6.12 (Yocto is using & it's LTS for this year)
    • Nov release of Zephyr is LTS, last week was non-LTS release 4.1
  • Migration from openamp applications to system reference
    • Arnaud: Can we update CI to use system reference applications instead of system reference applications?
    • Bill: Yes
    • Arnaud: Would like West mechanism to get system reference applications, build & run some Linux tests.
    • Arnaud will send a PR to remove the applications from open-amp & can either include in this release or add it just after the release.
    • Tanmay to reply on Arnaud's PR if removing the applications from open-amp now will impact the AMD Yocto CI
  • Zephyr on M4
    • NXP has some M4 support (older iMX.8), M7 is supported w/ OpenAMP in Zephyr
    • NXP freedom board ~$80 don't yet have upstream Linux support. Better to support with iMX.8 EVK
    • Iulia to look into adding M4, M7 or M33 support, but probably will not be ready for April release
    • Let's focus on NXP DSP support for April release, M will come later
  • Should we integrate Sipke's latest work into April release?
    • Getting close to merging to next branch
    • Breathe: If we can change build procedure to support, without necessarily having to use it yet. Doing full integration is probably too big of a change for April. Doxy-linking
    • Even if partially finished, these docs are more up-to-date than what we have, so can release with this
    • Would be good to get a global review of the updated documentation. Can target end of May for docs release incorporating Sipke's work since it is more up-to-date.
  • Virtio-msg
    • Has Viresh updated? Not yet
    • Bill trying to get Edgar to update the QEMU side. Suspect Viresh's change will get in ahead of that.
    • This/next week, Bill will be trying out on ST board.
    • Arnaud has updated recently so that West YAML will build the Zephyr part. Linux will require Arnaud's GitHub branch.
  • Arnaud: Discussing w/ Mathieu to get alignment w/ Bjorn. Will continue discussion tomorrow.
  • Iulia working on some Zephyr PRs & will ping Arnaud when ready for review
  • Bill was at Embedded World doing a demo, so no updates
  • Dan email update: reviewed the docs PR

2025-03-05

Attended

  • Bill, Arnaud, Dan, Iulia, Tomas, Nathalie

Agenda

  • Any recent PRs to discuss?
  • https://github.com/OpenAMP/openamp-system-reference/pull/65 Did Arnaud have any questions before he weighs in on the PR?
  • Anything else to discuss for OpenAMP docs improvement project?
  • Discuss Andrew's response on thoughts on getting Beagle Play support into Zephyr -> OpenAMP April release
  • 2025 task tracker / individual updates

Decisions/conclusions

  • Docs: will be easier to review on a clean baseline
  • Andrew's suggestion for TI board support sounds good.

Action items

  • (DONE) Arnaud will merge PR40 to main-next & ask Sipke to rebase 41, so that it is easier to review
  • If Andrew needs help w/ Zephyr reviews, he should ping on the Linaro OpenAMP discord to rally help b/c there are many Zephyr patches going by & ppl may miss Andrew's.

Notes

  • Any PRs to discuss?
    • What is status of doc PR fixes?
      • Waiting for Arnaud to weigh in on System Reference one
      • Bill will update PR65 and close it out
  • Anything related to docs to discuss?
  • Andrew's suggestion sounds reasonable
    • "Plan is to enable OpenAMP support for SK-AM62 in Zephyr. Will also work with BeagleBoard.org folks to get BeaglePlay M4 support into upstream Zephyr. If this happens in time will enable the same, else stick with SK-AM62 for first reference board."
    • If Andrew needs help w/ Zephyr reviews, he should ping on the Linaro OpenAMP discord to rally help b/c there are many Zephyr patches going by & ppl may miss Andrew's.
    • There is an OpenAMP channel on Zephyr chat too. Arnaud & Iulia are following that chat too.
  • Iulia: March 7 will be release 4.1 of Zephyr & merge window will open so will be able to post PRs. Currently, it is in stabilization.
  • Arnaud: No updates
  • Bill: No updates
  • Dan: No updates
  • Iulia: Still in progress.
    • If add 8ULP in Zephyr, could add to system reference
    • Has different values for device & shared memory. Different use case from what we have right now in system reference.
    • Would only work with specific Zephyr version b/c needs address translation driver that Iulia is trying to add to Zephyr
    • Arnaud: When it is upstream, will be able to add to documentation or point to OpenAMP documentation resource table example from Zephyr to show how to set up.
  • Linaro Connect
    • Will have informal virtio sprint the day before Connect
    • If Dan or Arnaud can make it, they are welcome to join. Unfortunately, travel approval would likely be hard for them to get.
  • ELC
    • Bill has submitted virtio-msg presentation for Denver
    • Iulia will be submitting to ELCE CFP for Amsterdam in August, not likely to be able to go to Denver
    • No conference plans for Dan

2025-02-19

Attended

  • Bill, Dan, Tanmay, Iulia, Andrew, Nathalie, Tomas

Agenda

  • Any recent PRs to discuss?
  • Anything to discuss for OpenAMP docs improvement project?
  • Demo testing issues
  • 2025 task tracker / individual updates

Decisions/conclusions

  • Move the doc/readthedocs_conf.py file to /.readthedocs_conf.py (in the root dir and with a leading dot)

Actions

  • (DONE) Andrew: Beagle Play support is not in Zephyr yet, but it could be a quicker path. Have M4 support on AM-62SK, so would just have to send patch to turn on support. Will think it over & get back to us
  • (DONE) Bill will update https://github.com/OpenAMP/openamp-system-reference/pull/65 with the decision

Notes

  • TI board update:
    • AI64, AI-Y are somewhat upstream in Zephyr
    • Don't have a lot of RAM until enable DDR. R5's were expected to run from DDR. So, run out of space
    • AM-64 & AM-62 (Beagle Play) have more RAM can run OpenAMP demos OOB now, using mailbox driver (got merged)
    • Don't have M4's w/ Beagle platforms. The R-cores are light on memory.
    • R5 setup of DDR is a bit hacky. Currently have springboard.
    • Bill: Could we do something on Beagle Play for April release?
    • Andrew: Beagle Play support is not in Zephyr yet, but it could be a quicker path. Have M4 support on AM-62SK, so would just have to send patch to turn on support. Will think it over & get back to us.
  • Docs project
    • Tanmay looking at docs directory in openamp library, can probably move to openamp-docs directory. Will move apps READMEs to openamp-system-reference. Much of the docs are obsolete though. In System DT flow, everything will be Yocto-based. Propose to remove apps part from library & then add the System DT flow READMEs in system-reference with the example code.
    • Bill: Does doc dir need to really exist in system-reference?
    • Tanmay: Not really. Could move general architecture content out of system-reference and into openamp-docs.
    • Bill: If not being used in the Doxygen, then should move to openamp-docs.
    • Tanmay: Will have to take a deeper look at the docs directory usage to confirm. Can remove apps docs from openamp library.
    • Bill will update https://github.com/OpenAMP/openamp-system-reference/pull/65 with the decision
  • Demo testing
    • The issues that Dan found are fixed in main & regression tested. Thanks, Dan!
    • Bill has in a branch: Can now build & run on Arm64 hosts
  • Andrew
    • Waiting on DDR support for R5 now
  • Bill
    • Docker hub should go back to "To Do"
    • HW demo: Ran what Edgar has. Have nto shown it to others yet but it works -> Done
    • Release item -> back to To do
  • Dan
    • Still to do, but closer to starting
  • Iulia
    • 8ULP started getting issues. Working on address translation driver in Zephyr. Waiting for Arnaud's review.
    • Remoteproc is still to do & don't know when will start.
  • Tanmay
    • Demo upstreaming is blocked b/c internal issues in BSP libraries. Ben working on fixing.
    • 5, 14, 23 can move back to "To Do" b/c not able to work on right now

2025-02-05

Attended

  • Tanmay, Tomas, Dan, Nathalie, Arnaud

Agenda

  • PR & issue filed by Iulia
  • GSOC: Do we have bandwidth to support as an org?
  • Documentation improvement project
  • Individual updates

Decisions/conclusions

  • OpenAMP team doesn't have enough bandwidth to support the org admin + mentorship for GSOC

Action items

Notes

  • Tanmay will review Iulia's https://github.com/OpenAMP/libmetal/pull/322
  • All: Please take a look at issue filed by Iulia https://github.com/OpenAMP/libmetal/issues/323
  • GSOC: Do we have bandwidth to support?
    • Nathalie:
      • Aside from having project ideas for proposal, the labour needed to support GSOC as an organization is 2 Organization Administrators + mentors for each of the project ideas
    • Arnaud:
      • Will not have bandwidth for a GSOC student b/c have ST intern to mentor
      • Experience from ST interns: If it's a good student, less than 1 day / week to support intern. If student needs a lot of help, can be big load.
    • Tanmay:
    • Arnaud, Tanmay:
      • Can discuss projects in Oct/Nov to consider for 2026, if team will have bandwidth to mentor
      • There are many items that could be addressed:
        • libmetal in Rust
        • Libmetal lite w/o Linux content for memory managing
        • Virtio demos
    • Tomas:
      • Feasibility hinges on available mentorship bandwidth
    • Dan:
      • Agree w/ prior discussion
  • Documentation
    • Propose to remove the Application Services Sub-Group page in the documentation
      • Tanmay & Dan: Agree. These topics are being handled in System Reference subgroup now.
      • Arnaud will put removal of Application Services Sub-Group page to the list of tasks for Sipke
    • All: Please review Sipke's PRs as they come in
  • Arnaud
    • Demo for Linux-baremetal for virtio-msg.
    • Discussion ongoing for the virtio spec & expect virtio working group to post RFC in mid-Feb. Bertrand has posted for internal review in WG.
  • Dan
    • No update
  • Tanmay
    • Waiting for Ben to update his PR on demos (#26) to address Tanmay's feedback
  • Iulia update by email

2025-01-21

Attended

  • Tanmay, Bill, Dan, Tomas, Andrew, Nathalie, Iulia

Agenda

  • Upcoming conference CFPs:
    • Nice message: 4 different vendors with reference boards for Arm64
      • To get TI as reference board: What is status of Andrew's Zephyr's PRs?
    • Linaro Connect due Feb 13 (too soon for system reference),
      • Registration is now open
    • Open Source Summit CFP is now open. (Embedded Linux Conference & Zephyr tracks)
      • CFP Closes: Monday, February 17 at 12:00 AM MST (UTC-7) / Sunday, February 16 at 11:00 PM PST (UTC -8)
      • IMPORTANT NOTE: The Call for Proposals for ELC & Zephyr will use this form exclusively for both the OSS North America and Europe events. Please indicate which event you would like your submission to be considered for.
  • GSOC 2025 is now posted. https://developers.google.com/open-source/gsoc/resources/
    • Does anyone have bandwidth/plans to mentor any GSOC students?
    • Jan 27-Feb 11: Mentoring organization application window
  • https://github.com/OpenAMP/openamp-docs/issues/38 tag the tasks indicating which ones are blocker and need to be addressed first for next release.
  • Individual updates / 2025 Task tracker

Decisions/conclusions

  • Getting Andrew's patches merged into Zephyr & having TI platform supported via Zephyr might be enough for April release - West manifest.
  • Target TI platform AI64 (more likely) or Beagley AI
  • Let's take the GSOC conversation to Discord to decide if OpenAMP should apply to be a mentoring organization. Deadline to apply as an organization is Feb 11.
  • Suggested docs priorities for April release (without Arnaud's input)
    • Proxy and RPC cleanup
    • Adding new platform support in documentation

Actions

Notes

  • Nice message: 4 different vendors with reference boards for Arm64
    • To get TI as reference board: What is status of Andrew's Zephyr's PRs?
      • Andrew: Have some patches merged. Mailbox support is still missing. Some movement, think it's getting close to be taken. Then can have OpenAMP support in Zephyr repo -> TI platform supported via Zephyr instead of via System Reference project
      • Bill:
        • Getting Andrew's patches merged into Zephyr & having TI platform supported via Zephyr might be enough for April release. Usually, OpenAMP makes a release & Zephyr picks it up a while later. So, TI platform will be using a different library from the other platforms at release time.
        • If you use the West manifest from OpenAMP, it glues the 2 together & that might be all we need
        • Nice to have OpenAMP copy so can innovate without waiting for Zephyr, which can be slow to get accepted. Will matter more with virtio work.
      • Andrew: If you use ivshmem demo, if you pull in Zephyr it would work for free, unless you need an overlay for the board. Would probably need for ivshmem demo. But other demo might be same DT defines as upstream.
      • Target TI platform AI64 (more likely) or Beagley AI
  • GSOC details are finally released
    • Andrew has been a mentor before. Usually go through Beagleboard.org folks & TI selects the project. Depends on the project that student proposes. Choosing the project allows you to manage the workload. Usually weekly or biweekly standup. Reasonable work.
      • Many projects were proposed
      • TI said what could be mentored
      • Then overlap was sent to Google & Google did final filtering
    • Iulia was a mentor via Linux Foundation
      • Google selected LF & projects proposed by LF
      • Last year they selected a lot & year before they selected <50%
      • Google selects # projects (but mentoring organization can have input)
      • Was told it's best if there's multiple mentors for project
    • Who selects the student?
    • Organization application deadline is Feb 11, but the form won't be open until Jan 27
    • https://wiki.linuxfoundation.org/gsoc/google-summer-code-2025
    • https://gsoc.beagleboard.org/
    • Has some info on what the students are to do: https://gsoc.beagleboard.org/guides/contributor.html#gsoc-contributor-guide
    • Let's take the GSOC conversation to Discord to decide if OpenAMP should apply to be a mentoring organization. Deadline to apply as an organization is Feb 11.
  • Docs issue #38: What are priorities for April release?
    • Andrew: Proxy and RPC cleanup would be a priority
    • Tanmay: Adding new platform support in documentation
      • Bill: Would like to see separate issues for those b/c won't be something that Sipke does on his own. Will require contribution from OpenAMP project member.
  • Individual updates
    • Andrew: Still waiting on mailbox piece. Working state, need final review by Zephyr code owner.
    • Bill: no updates. Was helping Cambridge lab to debug production SOM setup on KV260 starter kit & think what they did for thermal solution should be OK.
    • Dan: Added new tasks & they are still to-do
    • Iulia: Opened issue in Zephyr & talked to Arnaud. He proposed to talk to Mathieu on how to fix & will talk at the openamp-rp call.
    • Tanmay: Helping Ben on line 26

2025-01-08

Attended

  • Bill, Tanmay, Arnaud, Iulia, Nathalie, Dan

Agenda

  • Recent previous assigned actions
  • Felipe messaged in Discord: if he can be added to reviewer list for OpenAMP stuff in Zephyr
  • https://github.com/OpenAMP/openamp-docs/pull/37
    • Who else would be good to pull into the docs review?
    • Sipke requested a meeting w/ Bill & Arnaud to discuss outstanding items from Arnaud's review comments as well as any other items or direction.
  • Pending patches in Xilinx OpenAMP that will become a big PR in system reference to modify Xilinx FW code to latest
  • Schedule of next meeting: Nathalie OOO on 22nd - would it work to move from 1/22 to 1/21 or does someone else want to host it?
  • Nothing is posted for GSOC 2025 yet
  • Individual updates / 2025 Task tracker - Please populate with tasks planned for 2025

Decisions/conclusions

  • Iulia and Felipe can submit PRs to be added as collaborators for OpenAMP in Zephyr w/ justification why, Arnaud can approve as support & Zephyr leads will accept the PRs if they agree.
  • Bill will let Sipke know to split up his work into smaller PRs. For PR37, it will probably be easiest to merge it to a branch, so that GitHub Issues can be filed for specific changes.

Action items

  • Iulia to send Zephyr PR to add herself w/ justification of why should be collaborator for OpenAMP in Zephyr & notify Arnaud on Discord to approve it
  • Iulia will create a GitHub issue regarding resource table sample for i.MX8ULP (Libmetal virtual to physical is where NXP sample crashes) & can discuss there
  • (DONE) Dan, Tanmay, Iulia: Review Sipke's doc pull request in the next week or so, and share feedback in the PR or with Bill and Arnaud before the meeting with Sipke https://github.com/OpenAMP/openamp-docs/pull/37
  • Bill will try to take a look at Arnaud's POC (linked in the comments of row 7 in the new Google Sheet) in the next week or so
  • Arnaud to bring this up his POC in virtio-msg meeting w/ Edgar

Notes

  • Recent previous assigned actions
    • Getting Iulia added to the openamp-rp meeting series
      • Bill added Iulia today
    • https://github.com/OpenAMP/openamp-demo/issues/8
      • Lopper demo update is merged. Tanmay to work on the update to the readme & will submit to openamp-docs
  • Zephyr
    • Iulia tested the PR that Arnaud submitted 8M+ and another board
    • Iulia would like to get added as contributor for OpenAMP in Zephyr
      • Carlo C is no longer active
      • Iulia to send Zephyr PR to add herself w/ justification of why should be collaborator for OpenAMP in Zephyr & notify Arnaud on Discord to approve it
      • If Zephyr team agrees, they will merge it
    • Felipe messaged in Discord: if he can be added to collaborator list for OpenAMP stuff in Zephyr
      • Felipe's review helped Arnaud's PR get merged
  • OpenAMP resource table sample
    • i.MX8ULP
      • DSP addresses are remapped for Cortex-A
      • OpenAMP sample works w/ addresses that are same on both on main & secondary core
      • Linux will do the translation: PA2DA translation (PA is physical address from Linux POV & DA is physical address from coprocessor POV)
      • ST has DT node parent w/ bus that declares the DMA range & specify the translation at this level -> Can look at ST driver for Linux
      • Coprocessor will have not map on virtual address, so needs to work with physical address
      • Iulia will create a GitHub issue regarding resource table sample for i.MX8ULP (Libmetal virtual to physical is where NXP sample crashes) & can discuss there
      • Limitation for RPMsg virtio port: no translation for buffer itself. Put address for vring descriptor and there is no translation for this address, so may need something on DSP side.
  • How to split work on reviewing Sipke's docs PR?
    • Bill & Arnaud will probably meet w/ Sipke next week or the week after
    • Any feedback to Arnaud & Bill in the next week or so would be greatly appreciated
      • Can reply in PR or send email
    • Bill likes idea of creating a branch for docs-next where we can start building something up there b/c big PRs are hard to digest. Prefer if Sipke submits multiple PRs for his work. If we accepted this into a branch, then could make PRs for what we want changed
    • Bill: There is a diagram w/ wrong architecture
    • Iulia, Tanmay & Dan will review
  • Pending patches in Xilinx OpenAMP that will become a big PR in system reference to modify Xilinx FW code to latest
    • Were not putting anything into apps directory, and now would like to upstream some patches to system-reference
    • Attach-detach will be possible from baremetal firmware
    • Baremetal demos would be able to work with DT flow
    • 1 big commit & which commits are taken from downstream openamp repo b/c hard to have each change separately. Might be too big, but let's see the PR first.
  • Task tracker / individual updates
    • 2025 task tracker has the remaining 2024 tasks. Please add any new 2025 tasks to the new Google Sheet
    • Arnaud: virtio-msg: first POC is delivered on GitHub at these links. Do Bill or Edgar have time to look?
      • Bill will try to take a look at Arnaud's POC (linked in the comments of row 7 in the new Google Sheet) in the next week or so
      • Arnaud to bring this up his POC in virtio-msg meeting w/ Edgar
      • It's a different queue structure than what Edgar has today. Arnaud has Zephyr on the other side & Edgar has QEMU on the other side.
      • Arnaud: Maybe could propose an API that could also be used by application? Would be good to have some standardization of the system.
      • Bill: Alternative shared memory structure that could complement virtqueue structure
      • Arnaud: That's why put it in separate file to be able to expose it, but only implemented device part. POC - not mature code yet.
    • Bill:
      • Will see what progress can make on OpenAMP release best effort b/c demo upcoming + some OOO time
      • Arnaud already has the libraries tagged & that's most important. For the other stuff, don't want to tag without testing b/c that doesn't add value. Most ppl look at latest docs anyway & not tag.
    • Dan
      • No updates on existing items. Thinking of some new items
      • Bill: Viresh has done rust work & tested with Xen and FFA. Might be adaptable to co-processors. Is Dan a Rust person?
        • Not really.
      • Thinking of RTOS-RTOS scenario w/ running VxWorks on A and R cores on similar setup to ZCU102 Xilinx QEMU setup w. updated virtio-msg implementation (simple shared memory, no Xen stuff), and see how that would work
      • Would like to see rev up of version, TBD if will get time
    • Iulia
      • i.MX8ULP: Linux on the A core
      • Would be nice to have in Zephyr same like how we have Linux & remoteproc to start & stop the core. Want to run application on DSP and start from M core.
      • Bill: Library has that support in it, but doesn't get tested, so having a real use case will be helpful. What we had was probably the Zynq-7000 stuff that is no longer supported.
      • i.MX RT700 was announce by NXP at end of September
        • Will be helpful to start DSP form M33 core
        • If have support in OpenAMP, can try to test it
      • Tanmay: There is load firmware demo that shows how to use library to load firmware on the core.
      • Arnaud: Will need to create a remoteproc framework in Zephyr that relies on OpenAMP that gets the file from file system
      • Added 2 tasks to the tracking sheet
    • Tanmay
      • No change in statuses
      • Won't handle all of these in this release b/c have a lot of work in downstream repos
      • Added a task to the tracking sheet
Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️