Skip to content

TSC Meeting Notes 2021

Jump to bottom Edit New page
Nathalie Chan King Choy edited this page May 27, 2021 · 13 revisions

Table of Contents

2021-05-26

Attended

  • Stefano Stabellini
  • Arnaud Pouliquen
  • Bill Mills
  • Ed Mooring
  • Etsam Anjum
  • Grant Likely
  • Ioannis Glaropoulos
  • Loic Pallardy
  • Maarten Koning
  • Tomas Evensen
  • Nathalie Chan King Choy

Agenda

  • 1 min: Maintainer news
  • 10-15 min: Tomas, Kumar: Heterogeneous end-to-end example
  • 3 x 5 min: Stefano, Bill, Maarten: working group updates
  • 5 min: Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit?
  • 10 min: Maarten, Jeff, Tomas: Inclusive terms
  • 10 min: Tomas: OpenAMP resourcing needs for various upcoming initiatives

Action items

  • Stefano & Nathalie: set up next System DT call (aim for mid-June)
  • Stefano: Send out slide from today
  • Maarten: Send out slide from today
  • Maarten: Schedule meeting on the Zephyr work
  • Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week)
  • Nathalie: Set up follow-up TSC call in a couple weeks

Notes

  • Link to recording (Not sure how long before it gets auto-deleted, so please download the recording in the next few weeks if you want to get caught up)
  • Congratulations to Ed on retirement. Last day at Xilinx this Friday & has offered to continue as a maintainer.
    • Xilinx is discussing internally to determine LITE assignee successor
  • Stefano: System DT update (get slides from Stefano)
    • Did March LVC21 presentation on DT state of the union, including System DT
    • Had System DT call earlier this month
    • New developments
      • Remoteproc
        • Made sure the plumbing works from system DT
        • System DT description is smaller b/c multi domain & multi cluster
        • Lopper plug-in to generate traditional remoteproc binding from System DT info
      • Biggest new development: Hierarchical domains & access flags
        • There can be many domains (e.g. on different processors, with hypervisor). Best way to describe is in a hierarchical way. (e.g. VMs as domains under Hypervisor domain)
        • Benefits:
          • Closer representation to reality
          • Access flags are domain specific b/c depends on the technology (e.g. flags on Xen domain different from flags for FreeRTOS running on Cortex-R)
    • Lopper updates
      • YAML as way to express info as input to Lopper
        • Easier for humans to read/write than System DT format
      • New DTS parser coming from Zephyr
      • More lops & hooks for adding plugins
      • Backends (incl. YAML)
      • ReST API so you can invoke Lopper programatically
      • Plugin for Xilinx CDO generation as example of plugin for generating other boot-time scripts
    • Stefano & Nathalie: set up next System DT call
    • Bill: What's plan for System DT spec?
    • Stefano:
      • For now, we're putting the description we have in the Lopper repo in .rst files (similar to DT spec)
      • Some changes (not many) will need to go to main DT spec. Small but impactful.
      • Domains could be in main DT spec or could go elsewhere. Self-contained & a bit separate.
    • Loic: SystemDT & Zephyr?
    • Stefano
      • Bruce & Kumar have a plan
      • We sent a small system DT example with a couple domains (one of which is Zephyr) to Kumar for him to try to integrate it
      • Lopper adding alternative DTS parsing: Pulling the Zephyr parser in Lopper. Idea is to merge the 2 efforts.
    • Loic: So, no firm commitment from Zephyr community to move on System DT?
    • Stefano: Not sure. Kumar is main point of contact.
    • Loic: Now is currently more evaluation & no strong decision?
    • Tomas: More similar to Linux, DT is not changing for that. Start state: Can use Lopper & create a DT for Zephyr. Optional if you don't have multiple clusters.
    • Loic: Even without multiple clusters, you can use Lopper to transform DTS file to avoid duplicating different tools. MCU boot & TF-M, with Cortex-M with Secure/NS have problems describing the IP. Know Linaro working on TF-M integration w/ Zephyr. Would be good to have common system descriptions for the different SW components. Difficult for SoC system to embed DT, so if Zephyr is moving on that, can see others to move.
    • Tomas: Would be ideal. Intent is to have 1 way of doing it.
    • Bill:
      • Break into 2 problems:
        • System DT part.
        • Whether you are consuming system DT and know which node you are, or you generate a node-specific DT & how do you update code to match.
      • Today, can do System DT processing & deliver DT to Zephyr
      • How do we do same thing with Trusted Firmware or OP-TEE, etc?
      • Zephyr looking at how to make what they do more portable to other projects, whether or not the input is System DT is orthogonal
    • Stefano: Right now more looking at reusing Lopper to manipulate DT. Lopper as a framework, can add a lot of value. Lopper is more flexible than what Zephyr currently has.
  • Maarten: App-services update (Get slide from Maarten)
    • Goal: Enable multi-OS systems to achieve Linux-based application-friendly resource sharing & IPC on multi-core HW.
    • Approach:
      • Want to reduce learning curve: use existing APIs, drivers, etc.
      • Provide unifying way to share resources across different deployment architectures & do IPC across
      • Path for mixed criticality & safety
    • Decisions & Next steps (refer to the slide)
    • Tomas: Ties in well to end-to-end example
    • Bill: You ran demo with RTOS + Linux. kvmtool up on OpenAMP GitHub. RTOS not yet visible to everyone?
    • Maarten: We implemented it with VxWorks & Linux.
    • Bill: Can I do it without paying a VxWorks license?
    • Maarten: There are non-commercial offerings from labs.vxworks.com.
      • Demonstrated initially with VxWorks
      • Want to get the Zephyr part done, so that others can contribute. Did BSD virtio port. Open sourced the user level daemon based on lkvm. Demonstration & validation activity with VxWorks to prove it out & show the value. Understand that we need to get it onto Zephyr so that others can contribute.
      • Would like to try to get some OpenAMP reserve funds to accelerate the Zephyr aspect.
    • Loic: New virtio framework for Zephyr instead of reusing virtio framework in OpenAMP library? Both are based on FreeBSD implementation. Zephyr has virtio framework, but it's already part of OpenAMP library.
    • Maarten: Not aware of other Virtio framework for Zephyr before the one that we did.
    • Maarten: Researcher in Japan did some work based on Linux GPL implementation of virtio and did some tests, but can't release on Zephyr b/c license used for that code.
    • Bill: True. OpenMAP has been part of Zephyr for several years. Virtqueue is part of the rpmsg stack. With your contribution, there is a duplication of the virtqueue level.
    • Maarten: If derived from BSD, would be great to reuse that code. We took FreeBSD virtio code & built it for Zephyr on framework side. We didn't look at optimization/duplication & that work hasn't happened yet. Would be great to have some work on optimization.
    • Loic: OpenAMP virtio will require some modification of virtio service layer in OpenAMP. Would be good to port on several OS with OpenAMP library used for virtio instead of duplicating virtio in each project.
    • Maarten: We should have meeting on the Zephyr work
    • Tomas: Potential task could be to harmonize the virtio solution in end-to-end example
    • Bill: Need to discuss scope of app-services
      • Good to focus on: Using hypervisorless virtio as a transport
      • Some of the other parts intersect rpmsg, remoteproc & system DT
      • Still have yet to demonstrate the full flow in a truly open source manner.
      • Concern that scope is starting to encompass the other parts of the project & not fully open source yet.
    • Maarten: Agree. We should be focusing on the all open source implementation w/ Zephyr
      • Have been leveraging some efforts at WR
      • Demo would be contingent on dependency of Zephyr investment. Would like this group to see how we can resource the open source demo.
    • Bill: Engagement on proprietary is perfectly fine. But want to enable community to measure what you're demo-ing. When at TI, didn't use OpenAMP, but invested in the open source to prove out concept. Would like to understand what remains to be resourced.
    • Maarten: We did the framework and console. You need the 9p filesystem protocol and you need the vsock: those are both virtio-specified drivers that don't exist for Zephyr that need to be ported from another runtime. We were focusing on the user-level daemon based on lkvm to terminate the hypervisorless virtio and open sourced that. We did the framework for Zephyr & open sourced that and been contributing into Zephyr as well.
    • Bill: Can we run a fill demo with just console today with Zephyr and Linux?
    • Maarten: No hypervisorless virtio yet in Zephyr. There's just Zephyr virtio framework. Need MMIO driver & interrupt going across to Linux.
  • Bill: openamp-rp update has been posted to list
    • New openamp & libmetal library versions released
    • Significant progress on kernel upstreaming. Slowed down a bit b/c have worked through backlog of high-priority stuff. Xilinx R5 stuff important & still outstanding.
    • Starting discussion on some PRs pending with big changes w/ wire protocol changes
      • Thinking about namespace 2.0 proposal, future proof & backward compatible
      • Resource tabling enhancements that Arnaud is working on, but need to define current spec for resource table, so can make proposal for the enhancement.
      • Negotiating message size dynamically at startup time
    • Future work:
      • We don't have a good spec for what the wire protocol is & need one
        • Right now we just look at what Linux is doing & be compatible
        • Once we have the spec, then we can have wire protocol spec changes
      • At the same time, want to tackle the OpenAMP doc infrastructure. Will be Sphinx-based. Won't be as fancy as Zephyr or Yocto Project, but they are good examples to look at. Would like to have demo of the doc infrastructure by next TSC (e.g. top level table of contents, how to generate PDFs).
      • Low hanging fruit w/ CI
      • Demo: Rpmessage with 2nd virtqueue doing a mainstream virtio protocol. I2C is a decent example in upstream kernel.
        • Different from Maarten's primary use case for remoteproc (them using services from Linux), this would be Linux using services provided by remoteproc.
        • But there's a lot of commonality, so would be good to collaborate w/ app-services
  • Tomas: End-to-end example (covering all the OpenAMP sub groups)
    • Link to strawman proposal in Google Docs
    • Linaro LITE have been talking about heterogeneous example which is very aligned with what we are trying to do
    • Running Linux on Cortex-A cluster, maybe add Xen later. Cortex-R or M cluster with Zephyr as RTOS.
    • Initial platforms to consider:
      • Ultra96 or Xilinx SOM (A53 + R5)
      • ST stm32mp1 (A7 + M4)
      • QEMU
    • Want to be able to measure throughput & latency
    • Would like to show configuration w/ System DT, lifecycle using remoteproc, low-level messaging, app-services
    • First: Enumerate the tasks, then look at resourcing.
    • Would be great if LITE can do the project management, if aligns sufficiently
    • Still at concept level & invite others to chime in
    • Maarten: Like resourcing app-services so we can have OSS implementation
    • Bill: Timeframe?
    • Tomas: Hope for end of year, but depends on what resources we can get.
    • Bill: Linaro Connect, ELC, Plumbers would be good place to show subset of progress in fall
    • Tomas: Plan to discuss more with Kumar
  • Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week)
  • Nathalie: Set up follow-up TSC call in a couple weeks
Add a custom footer
Add a custom sidebar
Clone this wiki locally