Skip to content

OpenAMP System Reference Meeting Notes 2024

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

Table of Contents

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

Action items

  • (IN PROGRESS) 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

  • 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.
  • 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
  • Nathalie to make 2024 task tracking sheet & send for others to populate
  • 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