Skip to content

OpenAMP System Reference Meeting Notes 2024

Jump to bottom Edit New page
Nathalie Chan King Choy edited this page Jun 12, 2024 · 27 revisions

Table of Contents

2024-06-12

Attended

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

Agenda

  • v6.9 vs. v6.10 kernel for demo images
  • Does ST use Yocto Scarthgap LTS?
  • Task Tracking sheet / individual updates

Decisions/conclusions

  • Use West to make open-amp library sources available to demos for building (including for baremetal)
  • 1st preference for OpenAMP 2024.05 release is to use upstream v6.9 kernel + a few patches. 2nd preference is upstream v6.6 kernel + a few patches. Don't want to ship release on RC kernel. Could release the SD card images & not have Docker until v6.10 is released, but prefer not to do that.

Action items

  • Tanmay will work with Bill to bring up Ethernet on upstream 6.9 kernel (ideal) or 6.6 kernel (fall-back plan). Something in v6.10-rc3 seems to fix it (unclear if intentionally)
  • Tanmay to look into using West to take care of open-amp library sources for application build
  • Tanmay & Bill to notify Dan if will use v6.9 or v6.6 kernel, once they get Ethernet working
  • Arnaud will review the comments in the open-amp doxygen items, circle back w/ Tammy & decide how to move forward on them
  • Andrew will look up TI infrastructure for latency measurement of RPMsg data transfer between 2 cores when Linux + remote running baremetal or RTOS & share with Iulia

Notes

  • v6.9 vs. v6.10 kernel for demo images
    • Bill prefers not to release OpenAMP with an RC kernel
    • Tanmay will work with Bill to bring up Ethernet on 6.9 kernel
  • Does ST use Yocto Scarthgap yet?
    • Staying on older version. Not moving to Scarthgap yet.
  • Task Tracking sheet / individual updates
    • Andrew:
      • No update on tasks. Waiting for Zephyr
      • Got new GSoC intern. Will have them working on Zephyr & may tie back into OpenAMP similar to Kendall - TBD.
    • Arnaud:
      • No update on tasks.
    • Dan:
      • Will have to sync w/ Bill & Tanmay about up-reving kernel for demo. Have been using ancient kernel version. (v6.9 will depend on if we can get Ethernet working)
    • Iulia
      • No update on tasks.
    • Tanmay
      • Started working on moving apps
      • When we move the demos in System Reference, will we only provide OpenAMP build directory? Won't provide lib openamp source directory? How will link openamp library?
        • Arnaud: Should first build the openamp sub project & then link as static or dynamic lib as you need. Should have the makefile that generates the library in system reference.
        • Tanmay: Current openamp lib seems to generate static?
        • Arnaud: Depends on the platform, you can have dynamic if platform supports it. Default is static.
        • Tanmay: Will prebuild openamp lib & provide lib binary path to system ref demos?
        • Arnaud: You can build lib as dynamic or static & link in the application. Already present in makefile for the application. Might have to download sources or update some paths. Have not tried it.
        • Bill: What side are you building? Linux?
        • Tanmay: R5 baremetal
        • Bill: For baremetal it would be a static lib
        • Bill: Xilinx does it w/ Yocto?
        • Tanmay: Patching the BSP library binaries & linking them.
        • Bill: Building BSP lib as binary & bringing over? That can work. You can build libs for that environment & then build the applications using those libraries.
        • Nathalie: What about Tanmay's question regarding providing the sources or instructions on downloading & specifying path?
        • Arnaud: Build method could also fetch the sources, or could have in README that you have to start build of openamp library &
        • Bill: West manifest will clone everything for you. Even w/ baremetal, can still use West to initialize everything & sets up a known directory structure. Lets us control the version in 1 place.
        • Arnaud: Good idea.
        • Tanmay to look into using West to take care of open-amp library sources for application build
    • Bill:
      • Working on the 2024.05 release. Upstream kernel on Xilinx QEMU is the rough spot.
      • Trying to find a released kernel that will work with QEMU.
      • Tanmay: Can boot?
      • Bill: Yes, can boot, but the demos need Ethernet. Ethernet works in U-Boot (can TFTP boot). It's trying to use the 1588 precision time stamp, but that doesn't work on QEMU (works on HW). In Xilinx version of kernel, something makes it work.
      • Tanmay: You mean 6.6?
      • Bill: Xilinx 6.6 works but not upstream 6.6 with same config. There's 994 Xilinx patches on top of v6.6.
      • Tanmay: Will give it a shot with 6.9 and see what's the difference & ask some internal folks about Ethernet.
      • Bill: Something queued for 6.10 seems to fix it, so it must be relatively recent (whether intentional or not). Didn't see any intentional fixes in 6.10 commits.
      • Tanmay: If can fix 6.9 w/ some patches is first preference for 2024.05?
      • Bill: Yes, 1st preference for OpenAMP 2024.05 release is to use upstream v6.9 kernel + a few patches. 2nd preference is upstream v6.6 kernel + a few patches. Don't want to ship release on RC kernel. Could release the SD card images & not have Docker until v6.10 is released, but prefer not to do that.
    • Bill:
      • Tasks 19, 28, 29 are priorities for next couple weeks
    • Tammy:
      • No updates
      • Arnaud: Have a few doxygen issues on GitHub in open-amp
      • Tammy:
        • Went through the tickets & commented on them b/c needed review for current release.
        • If the issues are not relevant or important to the community, then can close. Siemens isn't working on OpenAMP too much.
        • Tammy can work on some OpenAMP docs items in near term, but not likely to have bandwidth to work on code & do all the setup for testing.
      • Arnaud will review the comments in the open-amp doxygen items, circle back w/ Tammy & decide how to move forward on them
  • Tanmay: Docker setup is a good setup. Good idea to use it for Zephyr development? Tried & ran out of space.
    • Bill: Demo lite was to just run the things. Full demo was to be able to rebuild things. We could make improvements to make it better as a developer tool. Not sure why you'd run out of space b/c Docker usually expands as you use it, so you might be running out of space on root partition.
    • Tanmay: Was on native machine
    • Bill: All in /var, so need a lot of space wherever /var is mounted.
  • Iulia
    • NXP trying to do latency measurements between 2 cores. Has anyone done it for RPMsg data transfer between 2 cores?
    • Arnaud: Long time ago, Kumar Gala had done w/ Zephyr on both cores. Have not seen any measurements in recent years.
    • Bill: Interested in Linux to remote core?
    • Iulia: Linux to start the 2nd core, which will probably run Zephyr Firmware
    • Andrew: Have for TI mainly to profile the Linux side. Can use w/ baremetal or RTOS.
    • Andrew will look up TI infrastructure for latency measurement of RPMsg data transfer between 2 cores when Linux + remote running baremetal or RTOS & share with Iulia

2024-05-29

Attended

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

Agenda

Decisions/conclusions

  • Trying for Yocto LTS 5.0 Scarthgap makes sense

Actions

  • (DONE) Arnaud will check if Yocto Scarthgap is compatible for ST build

Notes

  • Non-regression tests
    • Tanmay:
      • Don't have setup for FreeRTOS right now. Also relies on some Xilinx-specific stuff. So, skipping.
      • System reference testing on QEMU & not KV260. Think should be OK b/c kernel space is already passing.
    • Arnaud:
      • Did not succeed to build the library w/ armcc. Have issue w/ armcc license
    • Bill:
      • These are not going to happen before end of may. Targeting mid-late June.
    • Follow up w/ Ed on his non-regression test.
    • Arnaud:
      • Remoteproc test: Have no platform to test
        • Bill: ST H7?
        • A: No, have to regularly flash both FW so don't need remoteproc
        • Bill: Don't need, but could still test?
        • A: Where to load & run it, not sure would have enough RAM to load & run.
        • Bill: Better to do on a QEMU-supported board
  • Pull requests
    • Arnaud will merge the release PRs just before the release to update the version of the libs. Ed or Tanmay already approved.
    • PR43 Tanmay built but hit some issues for QEMU. WIP
    • PR43 Iuliana tested on NXP board w/ latest main branch Zephyr (3.6.x) & Arnaud on ST board w/ 3.6
  • Individual updates
    • Andrew: Waiting to get things merged
      • Tanmay: For R5 support on Zephyr is it supported for both lockstep & split?
      • Andrew: Will be for both. Currently upstreaming split, but shouldn't look different from SW perspective.
      • Tanmay: Split: Are you adding 2 diff machine support for the cores?
      • Andrew: Will in future patch, once we have DDR support they will need different addresses & will require another machine config.
      • Tanmay: 3rd machine for lockstep?
      • Andrew: Gets same memory address as 1st machine. Core 0 has same memory address in split and lockstep.
      • Bill: How do the interrupt controllers work in lockstep? Use just 1 or also in lockstep?
      • Andrew: Not sure, would have to check.
      • Bill: You have 2 instances of interrupt controller?
      • Andrew: Think should be. Configure for peripherals on that core.
    • Arnaud: No update
    • Bill: No update
    • Iulia: Started looking at it, but no progress so far. Let's keep in to do.
    • Tanmay: No updates. This week was mostly on reviews & testing of libs for release.
  • Arnaud: Saw we have new Yocto LTS. Too late to migrate for this release?
    • Bill: Plan to update to the LTS 5.0 (Scarthgap). Have some work to do there b/c generic arm64 has gotten upstream in poky so will have to drop the meta-arm layer. Hopefully should be transparent.
    • Arnaud will check if Yocto Scarthgap is compatible for ST build

2024-05-15

Attended

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

Agenda

  • Welcome NXP to System Reference working group
  • 2024.05 release
  • Task Tracking sheet / individual updates
  • Virtio to discuss w/ Dan (too late to integrate into current release) - OK to push to next week or week after

Action items

  • (DONE) Bill will look into adding Iulia to the openamp-dev discord channel
  • (PR43 approved by Tanmay) Arnaud to update system reference to point to latest release openamp & libmetal
  • Bill & Arnaud to discuss if can get by without Arnaud's 1 patch or if need to import it.
  • (DONE) Tammy to help review PRs around doxygen update by Friday? 1 in openamp-library & 1 in libmetal.
  • (DONE) Iulia to try testing frozen branches on NXP
  • Andrew to test frozen branches on TI, especially Zephyr stuff
  • (DONE) Arnaud will ping Carlo Caione (co-maintainer of Openamp in Zephyr) if no movement on Andrew's patch by end of week
    • PR merged in Zephyr

Decisions/conclusions

  • Will release system reference & docs 1-2 weeks later than openamp & libmetal
  • Freeze openamp & libmetal end of this week (this establishes that it's 2024.05)
  • 2 weeks of non-regression testing following freeze

Notes

  • What is system reference?
    • Have some demos that run on Xilinx platform & ST platform & QEMU
    • 2 repos in OpenAMP project
      • openamp-docs on how to enable demos on specific platforms
      • openamp-system-reference w/ code that can be run on several platforms
  • Is it possible to have NXP platform to run this reference code on it?
    • Iulia: Might be iMX8 M+
    • Arnaud: NXP already run Zephyr stable & same for Andrew/TI. Multi-services reference sample for Zephyr that runs w/ generic Linux & comm through RPMsg tty & char. Could also have console on top of RPMsg for Zephyr.
    • You can try demos on platform
  • Who can participate in non-regression tests for OpenAMP once we freeze openamp & libmetal release branch on your platform?
    • Code freeze should be at end of this week, but waiting on review to merge last PR
    • That gives 2 weeks for non-regression tests
    • Most of the changes in this release are in libmetal & not much in System reference
  • Arnaud to update System reference to point to latest release openamp & libmetal
    • Libmetal & openamp main should work for testing
  • Bill: Iulia could use system reference to initialize the workspace, but not have to use the system reference example
  • Iulia: see Zephyr 3.5 - but they are on 3.6, and close to 3.7
    • Dan's patch from virtio-exp branch has been merged main branch. His patch is needed to sync w/ latest Zephyr. Fix is in openamp-zephyr-modules main, so ideally you should be able to update main in zephyr-openamp-staging
    • Arnaud: Should we stay on 3.5 or migrate to 3.6 for this release? Would be nice to point to 3.6 Zephyr, but same question for Linux. Would impact Bill for CI.
    • Bill: Would need to look at Zephyr more. Planning to build latest Yocto 5.0 for meta-openamp. So reference images would be based on latest (6.6 kernel).
  • Freezing the release
    • First stage would be freezing libmetal & openamp libraries, then freeze system reference, then update CI build & then freeze demo images.
    • We can release system reference & docs 1-2 weeks later, if needed, similar to last time. Let's do that.
  • Bill & Arnaud to discuss if can get by without Arnaud's 1 patch or if need to import it.
    • Bill: For a couple releases, we've been integrating a kernel patch into kernel build so that the system reference sample as-is works 100%. We can do that again, or find a way to simplify the sample so it's not needed.
    • Arnaud: Like keeping this patch on top of kernel b/c allows to create endpoint from Linux. Patch is not upstreamable today. Also OK to remove it from the sample, but it means that we have to clean up the associated readme.
    • Nathalie: Bandwidth?
    • Bill: Don't have bandwidth until May 27, but could do it if release docs & meta openamp a bit later
  • Release name 2024.05
    • Based on code freeze date for the libraries not release date
  • Tanmay test coverage
    • Have to verify some of the Xilinx specific stuff (rpmsg in userspace & echo test demo) along w/ Zephyr
    • Developing CI to help do this faster w/ onboard script for QEMU to help test the demos
    • Planning to cover all the testing in automated way & next release can focus on other testing
    • Tanmay will also review patches that Arnaud sent. Have looked at Andrew's & some are still outstanding a 2nd approval. Target end of week.
  • Can Tammy help review PR around doxygen update by Friday? 1 in openamp-library & 1 in libmetal.
  • Andrew will take whatever we have in Zephyr & make sure that works. Can pull the frozen libmetal & openamp & test that.
    • Arnaud: Think system reference should work on TI, then if it does we can add that to the documentation.
  • Arnaud will ping Carlo Caione (co-maintainer of Openamp in Zephyr) if no movement on Andrew's patch by end of week
  • Tanmay working on testing latest openamp & libmetal

2024-05-01

Attended

  • Tanmay, Andrew, Bill, Tomas, Nathalie

Agenda

  • Any takeaways from EOSS that are applicable to OpenAMP System Reference?
  • May 15 is during Linaro Connect: keep the call?
  • Task Tracking sheet /individual updates
  • Docs committee: Please stay on the line to discuss procedure for working with contractor

Decisions/conclusions

  • If any example only works w/ vendor kernel, then that should be clearly stated in the README.
  • AMD Xilinx management can support with resource the activity of moving demos to OpenAMP system reference
  • OK to keep cmake infrastructure from openamp apps repo when moving to system reference if it's not orders of magnitude more complex. If so, then should discuss.
  • OK to move tests in openamp apps directory to system reference, TI will add others to openamp for their work

Action items

  • All: Help review AI64 initial patches to Zephyr from Andrew
  • (DONE) Nathalie to check w/ Arnaud, Dan & Tammy. Keep if >3 ppl can join. Andrew & Tanmay could join.
  • Tanmay to update readme for Xilinx user space demos that rely on Xilinx kernel & not expected to work with upstream kernel.

Notes

  • Any takeaways from EOSS that are applicable to OpenAMP System Reference?
    • Good showing & interest in the project
    • No change in direction for us
    • Would be good if we could continue conversation w/ NXP about a system reference platform
  • May 15 is during Linaro Connect: keep the call?
    • Nathalie to check w/ Arnaud, Dan & Tammy. Keep if >3 ppl can join. Andrew & Tanmay could join.
  • Individual updates:
    • Andrew:
      • Initial patches for AI64 are set to Zephyr. Would appreciate reviews from these folks.
      • OpenAMP examples need updates to R5 layer to assign more memory for them to work. Andrew tried on desk & seems to work.
      • May need help from OpenAMP folks later on C6 & C7 DSP support, less straightforward than Arm core.
    • Bill:
      • No new updates. Expect some movement over the next month.
    • Tanmay:
      • Talked to management about moving demos to OpenAMP system reference. They are ready to provide resource to work on it. Will expect a few things:
        • Cmake infrastructure in apps directory: if stays intact, will be easier to handle the demos
      • Once moved to OpenAMP system reference, think no blockers to upstreaming & Xilinx-specific demos
        • Bill: Anything Xilinx-specific of similar complexity that it used to be, it's OK.
      • Any new demos introduced would not likely be platform-specific. Just don't want to stop development on existing demos.
      • In future can work on platform-agnostic demos & deprecate the platform-specific ones they replace.
      • Tests are under apps directory. Will move whole apps directory as-is.
        • Andrew: That's fine. We can add new tests.
      • Working on making Xilinx driver complete in kernel. Have upstreamed a few more remoteproc driver features. Added TCM & few more platform support (Versal, Versal net). Working on attached, detached.
    • Bill: When doing the examples, if they only work w/ the Xilinx kernel, that should be clearly stated in the README.
      • Tanmay: We don't expect demos would only work w/ Xilinx kernel. Whatever I'm developing upstream for ZynqMP onward, making sure it works w/ upstream kernel.
      • Bill: Do any legacy demos rely on Xilinx kernel?
      • Tanmay: Maybe user space demos b/c bindings not in upstream kernel.
      • Tanmay to update readme for Xilinx user space demos that rely on Xilinx kernel & not expected to work with upstream kernel.

2024-04-17

Attended

  • Arnaud, Dan, Tanmay, Andrew, Tammy, Nathalie

Agenda

  • OpenAMP application migration to System Reference
  • Task Tracking sheet /individual updates

Decisions/conclusions

  • We had said we'd freeze demos for now. Don’t want to introduce new demos yet, but can improve existing.
  • Suggest that 1st step is to get platform-specific demos into system reference instead of living in openamp. Then 2nd step would be to satisfy Bill's ask & make them generic
    • Need ACK from Bill before we proceed

Action items

  • (DONE) Bill: Please comment on if OK for Tanmay to take 1st step to help unblock Andrew
  • (DONE) Tanmay will propose to downstream management b/c will need support for Yocto recipe.
  • Arnaud & Tanmay: Put in May release notes to warn that we plan to make application migration change in October release

Notes

  • OpenAMP application migration to System Reference
    • Context
      • Today we have pull request on openamp from Andrew
      • Evolution on applications on the tests in OpenAMP?
      • Andrew proposed improvements. How to move fwd if we accept Andrew's PR?
    • We had said we'd freeze demos for now. Don’t want to introduce new demos yet, but can improve existing.
      • Andrew's PRs are fixing existing demos & not creating new ones
    • Tanmay has dependency on internal teams. Need Yocto-based recipes. Would have to get management buy-in. Not sure how long it will take to do that. Could start w/ basic interfaces & RPMsg part & start from there.
      • Arnaud: RPMsg echo & ping example could be good start
      • Tanmay: Current demos highly coupled w/ Xilinx driver. Want to rewrite platform info part to make it platform agnostic.
      • Andrew proposed a way to make it platform agnostic
      • Many demos don't work for TI b/c specific to certain platforms
    • What interfaces is Tanmay missing? Not provided by libmetal? Why does moving repos create churn?
      • ZynqMP A53 remoteproc driver implements Xilinx-specific remoteproc stuff
      • Moving the demo wouldn't make much difference & still wouldn't work for another platform
      • So, if we want to have a generic demo that other platforms could implement interfaces
      • Expectation is that each platform would have to add platform specific defines in cmake
    • Andrew doesn't care if system reference demos are platform specific. Does care if platform specific demos are in openamp.
      • Suggest that 1st step is to get platform-specific demos into system reference instead of living in openamp. Then 2nd step would be to satisfy Bill's ask & make them generic
      • Tanmay OK to copy the code from 1 repo to another. There is a PR proposed by Sergei that did something like that. Can switch downstream yocto recipes to openamp system reference & test the demos, then can remove the apps dir from openamp lib.
        • The CI will also need some update
        • Need ACK from Bill before we proceed
      • The other way to do it was to implement something generic in system reference & then remove from openamp
      • Can move to legacy directory so ppl know these are not the recommended demos to start with
    • Arnaud: Think this is probably the best way to start moving forward. Start w/ openamp b/c easier to move, then libmetal in 2nd step.
    • Tanmay will propose to downstream management b/c will need support for Yocto recipe. Then can start create yocto recipe.
    • If we move the demos, do we need to notify community that this is the plan & get rid of apps dir from openamp?
      • Arnaud: We can put in release notes for next release that will move in Oct release & then keep in original dir for 1 release, so that ppl have warning. Also gives us time to move CI & adapt.
  • Individual updates & tracking sheet
    • Andrew: It's still in progress, moving along slowly.
    • Arnaud: Will work on item 6 this week
    • Dan: Marked items as done & Arnaud needs to review a PR & prob merge tmrw.
    • Tanmay: RPMsg support on U-Boot has dropped in priority. Have to focus on kernel TCM bindings. V1 patch was sent & need to refactor based on latest kernel bindings that were approved. Added a task for moving from openamp to system reference 1st step.

2024-04-03

Attended

  • Arnaud, Bill, Tomas, Dan, Tammy, Nathalie

Agenda

Decisions/conclusions

  • Nothing planned for OpenAMP for ELC at OSS Europe CFP

Action items

  • Dan will provide commit on Discord to Arnaud for creating virtio branch

Notes

  • EOSS & next week’s System Reference: Keep or cancel?
    • Next time, or RP meeting or in PR: OpenAMP application migration to System Reference (Tanmay, Andrew)
    • May need to speed up moving applications to System reference b/c dep for Andrew, hence need Tanmay
    • Check Tanmay’s availability. TBD, figure out when Bill’s talk is.
  • Nathalie emailed Iuliana to see if she wants to participate on behalf of NXP, no reply.
  • Arnaud: No progress. Focused on OpenAMP backlog
  • Bill: The In progress items are still in progress & return one to TODO
  • Dan:
    • Still in progress.
    • Migrated everything on top of latest Zephyr & it's been a pain. Dependency for creating the PRs.
    • Zephyr tweaked some stuff in OpenAMP, so need PRs for that
    • Now it works as before.
  • Arnaud is creating the virtio branch. Dan will provide the commit on Discord.
  • Tammy: on docs PRs stale
    • These things are still relevant, open & valid
    • Tammy updated the data structure consistency & readability one
    • Keeping open until someone can document them or decide which one don't need to be documented
    • Arnaud: Andrew proposed to put some of these structures internal to openamp ,s o maybe don't need to document some
  • ELC at OSS Europe - Sept 16-18
    • Dan not considering topic for CFP
    • Tomas considering attending, but no plan for talk submission

2024-03-20

Attended

  • Tammy, Andrew, Arnaud, Nathalie, Bill

Agenda

Decisions/conclusions

  • Probably need to delay 2024.04 OpenAMP release

Action items

  • Bill will add Andrew to the openamp-rp series
  • (OBSOLETE) Bill will email Stefano & Michal O. to see if they want to submit a talk related to Xen real-time performance & Zephyr
  • (DONE) Arnaud will propose to the mailing list that we delay this release to May

Notes

  • TI: GSOC https://gsoc.beagleboard.org/
    • If anything OpenAMP related, Andrew will probably get pulled in to mentor
    • Beagle Play as system reference would be trying to get remote processors working
  • Any preparation required ahead of Linaro Connect? 25 March 2024 is the CFP deadline
    • Bill is talking about Virtio at EOSS NA in April, so doesn't make sense to repeat it for Linaro Connect
      • Connect would be a different audience w/ more Europe folks, but EOSS will have a recording
    • Bill thinking about proposal for showing Zephyr maintaining real-time performance under Xen
      • Enabled by Stefano & Michal O. from AMD
      • Bill will email Stefano & Michal O. to see if they want to submit a talk related to Xen real-time performance & Zephyr
      • In future, this project will have an OpenAMP aspect to it, but not yet. Eventually this will intersect Bill's Virtio EOSS talk material.
  • Who's planning to go to Linaro Connect?
    • Linaro: Bill
    • AMD: Tomas, Nathalie, maybe Wes if his talk proposal gets accepted, possibly Michal S.
    • Siemens: No one
    • ST: No one
    • TI: A few folks will submit to the Connect CFP (Don H & Andreas D), so if their proposals get accepted. Nishanth will be busy with the EOSS talks in April, so not likely.
  • There will be another ELC track at the fall 2024 Sept 16-18 where ppl might convene on these topics
  • Discuss w/ Tammy the docs ones in this list: https://github.com/OpenAMP/open-amp/issues?q=is%3Aopen+is%3Aissue+label%3AStale
    • Defer to next call
  • Task Tracking sheet / individual updates
    • Arnaud:
      • No progress.
      • Have big milestone in April that will take near 100% time & Tanmay will also be less available in April. Will make it hard to review Andrew's patches quickly. Bill will be busy with EOSS & Connect in the next few weeks. Should we delay release to mid-May?
        • Bill: Sounds like it will be better to delay the release to May.
      • Arnaud will propose to the mailing list that we delay this release to May
    • Bill: Some of these tasks will close out when Dan finishes his rebasing work. Build Zephyr for QEMU virtio native mode
    • Andrew:
      • A lot of the recent patches I've been pushing are involved in this. It does work but have to deal with some bugs.
      • Have sent batch of patches -> Arnaud: these will help make library better
    • Dan: Have functional code for the 4 in progress items. Need to discuss the branching in next week's Virtio meeting.

2024-03-06

Attended

  • Tomas, Dan, Bill, Arnaud, Tammy?

Notes

  • Nishanth: GSOC https://gsoc.beagleboard.org/
    • Skipped due to no TI representation
  • Any preparation required ahead of Linaro Connect? 25 March 2024 is the CFP deadline
    • Not anything immediate. Circle back next time.
  • Discuss w/ Tammy the docs ones in this list:
https://github.com/OpenAMP/open-amp/issues?q=is%3Aopen+is%3Aissue+label%3AStale
    • Tammy will take a look until next time
  • Task Tracking sheet
    • Skipped this
  • Individual updates
    • Bill, Dan, Arnaud discussed VirtIO
    • Tomas shared that Edgar is back. Tomas to connect him with the VirtIO team.
  • Sticker discussion
    • Keep color scheme of the right draft.
    • Add openampproject.org in the other white circle area
    • Start discussion on how the whole package will look like, outside of the removable sticker
      • QR code?
      • Full OpenAMP logo?

2024-02-21

Attended

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

Agenda

Decisions/conclusions

  • Let's discuss next time with Tammy the docs ones in this list:
https://github.com/OpenAMP/open-amp/issues?q=is%3Aopen+is%3Aissue+label%3AStale
  • Propose to Umair (he appears to be from Siemens) to put his project in System Reference

Actions

  • (DONE) Nathalie: Create a task as an issue in system reference repo for Zephyr shell over RPMsg proposal
  • (DONE) Arnaud to look at https://github.com/OpenAMP/libmetal/pull/184 and see if it can be closed
  • (DONE) Arnaud to look at https://github.com/OpenAMP/open-amp/issues/172 to see if it is still relevant (from 2019) and close it
  • (DONE) Arnaud will email UmairKhanUET about OpenAMP PRs #553 & #556 for testcases that we can run in CI & adding to System Reference.

Notes

  • An issue/PR is marked stale after 60 days
  • https://github.com/OpenAMP/libmetal/issues/246
    • This is still a pending item for Xilinx - some legacy stuff to deal with, long tail
    • If we have new stuff that isn't a full BSP, can have other platforms
  • Xiaoxiang's PRs to OpenAMP are for NuttX. Need to address some issues on Linux mailing list for things that matter to both Linux & NuttX -> Arnaud prefers to keep these open
    • 246
    • 238
  • UmairKhanUET #553 & #556: Not able to test w/ ST & Xilinx
    • Think Ben tested it many years back with just baremetal FW, but have not seen this use case recently
    • Small processor is loading FW onto big processor. Not sure if someone has tried to load Linux.
    • We don't have it in our regressions anymore
    • Should develop testcase, but will take great amt of effort
    • Maybe can propose to Umair (he appears to be from Siemens) to put his project in System Reference
    • Tanmay thinks test should be simple to integrate into the Docker QEMU
    • Was this from the Zynq-7000 days w/ 2 A9's where one A9 is loading the other A9
  • Does anyone know how to reach Iuliana?
    • Arnaud: Maybe can look on Linux mailing list
  • https://discord.com/channels/881957442341208095/1097513779157282916/1205191236802183248
  • Individual updates
    • Bill: Working on non-System Reference stuff right now. Zephyr in Xen in various flavours. Trying to re-verify some of the demos that Felipe had reported were working. 2 Zephyr DomUs on Xen communicating over virtio.
    • Andrew: Trying to get resources together for next time
      • Bill: TI reference platform in April or October?
      • Andrew: October would be safer
    • Tanmay: Stabilizing the TCM bindings in kernel driver, getting close. After that, can take up one of the 2 todo items

2024-02-07

Attended

  • Tammy Leino, Arnaud Pouliquen, Tomas Evensen, Andrew Davis, Dan Milea, Nathalie Chan King Choy

Agenda

  • Review GitHub issues queues
  • Arnaud: Maybe good time to reach out to NXP for System Reference participation
  • All: 2024 task tracking/individual updates

Decisions/conclusions

  • Let's wait until we have Bill & Tanmay to review the issue queues

Actions

  • (DONE) Nathalie to follow up on NXP System Reference platform thread when Bill is back & figure out how to loop in Iuliana
  • (DONE) Nathalie to share DTB discussion thread from Arnaud to Stefano & Bruce

Notes

  • Arnaud: NXP participating in Zephyr based on RPMsg. Might be relevant to showing demos for OpenAMP. Some Qs on Discord.
  • Arnaud updates:
    • Remoteproc OP-TEE discussion ongoing w/ Mathieu on Linux mailing list
  • Dan updates:
    • Have to sync w/ Felipe b/c some overlap w/ his commits to OpenAMP. Mostly covered during the Virtio sync in the alternate slot to this call.
  • Andrew updates:
    • No updates on the items in the tracking sheet. Put on pause.
    • Got some resourcing now to start looking at these again.
    • 1st task would be the libmetal OpenAMP example on Beagle platform. Depends on system reference refactor.
  • Tammy: No update
  • Tomas: No update
  • Arnaud: Discussion on Linux remoteproc mailing list
    • Kalray use case w/ co-processor firmware w/ DTB. They ask how they can provide remoteproc firmware + DTB file. This may be interesting to AMD & System DT.
    • Tomas: Is Stefano involved in that discussion?
    • Arnaud: Don't know if Stefano is following remoteproc mailing list.

2024-01-24

Attended

  • Tanmay, Bill, Arnaud, Nathalie, Tammy, Tomas

Agenda

Decisions/conclusions

  • What should we do for GitHub main branch security policies?
    • Disable force push on main branch. If it is ever needed, the repo owner can enable it for making a specific fix & then disable it again.
    • Change main branch via pull requests only
    • We will not restrict rebase of patches (on any branch) b/c GitHub pipeline automatic rebase is useful when you're merging multiple PRs in a row. GitHub will warn you about lexicographical conflicts.
  • OpenAMP is no longer just about rpmsg and remoteproc, but our messaging is lacking around the expansion up the stack (Virtualization, Safety) & recent focus on Virtio work. Once we have demos/presentations, we should try to get the word out on OpenAMP's wider scope.
  • It doesn't make sense to do much work on doc cleanup right now if we're considering bringing in a contractor to make big changes.

Action items

  • Arnaud will check with Ed if it would make more sense to reduce his ownership level to certain repos instead of full GitHub org.

Notes

  • Github main branch security policies
    • Tanmay: Don't allow force push on main branch b/c almost never needed?
      • Arnaud: Can be needed sometimes if we made a mistake. Have used it 1-2x/yr. Could disable it by default & then repo owner only enable it for those 1-2x/yr
      • Tanmay: Or limit to maintainer only
      • Arnaud: Better to limit it for everyone to prevent maintainer from accidentally force pushing
    • Bill: Also having PRs only to main & no force push to main, you'd also catch your mistake
    • Arnaud: Don't allow new user to request CI to prevent bots
      • Bill: In future, when we have it, anything on real HW would want even more restriction (e.g. maintainer approval) so that you don't get ppl hacking the makefile for malicious purposes
    • Tanmay: Restrict rebase. Do we use much on main?
      • Arnaud: Sometimes automatic on merge. Otherwise, would have to ask contributor to make the rebase.
      • Bill: Can't rebase main without a force push, do you mean patch?
      • Arnaud: Yes, rebase on top of main branch.
      • Bill: Don't feel strongly. If 3 independent changes & they all pass independently, then accepting 1st & other contributor needs to rebase. Accepting in no particular order seems fine.
      • Tanmay: GitHub pipeline will automatically rebase
      • Arnaud: Only if something goes wrong, then will force the main branch. Otherwise we won't restrict.
    • Bill: Why do we have 3 owners on OpenAMP GitHub account? Role has a lot of capability. Arnaud, Bill & Ed. Would Ed's level of activity warrant reducing to repo owners?
      • Arnaud will check with Ed if it would make more sense to reduce his ownership level to certain repos instead of full GitHub org.
    • Arnaud: Tagging contributors as members vs. external contributors. Maybe could want to add more members?
      • Bill: We don't have to change anything right now, but can have a cut list when we want to add someone else.
  • Bill: GitHub annual bill should renew soon. Currently have 11 members. $4/mo per member. 0 cost for external collaborators.
    • Arnaud: 10 members + Felipe. Members are: Arnaud, Ben, Dan, Ed, Ioannis (asked to be member), Nathalie, Tammy, Tanmay, Felipe, Bill
    • Bill: Let's give Felipe ~1 mo to see if he does contributions & then can drop him if one of the other member companies wants a rep. Also, not super expensive.
    • Arnaud: Can ask Ioannis.
    • Nathalie: How active are they these days? Marti was active but left Nordic.
    • Bill: Nordic is very involved w/ merging of openamp & libmetal in Zephyr. It's not Ioannis, but someone else from Nordic.
    • Arnaud: 40 outside collaborators, no cost.
  • Individual updates & tracking sheet
    • Arnaud: No updates on "Virtio MMIO feasible w/ co-processor" is intern's work.
    • Arnaud: OP-TEE (OP-TEE part is upstream & Linux as client is awaiting Mathieu's review)
      • Bill: Think it is interesting to have concrete example w/ remoteproc proxy elsewhere in system.
      • Arnaud: If you need to load multiple firmware for different contexts, this allows to concatenate N fw's in 1 big binary file. e.g. MCU boot for Cortex-M.
      • Bill: Suspect NXP might be interested
      • Arnaud: Anyone w/ coprocessor w/ secure context might be interested
    • Bill: No updates b/c working on other things off this list. (We added the new tasks)
    • Tammy: In the other group wrt the doc contractor, we're talking about bringing someone in. Do we need to "tidy up before the house cleaner comes over"? Maybe we should look through in that team & specifically enumerate what the low hanging fruit is.
      • Bill: I think it's OK to have low hanging fruit with the contractor so they can have early wins. Our group should focus on the higher-level structure.
      • Tammy: Does it make sense to do any changes to the docs if big changes are imminent?
      • Bill: Agree, can hold off.
      • Tammy: New role's focus will have less b/w for OpenAMP. Have been working a lot w/ Xen & Zephyr recently, but not doing anything new for Nucleus.
      • Bill: Sounds like new direction is more synergistic now & you want safety for Xen & Zephyr & want to make sure OpenAMP isn't the downfall.
      • Tammy: Previously was AMP multi-core lead & now not using OpenAMP on projects right now.
      • Tomas: Early days of OpenAMP was RPMsg & Remoteproc. Bigger picture of OpenAMP w/ System DT, Virtio & Safety. OpenAMP starting to go up the stack. Virtualization is just another way of doing AMP. So, getting all these things to run together is synergistic to what Siemens is interested in.
      • Bill: Possibilities for future intersections w/ OpenAMP: Today, Zephyr virtio w/ OpenAMP. Today, how we do virtio in AMP could be safety certified (EOSS CFP submission), but not how Xen currently does it. Today, Xen virtio blocks your virtual CPU for arbitrary periods, so some device models can't be safety certified.
      • Nathalie: Do we need to update elevator pitch to reflect this wider scope of OpenAMP?
      • Bill: Think the basics are there, but let's get the other presentations & demos done, before we update.
    • Tanmay:
      • Figured out solution for R5-R5
        • Need fix in Zephyr Arm GIC v1 interrupt controller SW, but lower priority to upstream right now. Have created PR in staging repo for now.
      • RPMsg in U-Boot got moved to lower priority
      • Working on TCM binding upstreaming. Need to prioritize that before working on anything else.

2024-01-10

Attended

  • Bill
  • Tammy
  • Tomas
  • Arnaud
  • Dan
  • Stewart (AMD)
  • Nathalie

Agenda

  • Embedded Open Source Summit CFP due Jan 14
  • Plans for 2024
  • Individual updates

Action items

  • (DONE) Bill will share draft AMP Virtio proposal & submit to Embedded Open Source Summit CFP (Jan 14 deadline)
  • Tomas to find someone to work on getting System DT to work for System Reference, in context of HPP.
  • (OBSOLETE) Stewart will check w/ Stefano if was already existing or would be new work: app example w/ performance measurement on AMD HW that Linaro can build upon to show real-time capabilities of Xen on generic HW with Zephyr as DomU
  • Arnaud will learn more about GitHub security policies
  • (DONE) Nathalie to make 2024 task tracking sheet & send for others to populate
  • (DONE) Nathalie to send an email to TSC list about GitHub main branch security policies & Ben to ask for suggestions on policies to implement

Notes

  • Embedded Open Source Summit CFP due Jan 14
    • Bill thought the deadline was end of Jan. Will bump this task up in priority.
  • Plans for 2024
    • Bill: HPP
      • Complete AMP Virtio
        • Make sure it works in standard way
        • W/ AMP SoCs
        • Xen
      • CI, Demos, docs
      • Tomas: Should we push for any cleanup for System DT?
        • Bill: Demos today are not using System DT
        • Tomas: AMD coming out w/ System DT support in PetaLinux. Would be great if we can do in generalized way, not just in AMD way.
        • Bill: Need to rely on AMD to resource that. HPP has resource constraints & probably already over-committed.
        • Tomas to find someone to work on getting System DT to work for System Reference, in context of HPP.
      • Will continue the alternate week sync for Virtio for at least 1HCY24
    • Arnaud:
      • Finish upstream of management of signed firmware in OP-TEE. OP-TEE part is upstream. Have to upstream Linux part.
      • Come back to Virtio-MMIO work.
      • Start upstream of new STM32-MP2 platform
    • Dan:
      • Virtio-MMIO & AMP Virtio
    • Stewart:
      • Team is still doing 2024 planning
      • Primarily focused on Xen & safety
      • Integrating some Virtio PCI for Xen on Arm, including support of Virtio console
      • Tomas: Xen team wasn't too involved in OpenAMP before, hopefully more going fwd
      • Bill: Stefano has committed some support to help Linaro to prove real-time capabilities of Xen on generic HW using Zephyr as DomU & measuring the real-time performance. Stefano would deliver an app example w/ performance measurement on AMD HW. Pretty hot topic in Linaro, so eager to receive that example. Unclear if it was a pre-existing thing.
      • Stewart will check w/ Stefano if was already existing or would be new work: app example w/ performance measurement on AMD HW that Linaro can build upon to show real-time capabilities of Xen on generic HW with Zephyr as DomU
    • Tammy
      • Nothing specific scheduled. Aside from doc & conference committee, open to participating in OpenAMP. Approved by manager
      • Tammy now working in emulation/simulation, HYCON, Hypervisor (Xen) & multi-core framework.
      • Tomas: Think Xen has a great future in Embedded. Even better if within OpenAMP. AMD open to helping w/ Xen.
  • Bill: Defining GitHub main branch security policies
    • GitHub account is upgraded to team level & we switched to annual billing. $500/year for team size we have w/ extra storage for LFS that we were already paying $5/mo.
    • We can tighten up security on our main branches if we want. Should think about policies. e.g. Can say how many sign-offs on a PR & who can push to main.
    • Arnaud: OP-TEE has some security policies.
    • Bill: Aware of Joachim's HW test facility, so understand.
    • Arnaud will learn more about GitHub security policies
    • Who else to pull in? Ben had some opinions on security policies - low hanging fruit. Maybe he can make a suggestion.
    • Nathalie to send an email to TSC list about GitHub main branch security policies & Ben to ask for suggestions on policies to implement
Add a custom footer
Add a custom sidebar
Clone this wiki locally