Skip to content

OpenAMP System Reference Meeting Notes 2024

Jump to bottom Edit New page
Nathalie Chan King Choy edited this page Nov 13, 2024 · 32 revisions

Table of Contents

2024-11-13

Attended

  • Tomas, Arnaud, Iulia, Nathalie, Tanmay

Agenda

Action items

Notes

  • https://github.com/devicetree-org/lopper/pull/404
    • Got merged
    • Tanmay needs to update a script in OpenAMP demo to finish addressing openamp-demo issue #8. Will create a PR in OpenAMP demo repo & then see what Bill has to say about it.
  • Tanmay will review & approve https://github.com/OpenAMP/openamp-system-reference/pull/57
  • Is there anything to discuss around Sipke’s latest docs updates?
    • Arnaud did some review & looks like it's going in the right direction
    • The form & content is good, just a few details to discuss in the docs meeting organized by Bill
  • Don’t need to discuss NR tests: Remaining items are system reference or lacking HW/simulation platform
  • Arnaud: Zephyr
    • Sent PR to integrate the new OpenAMP release
    • But there is no maintainer in OpenAMP part of Zephyr. Discussing with the Zephyr maintainers to see if someone can review.
    • This is not blocking for System Reference b/c we have our own fork of Zephyr to be able to use our OpenAMP & libmetal repos
  • Arnaud:
  • Tanmay:
    • Added task for openamp-demo issue #8 completion w/ script update
  • Iulia's item:
    • Will be completed once Arnaud merges it (probably tomorrow)
  • Arnaud: Cancel remoteproc meeting tomorrow?
    • Tanmay: OK to cancel
    • Iulia: Would like to get the invitation. -> Ask Bill on Discord to add

2024-10-30

Attended

  • Bill, Tanmay, Dan, Tomas, Nathalie

Agenda

  • Non-regression test status
  • Pending action item status
  • Task Tracking sheet / individual updates

Decisions/conclusions

  • Would like to get rid of systemdt-linaro-demo branch in Lopper upstream once we have updated system reference to use Lopper master branch

Actions

Notes

  • Non-regression test status
    • Iulia tested libmetal/main and open-amp/main on NXP targets and posted results here – all pass
    • Tanmay: Doing regression testing & ETA to complete is end of week. Arnaud will release once he comes back to office next week.
  • Pending action item status
    • https://github.com/OpenAMP/open-amp/pull/541 has approvals & can wait until Arnaud comes back for him to merge
    • Lopper demo:
      • Bruce is busy w/ a release right now
      • Tanmay made 1st demo work w/ upstream lopper master & working on Xen demo. Missing some files, need to sync w/ Bruce.
      • Tanmay to create PR in openamp-demo repo to change the submodule reference & script
      • What to do about systemdt-linaro-demo branch in Lopper? Would like to get rid of it once we are updated to master branch.
  • Task spreadsheet status

2024-10-16

Attended

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

Agenda

Decisions/conclusions

  • 2024.10 release:
    • Target to freeze library code end of this week
    • Target to complete docs and System Reference in late Dec (due to resourcing)
  • Google Summer of Code: We still have some time to decide about projects, but should prepare starting from November schedule announcement that we might need to have material ready for submission in January if OpenAMP wants to be a sponsoring organization.
  • Update System Reference to use Zephyr 3.7

Actions

Notes

  • 2024.10 release prep
    • Hoping to freeze library code end of this week
    • A couple pull requests remaining. Bill has reviewed & commented on Arnaud’s.
      • Verbose gives more info when things go wrong but blocks warnings when things go right.
    • Bill working on a PR to bring OpenAMP Zephyr testing to same state that libmetal was (latest Zephyr SDK & known good). Target to test today & then submit PR.
    • Arnaud will be OOO last week of Oct, so will do non-regression tests next week. Will do Excel of test plan and send.
    • If any issues found, may have to release in 1st week of Nov, but expect low risk b/c no major features introduced.
    • Bill OOO first 2 weeks of November. Target to release System Reference & Docs late Dec b/c other deliverables.
    • Should we bump OpenAMP System Reference to Zephyr 3.7? Yes.
      • Will require updating names of configs and overlays b/c HW model 2
      • Iulia to send email or put in discord the difference in naming between 3.6 and 3.7 and will look at NXP board & let others know.
  • 2025 Google Summer of Code details will be available in Nov. Do we think there’s any project that could be doable by a student in the summer & someone available to mentor?
    • TI went via Beagleboard.org as the organization
    • Iulia has proposed topic for NXP under Linux Foundation
    • We would put OpenAMP (if possible) or Linaro as the organization
    • If we want to be a sponsoring organization, we probably have to get involved earlier (Jan deadline) compared to the internship project idea submission which happens in March.
  • Review of recent action items:
    • Reminder to all: Please review & comment on PRs this week, ahead of 2024.10 freeze
    • https://github.com/OpenAMP/open-amp/pull/541 needs first review from either Ed or Tanmay. Dan & Bill are also listed as reviewers.
      • Tanmay & Dan will take a look
      • Suggestion is to merge it after 2024.10 release & then we have 6 months to move the API.
      • Arnaud: Know for virtio-msg will need separate allocator (allocate/deallocate/register memories)
      • Dan: Think there’s value in the PR & could use the API. Dan & Felipe wanted basic memory allocator long time ago.
      • Could be via libmetal?
    • Tanmay: Add feedback to https://github.com/OpenAMP/openamp-demo/issues/8 & work with Bruce to get it resolved.
      • Tanmay will follow up with Bruce
  • Task Tracking sheet / individual updates

2024-10-02

Attended

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

Agenda

Decisions/conclusions

Action items

Notes

  • https://github.com/OpenAMP/openamp-system-reference/pull/53
    • Andrew: The rpmsg_multi_services demo is already in upstream Zephyr. There's also another Zephyr demo in System Reference repo, can't we put these examples in upstream Zephyr so we don't duplicate work?
    • Arguments for keeping Zephyr-related samples in OpenAMP:
      • Upstream examples in Zephyr should be kept simple (enforced by Zephyr maintainers)
        • In system reference, can have just 1 firmware. Merges all things in one.
      • Putting examples upstream would make it harder for us to work on it
      • OpenAMP System Reference is also good place for where example also works on FreeRTOS (has no upstream)
      • Bill: For a whole range of samples, you need DT overlay for each board. Thinking should opt in on project basis. Overlay for each board is a pain in Zephyr
      • Iulia: Can add board per-project. For DT can add snippets & include in compilation, or put in Zephyr path where it looks for snippets. Did for QuadMax & QuadXP example.
    • Arguments for submitting Zephyr-related examples to Zephyr:
      • Don’t want OpenAMP examples to become a dumping ground / second class for examples "not good enough" to be accepted upstream. Pushing to upstream forces quality & standardization. Zephyr will force us to use stock kernels & stock Zephyr. Things that should work without patches & experimental should go upstream.
        • However, there are some things that are good enough to show but not good enough for upstream
        • Things that rely on experimental barnch should not go upstream
        • It's a process: As technologies mature, can have examples go upstream.
    • Specific to #53 example
      • Arnaud: The char device is not implemented in Zephyr. Would need new sample in Zephyr for char device. Also cannot have Linux that is __ on RPMsg channel for remote processor - today, need a patch in Linux that we have in OpenAMP Linux repo. To be able to upstream this patch in Linux, need more work b/c only ACK today. (has been pending for a year)
      • Arnaud: Resource table is getting complex. If we add RPMsg char on top of it, that adds complexity. Not in favor of increasing complexity of upstream resource table b/c would have to create RPMsg char.
      • Andrew: This example already has that complexity. Specifically for this demo, things are 1:1. This fix in #53 is already is in the upstream.
      • Bill: Want to show this capability, but still have this patch that is pending for a year
      • Arnaud:
        • Yes, it's a blocker.
        • Also, is it OK to have separate examples for TTY example, char example, or 1 demo to show all with 1 binary
    • Arnaud:
      • Also maintain openamp libmetal library in Zephyr. If they need a fix, we merge first in openamp lib & then update Zephyr openamp module to align to last commit of OpenAMP.
      • Only exception is when there is a blocker issue (today, ST RN? copy function) and then merge fix directly in OpenAMP module & then will rebase in next release. It's manual process b/c both have their own lifecycles.
    • Bill:
      • OpenAMP sample is a "kitchen sink" sample, so should reside here & not upstream.
      • Dual QEMU will not go up to Zephyr b/c it's a weird configuration & not sure what Felipe tested. Will need to fix anything that breaks b/c need for my other work.
      • Don't think we should have a general policy of all examples going upstream, but can talk about specific ones being migrated to Zephyr when stable.
    • Andrew will modify #41 to be specifically about the rpmsg_multi_services example
  • Iulia: When added 8M+ saw we are using 3.6 Zephyr but latest is 3.7 LTS. Should we update version here?
    • Bill: CI has been updated to use 3.7, but System Reference hasn't been updated yet
    • Iulia: Means we'll have to update filename of overlays & config names b/c Zephyr 3.7 has Hw model 2 where they change SOC & board configuration.
    • Bill: Would probably do that with symlinks so can work with both 3.6 and 3.7
    • Iulia: Can test with 8M+ and see if that's the only change needed
    • Bill: We don't have CI for System Reference yet. CI for libmetal is updated to 3.7 and tests against tip weekly. Will change openamp library to do same.
    • Arnaud: For 2024.10 release, would be nice to have 3.7
    • Bill: Yes, will do. Libraries will freeze in mid-Oct &r est takes a while longer
    • Bill will create GitHub issues for updating OpenAMP system reference to Zephyr 3.7 LTS
  • Andrew’s presentation on IPC through UART in ELC
    • Arnaud: Made related presentation in 2019 ELC. Did Andrew look at virtio-msg protocol? May answer some of his use cases & possible to reuse virtio driver & device instead of creating new protocol
    • Andrew: Did look at prev topics & fast RPC over UART. We actually want to go the other way, we have complex protocols & want app to see simple protocol over UART.
    • Arnaud:
      • Our demo was to read sensor & reuse IIO driver for sensor, so we needed something more complex.
      • Savor-faire Linux pinged Arnaud about Andrew's presentation & asked about RPMsg development. Interested in possibility to plug Linux driver on top, as we had done w/ RPMsg
    • Andrew;
      • Have been looking at virtio
      • Beagle products, beagle connect, grey bus
      • Same goals: Reuse drivers for remote devices
      • Some spots where we can collaborate
      • But, this presentation, was the other direction for how to walk to simpler
    • Arnaud: Need both directions
    • Andrew: Yes, layering complex on & back to simple
    • Arnaud & Andrew to share links to presentations
  • 2024.10 release
    • Arnaud: Some pull requests & some review on OpenAMP. Waiting for Tanmay or Ed to review. No issues blocking.
    • Discussed w/ Bertrand Marquis about management of capability to allocate memory from virtio devices. He feels should not be part of virtio-msg protocol & managed by OS. Means OpenAMP needs some way to manage that (e.g. baremetal or default memory allocator). So, that's blocking https://github.com/OpenAMP/open-amp/pull/541
    • All: Please review & comment on PRs
    • Arnaud called attention to https://github.com/OpenAMP/open-amp/pull/619 for updating CI to point to apps in system reference ahead of removing in 2025.04 release. Only affects Linux build
  • Andrew: Still waiting on Zephyr PR. Did get a couple more ppl to approve it, but not sure what is process to get merged. https://github.com/zephyrproject-rtos/zephyr/pull/71527
    • Bill: Is Kevin Townsend still the Arm32 maintainer? Not sure if he kept that role when he moved from Linaro to ADI.
    • Andrew: Andy Ross got assigned
    • Iulia: Andy is with extensa arch. Maybe you have wrong assignee. If Assignee doesn't approve, then it won't get merged.
    • Bill: Only addressing R5 or DSP?
    • Andrew: R5
    • Andrew: Have been pinging tejlmand to re-review unsuccessfully
    • Bill: Assignee should be able to bypass the unresponsive reviewer if can explain that it has been resolved
    • Andrew: Check maintainer file to see if assignee looks correct. If correct, ping assignee for approval and explain how review comment was addressed but person who gave the feedback is unresponsive.
  • Arnaud:
    • OP-TEE item: Mathieu & Bertrand not aligned and still need to discuss tomorrow
  • Bill: Marked 2 items as in progress
  • Iulia: Item is done now. What other samples to try next on NXP?
    • Bill: Work done so far is sufficient to be listed as a reference platform. Would be good if 2nd person can replicate. Think I'm the only one with an NXP board (i.MX 8M plus)

2024-09-18

Attended

  • Iqra, Andrew, Arnaud, Nathalie, Dan

Agenda

Decisions/conclusions

  • If Iulia's example is doing cache ops for each message, then it's a good one to include in the test regressions

Actions

  • (DONE) Bill will add review comments to Iulia's PRs

Notes

  • Welcome & intros
    • Nathalie: Program Manager
    • Arnaud: maintainer of libs, at ST focused on interaction between processors in system (STM32 families
    • Iqra: 7rs at Siemens/Mentor. Used to work on Mentor Embedded Multicore Framework, which worked on old OpenAMP. Then updated to 2018.01 & have been updating - last is 2022.10.
    • Dan: Windriver. Working on forms of more complex IPC/services based on lib openamp, based native virtio on libopenamp, which could be used by Zephyr, etc. to be virtio guests. Hypervisorless virtio allows heterogeneous runtimes to communicate & share resources on top of virtio w/o hypervisor framework present
    • Bill: Linaro. Docs, automation for CI, release images, demo images. Focus on virtio-msg which will help us do the things Dan talked bout.
    • Andrew: trying to get open amp libs in condition to work with highly heterogeneous multiprocessing SOC. Have in-house solution, but would like to join openamp fold.
  • Iulia's PRs
    • Bill has looked at the PRs but not commented in them. Has the HW so will try to test on board in October
    • OK to merge if Arnaud is OK with it
      • Arnaud: Also, it's less strict than openamp lib & libmetal, so can introduce it & fix if issues found later
    • DSP is using the cache flushing configuration. Do we have another platform doing that?
      • Arnaud: They introduce it for Zephyr, platform dependent (can choose to use or not)
    • If doing cache ops for each message, then it's a good one to include in the test regressions
    • Bill will add some comments to the PR
  • 2024.10 release prep
    • Arnaud: Sent the code freeze announcement email this morning. Zynq-7000 was discussed last time. Just waiting for review on libmetal from Tanmay before integrating both openamp & libmetal PRs. Ok if he replies when he returns from OOO.
  • Bill: Will complete the Docker & readthedocs items in the next several weeks

2024-09-04

Attended

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

Agenda

  • Removing apps from OpenAMP library
  • Do TI or NXP have new reference boards for 2024.10 release?
  • Deprecation of Zynq-7000 support
  • Update of Lopper demo
  • Task Tracking sheet / individual updates

Decisions/conclusions

  • Will remove demos from old location in 2025.04 release. Any demo changes need to go in system-reference.
  • Aiming for i.MX 8M Plus to be the NXP platform for System Reference, hopefully at least resource table sample can be part of 2024.10 release
  • Deadline for 2024.10 release changes is mid-October. Last 2 weeks of October are for non-regression tests.
  • Dropping Zynq-7000 support officially in 2024.10 release

Actions

  • (DONE) Nathalie: Need to set up board meeting for end Sept early Oct & could ask then if dockerhub spend needs a board vote

Notes

  • Removing apps from OpenAMP library
    • In progress, need to make the CI point to the System Reference
    • Will maintain current demos in old location for 1 release & remove in 2025.04
    • Will tell users that we will not accept changes to demos in open-amp, just System Reference & then they have 1 release to update their pointers to the new location
  • Do TI or NXP have new reference boards for 2024.10 release?
    • Andrew: Won't have for 2024.10. Would need some fixes in examples, which are blocking.
    • Bill: We're not freezing examples in system-reference
    • Andrew: Will send a PR for a couple fixes, but don't think will make the timing for this upcoming release
    • Iulia: Currently only NXP person working on this. Focusing on adding new board support in Zephyr for OpenAMP resource table sample: i.MX 8M Plus for DSP core & working on M7 and QuadMax and QuadXP, but haven't tested OpenAMP System Reference samples.
    • Bill: Even if resource table works, we can start talking about it in release notes
    • Iulia:
      • It works now, but have to make PR for QuadMax & QuadXP. Need to make sure no code duplication before send for review.
      • RPMsg multi-services seems very similar to OpenAMP resource table from Zephyr. Will it just work if I run w/ 8M Plus?
        • Arnaud: It should. Multi-service RPMsg is extension of Zephyr OpenAMP resource table example. If you can run on your target w/ OpenAMP resource table, the System Reference one should work - may need some overlay.
      • What will be the deadline? Wouldn't want to block to add NXP board?
        • Arnaud: Mid-October. Last 2 weeks of Oct are for non-regression tests.
      • Will try to get it to work then & look at the others later
  • Tanmay: Deprecation of Zynq-7000 support
    • We have decided to remove Zynq-7000 support from OpenAMP and libmetal, but still getting new issues filed.
    • Pretty sure that code isn't being maintained or tested.
    • Is it OK to say we're in progress of deprecating this platform & won't support further?
      • Arnaud: Dropping support of the platform will be official in 2024.10, in the release notes?
      • Tanmay: Changes should be in for 2024.10 release
      • Arnaud: There is already a PR
      • Tanmay: Didn't announce for 2024.05 release but sent email after the release.
      • Bill: People using it are probably also using old versions of OpenAMP libraries
      • Tanmay: Agree
      • Bill, Arnaud: OK to drop support in 2024.10
      • Tanmay: Will rebase & then push new revision
  • Anything to discuss about “Update lopper demo to work on current code base”?
    • Bruce/Bill and Tanmay need to discuss
    • Bruce should be back from vacation this week, so Tanmay will reach out to him
    • Tanmay will be OOO but have a couple weeks between return and release - timing should be OK?
    • Bill: Demo won't be cut til Nov & doesn't intersect the libraries, so by end of Oct should be fine
  • Task Tracking sheet / individual updates
    • Tanmay: "Provide apps directory in OpenAMP system reference" is done will start on split mode support in Zephyr
    • Andrew: Still waiting on Zephyr folks for the PR & once it's accepted everything should start working automatically. Our PRs have been stalled on Zephyr for months.
    • Arnaud: no update on these items
    • Bill:
      • Working on the dockerhub item
      • Also working on adding another seat for GitHub $17 for rest of this year and $44 for next year, but having issue w/ CC
      • Dockerhub usage is much less than GitHub. Upgrade is to have other admins, or could figure out how to mitigate risk of bus factor.
      • Nathalie: Need to set up board meeting for end Sept early Oct & could ask then if dockerhub spend needs a board vote
      • Bill: Will wait to pull trigger
    • Dan: trying to get started on upreving kernel version for demo. Will discuss w/ Tanmay & Bill.
    • Iulia: i.MX 8M plus will be the first choice. Have 2 other possible boards.
      • Bill: i.MX 8M plus makes sense
      • Iulia: DSP as secondary core & some examples w/ Cortex-M7 but not w/ OpenAMP
      • Looked at what samples we have & upstream. Have i.MX RPMsg ping-pong & TTY, but both using RPMsg lite samples. Not sure if makes sense to port to system reference. Looks like already have echo sample, which is similar to ping-pong. TTY is also similar to multi-services sample w/ TTY.
      • Arnaud: Do you use RPMsg TTY upstream driver?
      • Iulia: Using NXP driver, so don't think should port example b/c already have examples in OpenAMP that also work on other boards.
      • Arnaud: There is a patch in Linux staging branch that is needed to be able to create end-point from Linux for remote side. It is explained in the readme of the example. Required to run last part of RPMsg multi-services example.
      • Bill: kernel built for last release might work if you give it the right DTB. Good part of the demo will run even without the patch.
    • Andrew: Kendall not working on OpenAMP yet, but she started doing related work w/ remoteproc.
  • Docs project
    • Bill: Docs contractor happy to re-engage for Phase 2 and will send contract reflecting that

2024-08-21

Attended

  • Tanmay, Bill, Nathalie

Agenda

  • Discuss open actions from last call
  • AMP Virtio/HVAC
  • Task Tracking sheet / individual updates
  • Any topics for docs committee to stay on the line for? E.g. anything to discuss about table of contents ahead of next week’s docs meeting?

Actions

Notes

  • Discuss open actions from last call:
    • Tanmay: Add feedback to https://github.com/OpenAMP/openamp-demo/issues/8 & work with Bruce to get it resolved.
      • Bruce is on vacation until 9/3
      • He is working on this task in background but September release is due first
      • Ben also knows a lot about this & could pull him in if need earlier
      • Libraries will freeze in Sept but demos will freeze in Oct. Ideally would like fixed by late Sept/early Oct.
      • Tanmay tried with latest tip of Lopper but it failed w/ some filename changes. Have rough idea of how to set up, but much faster w/ Ben or Bruce level of knowledge.
      • Bill & Tanmay can update demo side after the issue is resolved
    • Tanmay to check w/ Ed if he plans to review the PRs & if not, can go ahead & merge it once have the 2nd review
      • Ed hasn’t had a chance to review
    • (DONE) Iulia will review https://github.com/OpenAMP/openamp-system-reference/pull/44
      • PR is approved and waiting to be merged (her review is 2nd ACK)
      • Can’t build the demos without the Xilinx BSP, but Tanmay has tested that part
      • This is a copy of the sources + some mods to make it work with cmake infrastructure
      • Merging this doesn’t remove these from openamp library. Will give at least 1 release before removing.
      • Will need to update the CI test to be multi-repo after we merge this.
      • Not required for the upcoming AMD release (45 was)
      • Arnaud to merge
      • https://github.com/OpenAMP/openamp-system-reference/pull/44 since Tanmay was the developer
    • (DONE) Bill will ACK https://github.com/OpenAMP/openamp-system-reference/pull/45
      • Bill merged the PR
    • (DONE) Tanmay will ask Ben to join next RP call to continue discussion on https://github.com/OpenAMP/libmetal/pull/302
      • Bill merged PR
  • AMP Virtio
    • Edgar will be the AMD architect
    • More ppl in Tanmay’s team are also working on the CES demo & Tanmay will stay in the loop. They will be leveraging the code base without Xen. They will be helping w/ OpenAMP kernel, can help with code reviews.
    • Xen doesn’t play much of a role in the end solution anyway, so it can be included or left out
    • Tanmay will give Bill the names to add to 8/29 public HVAC meeting
    • (the alternating Wed OpenAMP Virtio call got rolled into HVAC)
    • Using virtio-msg transport layer. Edgar most interested in virtio-net as top level. Bill expects we’ll test with net, rng, i2c
      • RPMsg is a top level protocol like virtio-net
      • Virtio-msg is a transport layer like virtio-mmio
        • Bill will propose that we use RPMsg under virtio-msg as the mechanism for transporting messages, specific virtio-msg bus implementation
    • More info at: https://linaro.atlassian.net/wiki/spaces/HVAC/overview
    • Some folks at Linaro are also looking at FFA transport to secure world
    • Does the project have a min data speed requirement between the 2 cores?
      • First step is to make it functional & prove that the concept/spec works. Then can start looking at performance.
      • Edgar has something going achieving decent bandwidth (on the optimistic side). Assumption is the packet buffers can go anywhere in memory.
      • Throughput will vary depending on where the buffers are located & how much copying is involved
  • Docs committee
    • Likely will push the DE sync out a week b/c OOOs

2024-08-07

Attended

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

Agenda

Decisions/conclusions

  • Would be nice if System Reference had some generic code that could use on multiple RTOS & platforms, but currently a weak spot for project. Have to provide some hooks so each platform can implement in their BSP, so that demo can be generic & portable, but it isn't the case for all demos right now.
  • Release images are tagged but no release email yet due to doc update outstanding

Action items

Notes

  • Lopper demo update
    • Bill created a GitHub issue for it. To do item for next release.
    • Tanmay also had some suggestions that should get folded in
    • That demo is pulling from a 2yr old commit & Lopper has moved on a lot
    • Bruce has action to update demo to work on current Lopper & that is necessary before Tanmay's feedback can be incorporated
  • Tanmay's pull requests
    • Already had multiple review cycles & edits w/ Arnaud
    • Policy requires 2nd reviewer
    • 44: Moving apps dir
    • 45: Unbind
      • Might be only on AMD Xilinx platforms
      • Tanmay to create an issue for switch to ioctl & assign to himself. Here it is:
      • R/W access still requires root. Would like check w/ just read & if need to make change then request write. That would allow non-privileged user to check & just use it if OK. But if will switch to ioctl method, then can use as-is.
      • Bill will ACK PR 45 once Tanmay creates the ioctl issue
      • Tanmay to check w/ Ed if he plans to review & if not, can go ahead & merge it
  • Andrew
    • Kendall hasn't yet been reassigned to the internship work
    • Still waiting on progress on Zephyr side to get base support in
    • Waiting on System Reference demos to be moved over before taking new work
  • Bill
    • Released demo images and tagged
  • Dan
    • No update
  • Iulia
    • Enabling more platforms w/ OpenAMP. Have done i.MX 8 QuadXP , working on i.MX 8 Quad Max
    • First goal is to add them in Zephyr b/c need for CI, then might be able to check System Reference
    • Just Zephyr & Linux sufficient for system ref?
    • Bill:
      • We do build tests for baremetal & FreeRTOS.
      • Integrated demos: Xilinx has a baremetal demo, but that is hard to reproduce w/o whole build flow. ST has own build flow.
      • Would be nice to have other demos here if can do in semi-portable way & not have to carry bunch of platform-specific code.
      • Zephyr demo is Zephyr specific
      • There are simple demos that Xilinx has that run on Baremetal & FreeRTOS
    • Is the code specific for platform or for OS? Sounds like system reference shouldn't be specific to OS, should work on multiple
    • Bill:
      • There is a Zephyr directory in system reference & all that will be Zephyr-specific.
      • Tanmay working on demos in System reference & should be more portable, but only ever tried on Xilinx platform.
      • Would be nice if we had some generic code that could use on multiple RTOS & platforms, but currently a weak spot for project.
    • Have some simple examples (e.g. ping pong, RPMsg) & will check if they can be ported to OpenAMP
    • Tanmay:
      • Have to provide some hooks so each platform can implement in their BSP, so that demo can be generic & portable, but it isn't the case right now.
      • Currently the AMD Xilinx demos do in the demo or libmetal & planning to remove that.
      • We want to move to System DT flow to generate platform-specific info & can use in these demos, but not there yet.
  • Tanmay
    • Been working on demos
    • Got ACK from Arnaud on PRs & waiting for 2nd ACK
  • Prev action: https://github.com/OpenAMP/libmetal/pull/302
  • Prev action: Arnaud will test docker on Ubuntu machine
    • Docker only has the Xilinx stuff & no ST stuff, Bill just wanted a 2nd set of eyes
    • Tanmay tested on Ubuntu machine
    • Arnaud didn't send any feedback so Bill released based on Tanmay's feedback
  • Tanmay: Did Bill send release email?
    • Bill needs to update OpenAMP docs to match the demos, but the images are released. Need to edit docs & tag it. Deferred for now b/c have to work on different project.

2024-07-24

Attended

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

Agenda

  • Actions from last time:
    • Bill to reply documenting the unified config fragment
    • All: Please give Bill's provisional Docker image a try
  • Bill’s proposal for 2024.05 release and getting volunteers for testing
    • Testing of sd card images by others
    • Testing of docker images by others
      • Especially anyone with an Arm based macbook
  • Arnaud, Tammy: Doxygen item https://github.com/OpenAMP/open-amp/issues/506
  • Arnaud, Tammy: Any warnings remaining after https://github.com/OpenAMP/open-amp/issues/458 ?
  • Task Tracking sheet / individual updates
  • Docs committee: Please stay on the line to discuss next steps with DE

Decisions/conclusions

Actions

Notes

  • Tammy: No more Nucleus, but more focus on emulation - OpenAMP fits in.
    • Tammy having a lot of meeting conflicts b/c new role.
    • Siemens wants to stay active w/ OpenAMP.
    • Tammy will find out if another Siemens person can engage more actively w/ OpenAMP.
  • Actions from last time:
    • (DONE) Bill to reply documenting the unified config fragment
    • All: Please give Bill's provisional Docker image a try
      • Tanmay will test QEMU & KV260 docker images (try for next week)
      • Arnaud will test docker on Ubuntu machine
      • When do we want to tag?
        • Getting test results sooner the better in case re-work is needed.
        • Bill will aim to tag on Tuesday
      • Bill hasn't tested on macbook, but on Arm
      • Tanmay: Do we have testcase list to verify the images?
      • Bill: the SD card & Docker walks you through what you can do. Try all 3 options for ZynqMP & all the demos at login.
  • Arnaud: Suggest to release by end of this month. Can make minor update later if needed.
  • Can close https://github.com/OpenAMP/open-amp/issues/458 .
  • Arnaud: Ben's pull request for restructuring platforms & projects https://github.com/OpenAMP/libmetal/pull/302
    • AMD has platforms w/ several cores
    • OpenAMP & libmetal libs are structured w/ associated 1 directories for things
    • Each platform has to regenerate to the directory
    • Should we structure the libraries & System Reference to have a hierarchy that would be similar to Linux hierarchy
      • SOC vendor folder
      • SOC folders for each platform
      • Folder for each core
    • Tanmay: In multicore systems, some cores have different configs & need to be able to tell which core this libmetal is being built. Currently have something Xilinx specific where we mention each platform & core w/ variable PROJECT_MACHINE
    • Arnaud: Would be nice to apply same rule for all libs & docs, so users can refer to same hierarchy. Will probably need in OpenAMP & System Reference & CI & docs
    • Would be good to have Ed in the call - he's usually on Thur RP call
    • Bill: Don't have a well-informed opinion yet. So far, SOC platform sounds good & coalescing lots of individual platforms into a common structure sounds good.
    • Arnaud: Do we want to sort by vendor, as is done in Linux DT? Do we want to sort by platform or platform family?
    • Bill: Platform families tend to be associated to a vendor? And then could have a generic "vendor". Maybe can keep things flexible underneath vendor?
    • Arnaud: SOC family won't change but name of vendor company may change
    • Bill: Kernel still uses Freescale even if bought by NXP
    • Bill will put https://github.com/OpenAMP/libmetal/pull/302 on the agenda of the RP call
      • Arnaud won't be able to attend 8/8. Will follow the decision. Just want common solution for all the repos, otherwise have no strong opinion.
  • Individual updates
    • Andrew:
      • Kendal got hired back by TI. Some of her work might come back up to enable System Reference on TI platforms, but she has not been assigned that work at this time.
    • Arnaud: no update
    • Bill: Already updated the tracking sheet
    • Dan: No update
    • Tanmay:
      • Have been addressing comments & moving examples to System Reference
      • On Linux apps, sending some patches
      • Working on openamp System reference demos mainly
      • In kernel, sending last part of OCM support. Would like to see this get upstream. Will be able to get back to U-Boot after that.

2024-07-10

Attended

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

Agenda

  • Anything to discuss regarding 2024.05 release for System Reference?
  • Arnaud, Dan, Andrew: Virtio_mmio – Andrew’s patch (I don’t have the link) and Dan’s patch as potential alternative
  • Arnaud, Bill: Any demo feedback from Sipke to discuss with System Reference group?
  • Task Tracking sheet / individual updates

Actions

  • (DONE) Bill to reply documenting the unified config fragment
  • (DONE) All: Please give Bill's provisional Docker image a try

Notes

  • Don't need meeting for Lopper. Fixed up old demo for this release. Would be good to get it updated in next release.
    • Bill will reply to Bruce's email
    • Tomas will bring it up in next 1:1 with Bruce
  • Docs feedback can go at the end
  • Actions from last time
  • Andrew
    • Got a GSOC intern but doesn't look like he'll work on this
    • Waiting for that to go upstream.
  • Bill
    • Still working on release
  • Tanmay: If I sync to latest Docker image, will it pick up previous release?
    • Bill: Haven't pushed Docker images since 2022 & haven't pushed WIP. Would push that under a WIP tag when ready for ppl to test.
  • Anything to discuss regarding 2024.05 release for System Reference?
    • Bill: Expect to publish draft SD card image for KV260, ST & ZCU102 images by end of week. May have provisional Docker image by then. Would like help from folks to test when they're out.
  • Arnaud, Dan, Andrew: Virtio_mmio – Andrew’s patch (I don’t have the link) and Dan’s patch as potential alternative
    • Andrew updated his patch based on Dan's & it is merged. Does the same thing now.
    • Dan's wasn't a PR so can just ignore
  • Docs feedback
    • Next release
  • Arnaud
    • Ongoing discussion w/ Mathieu for OP-TEE wrt error management
    • Is anyone else using OP-TEE's remoteproc?
      • Don't believe so
  • Dan
    • No update
  • Tanmay
    • No update. Working on System reference demos.

2024-06-26

Attended

  • Tanmay, Bill, Arnaud, Iulia, Nathalie, Bruce

Agenda

  • https://github.com/OpenAMP/open-amp/pull/596
  • Additional changes by Arnaud awaiting review by Carlo, Tanmay & Ed
  • Any volunteers for non-regression test?
  • Bill & Tanmay: Is the decision to go with v6.6 kernel (not v6.9, not v6.10-rc) for demos?
  • Arnaud, Bill, Tammy: Any demo feedback from Sipke to discuss with System Reference group?
  • Task Tracking sheet / individual updates

Decisions/conclusions

Action items

  • (DONE) Bill to document how to use the config fragments to build
  • Arnaud will send pull request to point to meta-ST layers for Scarthgap
  • (DONE) Tanmay to reply on https://github.com/OpenAMP/open-amp/issues/506
  • (IN PROGRESS) Bill will look into adding OpenAMP contributor access for Iulia & Andrew (generates billing to Linaro/OpenAMP) & give an update next time about billing above 10 contributors
  • Nathalie: put on agenda to discuss with TSC how to define project roles for OpenAMP (can probably borrow a lot from Zephyr's governance)

Notes

  • https://github.com/OpenAMP/open-amp/pull/596
    • We got a couple reviews now (Ed & Iulia)
  • New patch release needed on 2024.05 to fix issue w/ Zephyr
    • Found 2 regressions. Not found w/ RPMsg multi-protocol.
      • Nordic simulation test using OpenAMP in driver failed
      • Iulia tested Zephyr samples that rely on OpenAMP
    • Many different ways to use OpenAMP.
      • Would be good to have pre-integration w/ Zephyr for next release to get full Zephyr CI (better test coverage than OpenAMP CI) – send PR for openamp & libmetal module & West manifest
      • Would be good to update the System Reference applications to cover
    • Bill & Tanmay: Is the decision to go with v6.6 kernel (not v6.9, not v6.10-rc) for demos?
    • Likely to go with v6.6 kernel b/c have a combination that works on both KV260 HW & QEMU
  • Tanmay: Dan was looking for what kernel version to use
  • Will we publish defconfig for this release?
    • Bill: The config fragments are in the metadata, so published in Yocto Project way.
    • Bill to document how to use the config fragments to build
  • Arnaud:
    • If needed, we have released meta-ST layers for Scarthgap. Won't make it into openamp 2024.05, just FYI if you need it.
    • Arnaud will send pull request to point to meta-ST layers for Scarthgap
    • Bill can change from Nanbield to Scarthgap and should work.
    • https://github.com/OpenAMP/open-amp/issues/506 and other doc items
    • Mainly discussion w/ Tammy
    • Also looking for Tanmay's opinion. Tanmay to reply on https://github.com/OpenAMP/open-amp/issues/506
    • Arnaud, Bill, Tammy: Any demo feedback from Sipke to discuss with System Reference group?
    • Sipke making good progress & expects to be mostly done by next meeting in 2 weeks
      • Has pushed his notes to the private repo openamp-docs-notes
  • Contributors
    • Don't have to pay for outside contributors
    • We have paid for 10 contributors & have 9 ppl officially in
    • Added Sipke as private contributor to openamp-docs-notes, which used our 10th license
    • Bill will look into adding OpenAMP contributor access for Iulia & Andrew (generates billing to Linaro/OpenAMP) & give an update next time about billing above 10 contributors
    • Currently adding contributors ad hoc. Could propose to mailing list some governance around GitHub organization member & contributor status & merge access to TSC mailing list, or have a TSC meeting to discuss. Default policy is that each repo has 2-3 ppl who can push to branches & anyone can send PRs. Affects expenditures by OpenAMP project.
  • Task Tracking sheet / individual updates
    • Arnaud
      • Still discussing w/ Mathieu on remoteproc integration in Linux
      • Virtio-mmio: Need to find time to work on it. Will try to clean up work from intern in Linux staging branch.
    • Bill
      • Working on the release
      • Got hung up on kernel configuration for a few days
    • Iulia
    • Tanmay
      • Created draft PR to move demos to openamp system reference repo
      • Not using West as of now. Expecting user will provide the directories. Will switch to West & sync openamp & libmetal libraries.
      • Arnaud: Using West will ensure compatibility between system reference & libraries
      • What if user wants to link in pre-built libraries when building application?
      • Arnaud: User gets sample, does cmake & make & all built in 1 step. If we ask them to first put openamp libs & libmetal and build them separately w/ proper options, it is more work & harder to do CI. User can customize the makefile if they want.
      • Bill: Prefer that we all build the same way. What is reason for prebuilt libs?
      • Tanmay: Prebuilt for openamp & libmetal. Don't want to assume that the app will have openamp & libmetal source code available. Do we want to issue 1 cmake to configure all 3 repos for system reference demos?
      • Bill: Doesn't apply to Zephyr b/c everything builds from source w/ Zephyr. For baremetal, it could be a use case, but more likely you'd have a BSP library that is pre-built & don't want to add how to build it. Would need to see the code... Having something in cmake that looks in a spot & uses it, could make sense for BSP.
      • Arnaud: If have dependencies in cmake and subproject is already linked & it finds the library, it should not try to regenerate it. Maybe have to test it out. Also have case of dynamic library - can support for Linux, but other OS and baremetal are just static libraries
      • Tanmay: Build system: Library is separate target, demo is separate target. Want to make sure library is same version that demo is compiled with. If have separate targets, have to maintain the target versions manually. If manage as dependency, can make sure same version is installed in system & compiled for demos. Is there a way to make West optional?
      • Arnaud: West is interesting - if you want to install your environment you use West. If you have your own environment, you'd do in 2 steps. You can download package in cmake, but better to do in West b/c West is optional & could define per-platform. West gets the package, gets the branch & puts in your environment - there is no build mechanism. You can get own package by giving URL & branch to check out. Quite flexible.
      • Bill: Building baremetal w/ YP is a Xilinx SDK thing & not upstream openamp thing, but that can still be compatible. Cmake can figure out if the libs are already there & build if not. OpenAMP System Reference view will be using West & building the libs, but you could do it a different way in the Yocto flow.
      • Arnaud has example where integrated Tanmay's PRs
      • Iulia: Referring to West YML file or West doing the build & everything. West is based on cmake, so if don't want to use west update, etc. can use cmake b/c based on cmake. Using West command?
      • Arnaud: Calling west init w/ YAML file & setting up environment
      • Bill:
        • West build command comes from Zephyr repo. If you don't include Zephyr, West doesn't know how to build, it is just a repo set tool.
        • At one time you couldn't build BSP without Xilinx tool stack. That could be a reason to bring in BSP as a pre-built. That should be possible. For ease of integration & development, the default system reference flow should be to build the libraries.
      • https://github.com/arnopo/openamp-system-reference/tree/legacy_app/examples/legacy_apps
  • Do we want to keep demos in OpenAMP library for 1 release?
    • Arnaud: Yes. After we integrate in System Reference, will need to update CI. Can remove after we update. 1st step to just move openamp. 2nd step to move libmetal.

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

  • (DONE) 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)
  • (IN PROGRESS) Tanmay to look into using West to take care of open-amp library sources for application build
  • (OBSOLETE) Tanmay & Bill to notify Dan if will use v6.9 or v6.6 kernel, once they get Ethernet working
  • (DONE) 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
  • (DONE) Arnaud to update system reference to point to latest release openamp & libmetal (PR43)
  • (DONE) 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

Actions

  • (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.
  • (OBSOLETE) Arnaud & Tanmay: Put in May release notes to warn that we plan to make application migration change in October release
    • Not done, but not critical

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

Actions

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

Actions

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

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.

Actions

  • (OBSOLETE) Arnaud will check with Ed if it would make more sense to reduce his ownership level to certain repos instead of full GitHub org.
    • Decision is to keep Ed as full member. We can have 10. Prefer to shuffle out others with smaller/inactive roles if needed.

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