Skip to content

OpenAMP remoteproc Subgroup Meeting Notes 2019

Jump to bottom Edit New page
Bill MIlls edited this page Dec 28, 2019 · 16 revisions

Table of Contents

Introduction

This sub-group covers areas such as remoteproc, rpmessage, virtio, big buffers, etc. The proposed meeting cadence is every 2 weeks.

2019-12-19

Agenda

Attendees: Don (Linaro), Mathieu Poiier (Linaro), Clement Leger (Kalray), Etsam Anjum (MGC), Maarten Koning (?), Mark Grosen (TI), Bill Mills (TI), Tomas Evensen, Stefano Stabellini, Bruce Ashfield, Arnaud Pouliquen, Ben Levinsky (Xilinx), Ed Mooring,

Next Meeting

  • Bill: Next meeting date: Scheduled for Jan 2nd, suggest cancelling. Consensus was reached
    • Old invite ends in 2019
    • Action: Bill to set up new meeting slot likely with a new zoom starting on Jan 16th.

64bit addresses in Resource table and Resource table evolution

  • Clements writeup:
  • Clement: 32 to 64 bit migration. Lots of 32 bit types. Alignment issues highlighted that could be problematic for other architectures. Need to find an efficient solution to the problems
    • Bill: No objections to the proposal. May not need to be as cautious as suggested.
    • Other pre-meeting reviews?
  • Loic: Need support for 64 bit coprocessors. May be good to have two 32 bit for PA High and PA Low if makes sense. Need to work on a more generic solution.
    • Clement: So always aligned on 32 bit for compatibility?
    • Loic: Yes
    • Clement: generic remoteproc alignment may be problematic
    • Loic: Need to differentiate from Linux only implementations. May also be nice to further discuss buffer ring architecture (?). Having all the buffer size defined for V2. Missing location of VDev.
    • Arnaud: Also adding size of host table itself as well. Get size by reading the ?. Also SoC version info? PRocessor state of remote processors to mge suspend/resume. Trace improvement w/ read/write offsets.
    • Loic: Today hard to understand memory allocations
  • Tomas: Since more w/ device trees, an optional device tree global to help understand resources and addresses
    • Loic: Should we keep as is or DTB?
    • Should be optional, but for advanced use cases could be a verification mechanism. A more compact dtb for verification could be nice.
  • Suman: Unless changing resource headers don't see need to bump up the Version number. A magic number if loading from somewhere else. As long as adding resource types, define an new resource type number or introduce a versioning field. Been using sub fields in 32 bit value downstream (TI vendor tree). Check if separate type needed for each variant.
  • Suman: Also, need to incorporate rproc features into resource table itself to see if anything needs communicated to the table. F/W and remoteproc driver alignment/compatibility needs considered (always tricky - since mixing/matching resource types). Likely not possible to assure every resource types added are aligned. Overall size of resource table incorporated into resource table needed.
  • Bill: There will always be a new resource type to add. Would like to know per resource if resource is required or optional. Version numbering helps with this, but could also use a resource table identification and if not understood, don't use.
  • Bill: Suman also suggested ranges for the resource types as opposed to an enum. Keeping kernel source as one place to define resource types.
    • Suman: Yes, the range was already added upstream (VX.x?). But up to end user - remoteproc core should stay agnostic.
  • Suman: Was interested if need to handle resources before/after loading. Today handled prior. If need to do handling after loading
    • Loic: After loading use case?
    • Suman: Like having a f/w defined pointer for spinlocks - didn't have ownership and needed to reclaim the locks and keep track of them. Another is variable type resources for f/w expandable items where f/w needs to be loaded first.
  • Loic: Was a resource manager developed?
  • Suman: Resource Mgr is whether can grow or is fixed. A scope to grow with resources. If can grow, the RT size isn't constrained w/ a pointer on both sides.
    • Bill: RT's during load may be fixed up, but after load should be constant.
    • Suman: RT's are already read/write somewhat for virtio ready indication(?)
    • Bill: Not thrilled with the idea, lets not double down on random read-write of resource tables.
  • Clement: What to do for next round?
    • Bill: Work on resource table laundry list.
  • Action Bill: Create a resource table laundry list wiki page and share.
  • Next time on this topic we should review to decide which should execute now and which can wait. How can we define a table that expands to needs as move forward. Versioning, required, optional, etc. May require incrementing the top level version number.
    • Ed: Should decide what problems to solve first.
    • Bill: That's the laundry list
    • Ed: Focus on problem, not solution
    • Bill: a laundry list is brain stroming, get the ideas out in whatever form people want to share
    • Tomas: Agree w/ Bill that need a way to determine changed
    • A feature flag could do this.
    • Clement: Even Feature Flag can be limited.
    • Bill: Right now a list of items - please think about it
  • Stefano: would it make more sense to have ranges as a document in OpenAMP? like ACPI deviceID's for example. Then a single text document.
    • Bill: There will be doc, header file, and linux kernel header at very least to keep in sync. One needs to be the master, don't care which.
    • Stefano: Agree.
    • Bill: Etsam has mentioned we don't have a spec and should.

Ben's patches sent to the list - examples for pass buffers by reference model

  • Bill shared Bens patchset on the screen:
  • Ben: First part to introduce using out of band data rpmsg mode.
  • Bill: Same c file on host and client?
    • No: separate files - will update documentation to reflect that. ACTION?
    • Mathieu: Would appreciate update. What happens on App Processor having a clear picture of solution vs one side would be helpful
  • Bill: Is ping a different app or other side?
    • Ping is client / other side
    • Could be bare metal. Did Linux to Bare metal, but could be bare metal to bare metal
  • Userspace rpmsg in this solution
  • Buffers coming from out of band. Carveout is known to both sides.
    • Ben: A cleanup option is to get info from dev node(?) on Linux side. On bare metal a separate header file would be nice.
  • Bill: From V2, squash to clean up patches. Patches should be logical / functional. More context on how built and run would be good. Building rpmsg from userspace - is this supported cross distro?
  • ACTION: Ben document build process. Uses R5 toolchain presently. Using OpenAMP cmake structure for demos.Booting Linux and loading onto RPU via echo. Linux build on Yocto Meta-OpenAMP layer. Specifies to build apps via flag. Leverages rpmsg in user space.
  • Bill: Meta-OpenAMP - which one being used?
    • Ed: Xilinx - Github - All can be built off Xilinx Github, not OpenAMP github - haven't tested to see if all builds on OpenAMP. Have instructions to build testbed using QEMU docker images.
  • ACTION: Ed share w/ list or create a wiki page on build instructions. for OpenAMP.
    • Bill: Need to get info on build process before many of us will be able to participate much
    • Ed: Goal to get OpenAMP github repo / instructions in sync to build complete OpenAMP environment without chasing vendor specific ratholes
    • Out of bounds: How dependent?
    • This existing implementation is on top of existing rpmsg framework. Can build separately on top for this demo.
  • Bill: Got stuck on how do both sides coordinating buffers to use.
    • No abstractions for allocating shared memory across this.
  • Bill: Thanks for the patches Ben. Helpful in understanding.
  • ACTION: Ben: In V2, make more verbose README
    • Bill: If Ed's build instructions not too far out, could leverage this as well.

2019-12-05

Attendees:

Suman Anna, Bill Mills, Mathieu P(Linaro), Don(Linaro), Clement Legar (Kalray), Nathalie C., Etsam Anjum (MGC), Tomas Evensen (Xilinx), Loic Pallardy(ST), Ed Mooring,

Minutes:

  • Suman posted write up on TI Socket i/f and it's limitations
    • In App Services call, there was interest in Socket I/F
    • Bill: Not convinced it's needed
  • Loic: Sent patches to list. Good reviews from Mathieu, awaiting Bjorn feedback.
    • More comments / acks appreciated.
    • Mathieu: This work is precursor to some of the wiki future work. Adds robustness to rpmsg and late attach/ detach. Lots of work, but good start.
      • Loic: Have another patch series still under internal review that helps w/ attach/detach but needs Bjorn review
    • Bill: TI internally brought up remote I2C/SPI and regmap over rpmsg. An internally developed patchset to add framework on top of rpmsg to do virtual devices over remoteproc. Not convinced of need but use case is interesting. Need to configure switch/registers/etc. So regmap i/f would fit nicely. Also another use case is to have a control plane with shared registers. Might be worth exchanging ideas in these use cases
  • Loic carrying patches for I2C and SPI as well?
      • Yes: Working to support virtual ???. Have something working internally. Mid January could have something to share.: One vdev node for virtio network, another for ???. Have never run into running out of buffers - must be sized. Bjorn's suggestion in this are helpful. Main issue is service probing done dynamically, but once probe on top, not real clean. Need to manage several co-P's to determine which P is managed is helped by Device Tree. All services based on OpenAMP.
    • Bill: libopenamp rpmsg callback buffers must be consumed in the callback.
      • Loic: Not sure on this, not familiar
      • Etsam: Bill is correct. Buffer put back into the queue.
      • Bill wanted an option to hang onto the buffer. Especial for slow I2C use case
      • Etsum: Currently not there
      • Today must copy to another buffer
      • Loic: Agree that should release later.
      • Ed: Raising an issue in libopenamp repo is the way to handle issues like this. Need to write down this process, but for now a github issue is best bet.
      • AI: Bill to raise this issue in github
  • Loic: for resource mgr, would like to rely on SCMI. A new LBI on running trustzone has been created. Need to discuss how co-processors request resources.
  • Suman: So asking for dynamic peripheral ownership?
    • Loic: Yes.
    • Bill: envisioned remoteproc had own channel. Need to go back through host?
    • Loic: Depends on h/w. If not dedicated co-P, sned request to trustzone. May need to support multiple use cases.
      • Mathieu: Agree, need to support multiple cases. Available h/w could determine solution.
    • Bill: Raise discussion after January release
    • Etsam: Another use case, don't want to return buffer when callback is done. Want to hold on until app is done.
      • Ed: Multiplexing w/ asynchronous out of order return buffers.
    • Etsam: May have to retain added information for this
    • Bill: Out of order return not currently an issue, but when multiple channels, buffer underrun can be an issue
    • Math: can impact how queue/dequeue is done and consider bandwidth mgt.
    • Loic: See Bjorn's bandwidth mgt proposal to prevent deadlock/concurrent access.
    • Bill: vring protected w/ mutex's in kernel?
    • mobile rings can send data at same time
    • Etsam: Kernel rpmsg bus driver - buffer is returned. Must consume buffer from within a callback. This may be same for OpenAMP.
    • Math: Agree.
  • Bill: Suman's writeup. Background - on App Services call, it was suggested that providing a socket i/f is good to do. TI has carried a patch - Suman wrote up the status. Loic, had used a variant of the patch as a variant in ST.
    • Loic: Starting point is the code shared by TI. Loic walked thru the use case
    • This was done on 4.4. ST plan to use it today as well. Has been used on docsys platforms.
    • Suman: Shared screen to walk through. Add to notes(?).
    • Loic: One end point per socket is a main difference. Up to Co-P to add on additional.
    • Suman: TI does same thing. Need to connect all sockets to underlying rpmsg device to handle error conditions - had to rely on private feed(?). Right now in band. Application sends/rx on different sockets.
    • Bill: can have 1 vring w/ rpmsg where one goes to kernel driver and one to socket?
    • Suman: 1 virtio ringset. Can create multiple endpoints. A kernel driver can get one endpoint.
    • Suman: In general no limitations - single driver supporting multiple devices. Limitation of three is implementation decision and could be easily resolved
    • Suman: 4 issue -
    • Loic: Need fixed endpoint. This is one issue.
    • Bill: May want a library to support this all.
    • Bill: Still not sure need a socket i/f. Sockets nice but a customized socket doesn't seem wise. Need to evaluate need. thoughts
      • Tomas; Had similar discussion in higher level group. People are familiar w/ sockets, so makes interesting to some. A thin-layer socket on top of rpmsg could also be interesting. Should this be in the application services group.
      • Bill will bring the socket question up in the app services group call.
      • Bill: Nice to use sockets that people understand, but polling loops may be a better solution. Need to evaluate both?
  • Bill: Next call is Dec 19th. Should we have it?
    • Several confirmed presence.
    • Won't cancel
  • Ed: POC patches sent to list by Ben - much appreciated if review and could be an agenda item for next call

2019-11-25

Agenda

  • Brainstorm on carried patches and if we should create a collective staging tree ~ 30 min
  • Discuss CI loop next steps & Bill's feedback ~ 30 min

Attendees

Suman (TI), Bill (TI), Mathieu (Linaro), Nathalie (Xilinx), Stefano (Xilinx), Ed (Xilinx), Tomas (Xilinx), Bruce (Xilinx), Arnaud (ST), Dan Milea, Don Harbin, Kumar (Linaro), Loic (ST), Grant (Arm), Etsam (MGC)

Notes on Carried patches

  • Want to talk about the patches that all the participants are carrying & making more visible to group
  • Idea of creating a staging tree to get it all in one place, don't have to merge together. Unified repo with topic branches.
  • Collect via PR on Github
  • So everyone can see what everyone else has done
    • Tomas: Linux codebase, or other parts?
    • Bill: Is anyone carrying patches for libopenamp?
    • Arnaud:
      • Could create branch in the projects. More for services on top of OpenAMP libraries where we would have to have separate Github project.
      • Rpmessage in kernel part & user.
      • Which version of kernel should we fork from? Latest, stable?
  • Bill:
    • If the goal is just to publish so we can all look, it doesn't really matter. Certainly, you don't want a combined history branch w/ remoteproc changes all intermixed. Hopefully a rebase type branch
    • You raise a good point on the user land apps
    • We could do some of this with wiki pages as well. We do need a wiki page, putting things in context. I can take the lead & create a landing page for this process & post the TI stuff as an example.
    • Should we punt the app stuff to application services group?
  • Mathieu:
    • We should have a reference somewhere so we are not missing a piece of the puzzle
    • If it's too difficult to have branches in the same repo, an alternate would be to post reference most up-to-date
  • Arnaud: Could be nice to have everything in same Github
  • Mathieu: That would be solution #1 & ideal. But if not possible, could post reference in the wiki.
  • Bill: Does anyone have issue to publish content to Github?
    • At TI, I will have to jump through hoops, but will do it
    • Dan: Will have to go through legal, but that's the only
    • Ed: No issue on Xilinx side
  • Suman:
    • Are we talking rpmessage & remoteproc core? I picked up couple of Loic's patches from earlier from upstream that are slightly different from what I might be using.
    • Are we talking all patches, including the drivers? Or, start with rpmessage & remoteproc?
  • Bill: We're not trying to merge them all into a branch. We're just trying to publish branches with our work. Strategy could be different for different companies.
    • I will work with Ed on creating repo & will just be upstream Linux for the moment & we'll work on creating branches.
    • Does anyone else volunteer to stage patches?
  • Ed: There's a PR from Xilinx that's been sitting for about a year. Xiaomi have patches that they have been carrying for a while. Will reply to them on the OpenAMP mailing list & suggest they join this effort.
  • Manju: We eventually want to push to upstream Linux, right?
    • Bill: Right. This is not a product. This is why I’m avoiding merging this together. This is to collect up what we're carrying in the vendor trees. It doesn't change the submission process of sending patches to mailing list. This just keeps things visible.
  • Manju: OK, I'm in sync w/ you there.
  • Arnaud: There are also some patches that are sitting several months/year around zero copy & dynamic services. Would be interesting to discuss here.
  • Ed: That's an area of interest for me too.
  • Arnaud: I can take the point to merge the Xiaomi patches to this new branch.
  • Bill: Let's circle back to libopenamp
    • If you are carrying anything, send a PR, even if you think it's not ready to be merged yet. Like RFC.
  • Mathieu: Would be interesting to create branch names same on lib as on kernel side, so we can correlate what goes with what.
    • Ed: Would be interesting, but being a manual process, a bit error prone
    • Kumar: Both repos would be in Github, so you could make references in the comments of the PR
    • Bill: Let's start each branch name with the vendor proposing it, to keep things simple. Certainly for carried patches, that makes sense. If they're proposals for upstream, you can debate that.
    • Mathieu: Vendor name in there is mandatory. Vendor may have multiple branches & not map directly between library & kernel
    • Arnaud: If we have branch in Github origin w/ name correlating to your feature, so you have company & feature. Both are OK for me.
    • Bill: We can connect dots on wiki if it's not obvious. We'll start there & Mathieu, speak up when you start seeing a problem. Then we can address it with an example in mind.
    • Mathieu: Certainly will. Solution may become obvious when problems do arise.
  • Stefano: Do we want to align on baseline Linux version (e.g. 5.4), or is it free for all?
    • Bill: I think most will prefer 5.4 at this point. But if it takes you 6 months to make it work for 5.4. I'd rather see what you have now & have TO DO item to get it on 5.4
    • Stefano: Sounds good to me. We can make judgement call.
    • Bill: I'll put that on top-level wiki page.

Notes on CI Loop

  • Bill
    • Ed & Manju published a docker file
    • I played with it
  • Ed: I am working with ___ at Linaro to get it into their LAVA framework right now. There's going to be some evolution. I'd appreciate your feedback.
  • Bill: see the write up I made and referenced in meetings notes and email list
    • Manju: If you don't do LAVA, what approach should we be taking as a group?
    • Bill shared desktop with his notes in OpenAMP wiki on CI. Includes items he'd like to see improved.
  • Bill: Want to look at loading initramfs image separately if QEMU loader supports, or have SD or SPI flash image and use that. To be able to build a kernel & get it tested a lot easier.
    • Ed: About halfway done with SD card image support. Need to figure out how to pass that in on command line.
    • Bill: -v and mount par tof the user's home dir into the container & then container looks for certainf iles when it starts up & uses those instead of the ones built into the container.
    • Ed: Also need to work around constraints in LAVA. Will try to get it out soon, but not this week.
    • Manju: SD image for QEMU - traditionally, we had used wic. Need to look into NFS.
    • Bill: I want to be able to put my kernel somewhere & pick up my kernel & we don't touch the userspace very much. Certainly w/ CPIO images, most of userspace is baked in & have dir w/ extra things & CPIO that & tag it onto the other one. Want to make it easy to inject into CI.
    • Manju: Good to know, will play important factor in how we evolve
    • Kumar: When we have something where we test Linux & library or userspace, are we going to have the test as kernel module, or how does that get built & packaged up?
    • Bill: Hadn't thought about kernel modules
  • Bill: My understanding of docker image is that it binds the driver, but doesn't start the R5
    • Ed: Correct, you start the R5 via remoteproc & that's just a matter of how the QEMU is configured b/c that was easiest way for me to test
    • Bill: I didn't see any kernel module to insert to start the test or userspace test application
    • Ed: There is a test application called echo_test. It's a matter of saying echo <name></name> to the right sysfs place. Hm, my README didn't get into the docker image…
    • Ed TODO: Add the README & publish it to the list
  • Bill: The next big hurdle is how to build the R5 firmware image
    • Ed:
      • I'm working on toolkit for that right now. It's 90% there in implementation & need documentation. Uses Xilinx toolchain to build it, but can download all the pieces from the Internet & don't need anything from inside Xilinx network. Tested in a VM not connected to Xilinx network.
    • You could add another dir & build firmware, or extend existing application
    • Targeting before end of year. This week is shot.
    • Bill: I'm not available next week, but if there's anything I could do working with you, I'm happy to
    • Ed: Not until early December
  • Stefano: Should keep on roadmap to have a way to start R5 kernel at boot time with QEMU. Sounds like would make it easier to test different R5 kernels while keeping fixed everything else. Complementary testcase to what you were saying about Linux kernel.
    • Bill: My idea is to inject file for Docker to check what tester is providing & use those. So, work for Linux or others.
    • Kumar: U-Boot? There's presumption that remoteproc is functioning & working.
  • Bill: That touches on another piece of my feedback - can we run 2 R5s in simulator with/without Linux
    • Ed: I believe this can be done, I just need to get the configuration right. Iw as trying to get a QEMU config out there & figure out what peole need
    • Kumar: Can do 2 cortex M but no cortex A, so that would at least get us library to library case
    • Bill: Kumar, is there a wiki page?
    • Kumar: Not yet. Need to finish some other work 1st & touch base w/ Bill to figure out where to put on OPenAMP wiki
  • Bill: We need another repo in openAMP for CI
    • Want to keep big binaries out of that
    • Maybe put prebuilds into a seperate repo (ex name OpenAMP-CI-prebuilt) using lfs git extension
  • Kumar: In Docker image you'd have some OE layer & vendors would provide their BSPs & have that be buildable instead of rootfs images & Docker image could go grab those
    • Bill: There is already a meta-openamp & wonder if expand that
    • Kumar: Sounds like a good place to start

Notes other items

  • Bill: Suman published a write-up on the socket interface that we have for rpmessage. Probably a little too hot off the press to talk about today. Suggest as background reading for next time
    • Suman: Would like to know what other vendors are using, since everyone has different fork of this. Want to know how many variants are out there.
    • Bill: Loic said ST has a version they are carrying.
    • Bill: This came up in app-services call: Interest in socket-based interface. I'll put your write-up on the wiki & cross-post it to both lists.
  • Manju: Ed had posted some RFC about __ and zero copy to OpenAMP Google Groups mailing list. There is architecture document & patch set. Did anyone have feedback on how we should proceed?
    • Bill: Can you re-post to the openamp-rp list?
    • Ed: openamp-rp didn't exist when those patches were posted.
    • Ed TODO: Re-post to openamp-rp list. Work with Ben.
  • Arnaud: Release of OpenAMP - do you have status, Ed?
    • Ed: It's been caught up in lots of things. Little bit of controversy with the Xiaomi patches. Not sure if will make it before end of year…
    • Arnaud: So you want to integrate Xiaomi patches?
    • Ed: There are patches I would really like to see in, but I don't know how to test. They are C++ patches. With all the movement & new mailing list & new structure, hard to keep moving forward.
    • Ed: Xiaomi wants to reinstate zero copy & have some reservations. Not sure how to test C++ patches & haven't heard from anyone.
    • Arnaud: Send to both lists to see if anyone can test.
  • Bill: Think the google group should be dead b/c had issues with the google group list, so don't expect opposition
    • Nathalie: Should send message out to TSC to discuss transition
    • Arnaud: Should also inform the google group members to transition over to the other lists
    • Bill: Will send a message today to TSC about this

2019-11-07

Attendees:

Bill Mills (TI), Arnaud Pouliquen(ST), Ed Mooring(Xilinx), Loic Pallardy(ST), Mark Grosen(TI), Mathieu Poirer(Linaro), Don Harbin(Linaro), Tomas Evenson(Xilinx), Grant Likely(Arm), Etsam Anjum(MGC), Clement Leger(Kalray), Bruce Ashfield

Review Action Items / highlights

  • Topic list edits
  • Status of CI loop documentation published
    • Ed: Hasn't gotten there yet. Still in progress.
    • Target date: two more weeks would be good.
    • (later in the call) Ed: Update on CI loop - a docker container that will fire up a linux and r5 remote proc instance w/ QEMU on dockerhub. Need feedback on next steps. Needs some configuration / scripting to wrap around it. Will add link to wiki under CI loop

Review of Topics list to ask remaining questions

  • Clement: What is the meaning of the spec doc topic
    • Etsam: We had at least two issues while making an independent implementation. Right now somethings are just define via behavior of the current code. Linux kernel behavior changed a while back and broke our system
    • Bill: Yes it would be good to document the protocol in pure form so we are not relying on the lore in the code
  • Bill: Since whole system device tree subgroup, limited focus here?
    • Tomas: Yes, will move focus there
    • Ed: There will be interactions
    • Tomas: yes, some things to standardize on, will tackle here as they come up
  • Loic: Remoteproc drivers contain too many different functions. Some issues in this area. Need to decouple the drivers and handle the virtio part seperatly. Just changes subnode support. One of the problems in 32/64 support. Goal would be to better match other virtio drivers. Work in progress of patch cleanup.
    • Ed: Is this submitted or work in progress
    • Loic: yes, WIP but shown to Bjorn and he was happy.
    • Bill: This is just internal to the kernel right?
    • Loic: yes, that would be the case, you would be able to support multiple virtio links to one processor
    • Bill: One co-processor w/ multiple virtio links is an important use case.
    • Loic: Example, I was challenged why we aren't using virtio console, this would enable that.
  • Etsam: Lifecycle mgt.
    • Etsam clarified this is the same use case as Bill's RPMsg only mode
    • Bill: I thought your topic was about two Linux instances?
    • Etsam, no R5 is the system master, Linux just has to work with RPMsg and we need to do something to replace the Remoteproc layer.
    • Bill to merge sections based on this.
  • Bill: In virtio spec, added virtnet, virtcon, virtblock, etc. Should these be a separate topic(s)?
    • Loic: Need to look at each, why are we doing these? Why use virtblk instead of 9pfs. Why use virtnet just for socket communication?
    • Clement: Yes we share an ethernet port with an MCU over virtio-net
    • Bill: virtionet support would not be used just to get socket-based communication. MCU owns or simulates a ethernet peripheral and we want the Linux network stack to use it as such.
    • Loic: Makes sense. Should be 3 topics.
    • Clement: Have some patches that could be merged for libopenamp.
  • Clement: Currently, we have a gap on 64bit; only support 32 bit so work to do on that.
    • Loic: Do need to consider more than 64 bit topics.
    • Loic: Turn 64 bit into two topics makes sense, resource table expansion w/ back compatibility should be its own topic, Suman for example has added vendor specific resource entries
    • Clement: yes makes sense
  • Loic: Can we share what's available from members so that don't overlap efforts?
    • Bill: Staging tree is already a defined topic. Added this morning. Agree this is important to avoid re-inventing things, but not a blocker (yet). Hoping this comes up as we go thru the details on each topic
    • Envisioned the staging tree populated through pull requests

Top 3 priorities from the team:

  • Loic: ST
    • P1: Secure coprocessor
    • P2: Definition of virtio devices
    • P3: patch for early coprocessor boot. Then attach w/ rpcmsg
      • Bill: Unclear how the variable gets loaded in the patch.
      • Loic: STM32 Coprocessor driver patches on uboot mail list. Using coprocesssor registers to point to resource table.
      • Bill: late-attach means you can keep to firmware or replace it or stop it. Is this what your doing?
      • Loic: yes, plus crash dump yes/no and restart after crash yes/no
      • Bill: the TI use case for preloaded would be Linux is forbiden to control the remoteproc.
      • Loic: Suman has already sent patches for that, These two things can be used together
  • Bill: TI
    • TI Priority reduce patch count
    • P1: Get CI Loop functional
    • P2: Get big data worked out in several use cases. Not worried about cache maintenance yet.
    • P3: IPC only mode - coupled w/ robustness for Linux to recover from coproc reboot and vis-versa.
  • Tomas:
    • P1: CI Loop
    • P2: Ease of use. Docs, porting, etc. Customers noting it's hard.
      • Need to add this as a topic
    • P3: Big Data. One solution is nice, but other use cases need added.
      • Determine if Big Data is a topic for this subgroup or another?
      • Loic thought it should be in Higher Layer, Bill & Tomas that that plumbing should be here and libraries and higher level use cases should be in the other group.
    • Tomas: Since ME's will work on their own stuff, how do we prioritize?
    • Bill: Yes, you are asking what is the point of this exercise.
      • Bill: Linaro resources are coming on board and we need to provide some guidance. Also good to get an understanding from each member so we can better see group commonality etc.
      • Bill: Yes, this is *not* a TODO list for Ed :)
  • Clement:
    • P1: 64bit support
    • (P2): H/W description - removing from this subgroup(?). Yes
    • P2: Virtio spec
      • Have use case of multiple channels. Need multiple communication paths to the same accelerator. (Multi-queue virtio net). Maybe also interested in packed descriptors / vrings.
    • P3: Big Data
  • Etsam:
    • P1: Protocol documentation for rpmsg
    • P2: rpmsg only on Linux side
    • P3: Big Data: zero-copy
    • P4: Late-attach & resiliency

Summary / Wrap-up

Bill: Looking at P's, lots of core code cleanup. Makes sense to do together w/ regression testing. Lots of interest in Big Data. Loic: Need active review on mailing list or nothing will happen. Bill: Yes, Mathieu will help on the reviews, but team needs to be proactive as well in patch review. CI loop will help in this, but still need participation Ed: (Gave update to CI loop edit in above)

Mathieu: Introduction and role overview provided. Ramping up on different implementations.

  • Will offload Bjorn as half of this work
  • Also want to implement some of things that multiple members want
Bill encouraged team to test out Ed's docker work when he posts it. Also start collecting carried patch info so we can start sharing.

Next call should be 2019/11/21. (Bill will be on the road but will join from the car while someone else drives. Should have a backup plan in case there is a wireless deadzone etc)

2019-10-24 First sub-group call

Attended

Bill (TI), Loic (ST), Mathieu (L), Tomas (X), Arnaud (ST), Clement (K), Dan M., Ed M.(X), Maarten K.(WR), Mark G. (TI), Poonam (NXP), Wes S. (X), Stefano S. (X), Bruce A. (X), Manju (X), Nathalie (X)

Proposed agenda

  • Housekeeping details
    • Decide what the group should be called (helps with consistent naming going forward)
    • Get some volunteers for roles (e.g. note taker for future meetings of this work-group, champions/contributors/reviewers for specific topics)
    • Decide if every 4 weeks cadence in this time slot works, or if more calls are needed
  • Review the topics in the wiki list for OpenAMP classic and that were discussed at Connect SAN19 meeting. Rank the different topics and identify those that are applicable to Linux and/or OpenAMP.

Action items

  • Topic owners to fill in their topics on the OpenAMP remoteproc future topics page
    • Bill: Big data, Resiliency, Late attach, IPC only, Communal Linux repo, CI
    • Loic: system resource mgmt
    • Xilinx: Hardware description
    • Etsam: Lifecycle mgmt, Protocol documentation
    • Mark: Discuss with Kumar & post for RTOS side
  • Maarten & Stefano: Let Nathalie know which sub-group is going next Thur at 15:00 UTC
  • Manju/Ed to send mail to list when the "CI in Docker" work is ready for first looks (expected 11/1 ish)
  • Nathalie to post this week's notes & Bill to fill in on wiki (done)
  • Arnaud to publish example pull request to list (done, captured in notes below)

Notes

  • Sub-group name: OpenAMP remoteproc
  • Bill will chair the meeting. Needs a co-chair b/c out sometimes.
  • The "classic" temporary name is because this is where OpenAMP came from
  • Original pitch:
    • Clean room implementation
    • Standardize protocol -> We documented it
      • Want as much as possible to be plug & play and just have virtio as the channel
    • Standardize interface: Kernel, RTOS, baremetal
    • Long list of things that people are interested in. Depends on where ppl have interest & can put resources.
      • How do we test?
      • Code cleanup for ease of use
      • System DT to make it easier to configure both parts
      • Big buffers
    • Concerns kernel & microprocessor part & userspace
      • User space: can do system calls or virtio user space implementation
    • It's supposed to be a wire protocol. Should not need to update both sides. Should work regardless of if 1 side is newer or older.
  • Will Bjorn join call? (kernel maintainer for this area)
    • Tomas asked him at Connect SAN19 & Bjorn thinks he may have some time going forward
    • Loic: Even if Bjorn can't make the calls, if we have community behind idea, can justify on mailing list as having multiple vendors behind it
    • Tomas: Tricky part is here we have cross-functional: have kernel & other parts of project not all on same mailing list. Can discuss more details in call if Bjorn can join.
  • Meeting cadence
    • Bill would like OpenAMP remoteproc sub-group to meet once every 2 weeks.
    • Maarten is ready for 1st higher level services sub-group call. Also thinking every 2 weeks to keep momentum.
    • Stefano is ready for 1st hypervisor interface standardization call to define scope & introduce the effort, but maybe better to wait until have material to show. Not more than every other week. Once a month might be OK.
    • Tomas: TSC once a month. Initially, will be deciding things that board chooses to defer to TSC
      • Loic: If TSC is smaller group, might be OK to do later time that will still accommodate for Europe
    • Decision:
      • Weekly Thur 15:00 UTC is main slot for larger groups
      • Thur 19:00 UTC (the old slot) can be used if smaller group needs to meet & 15:00 UTC is taken
      • OpenAMP remoteproc to take every other 15:00 UTC
  • Bill: Getting all the code in 1 place to accelerate review & upstreaming
    • 1st step in cleaning up a bunch of forks is to put all the stuff in 1 bag to expose it to everyone.
    • Would be good to collect everyone's kernel code into 1 repo, with branch for each vendor, so you can see everything in 1 place.
    • This repo is not to be a product, just to help accelerate upstreaming.
    • Mathieu: Next step, can consider merging some stuff to prep for upstreaming. OK with different branches in common repo. Don't have to merge if not needed. See value in 1 repo & see how things evolve.
  • Bill: Future topics
    • From Connect SAN19 meeting topics: CI is really important so ppl can reproduce
    • Wiki page of future topics is a good outline, but not a lot of detail here.
    • Action for the following owners to update future topics page - Link to presentations from the past, Update the text on what this topic is about & what you're hoping to get out of it (loosely, but not exactly, "requirements"). Objective: someone coming in cold can understand what the topic means.
      • [See]
  • Tomas: How do we get better documentation around how we use & set up OpenAMP and put it in the open?
    • Mathieu: For someone coming from the cold: Would be good to have a "How to" with a board that has the components open & hello world message passing example & capability to re-compile & re-install everything.
    • Tomas: Agree. Issue is that it's different across vendors. Trying to harmonize with System DT.
    • Arnaud: Saw PR on Zephyr a few months ago related to rpmessage. May be good starting point for co-processor. In review by Kumar. Could be a simple sample to help see how things work.
    • Bill: That's why was pushing for CI. If can do it in CI, can do it in lots of places & it works.
    • Ed: Targeting end of October: a basic Docker container w/ toolchain (Yocto flow) & Xilinx QEMU, incl. generation for R5. Incl. Xilinx github repo as example. Hello world between linux & R5 with baremetal
    • Manju: Will have to generalize further for other vendors on how to use meta-openamp & how to use Yocto to build the binary.
    • Bill: That's a major step forward to see it on 1 platform, then everyone can figure out how to generalize on their platforms
  • LITE sprint was in Mid/end June in Austin
    • Most ppl did MCU Zephyr topics. Ed & Bill used that time to make progress here but did not get as far as they wanted.
    • If we want to do an OpenAMP remoteproc sprint, could do it independent of LITE. Would want ST to be able to join.
    • Loic: Think need to decouple OpenAMP remoteproc from LITE. It was there b/c Xilinx in LITE and wanted to have integration with Zephyr. But related to co-processor mgmt, not linked to Zephyr, so good to decouple.
  • Manju: Know many different build systems. Will Yocto Project instructions work for everyone?
    • Loic: Yocto is 1 option. For development, bitbake is taking time to compile all the modules.
    • Mathieu: Separate compilation mech from distribution makes it easier for ppl to integrate into their flow.
    • Bill: Most important is to publish 1 example that works in any platform in any distribution in any makefile. Then can simplify build flow in the generalization process.
    • Loic: Agree. Also OpenAMP userspace w/ application on top.
    • Bill: Don't worry about explaining how to build Xilinx QEMU if not using Open Embedded. Won't be changing that every developer compile.
    • Mathieu: Agree having 1 example is a huge step forward from nothing at all. Point was for working towards what kind of environment we want.
  • Loic: How to progress on list of topics? Fill in topic descriptions & draft list of tasks for each topic. Will need to define priorities to figure out starting point. Think this list is 2-3 years of work.
    • Bill: That was my purpose for collecting owners for the topics. Prioritization will be harder & have to tackle that together when we meet. Everyone should come up with their top 3 list.
    • Loic: Don't yet have common git. If anyone has internal solution existing, share
      • Bill: First step would be to provide links to your repos
  • Role: Notes & organizing calls
    • Tomas: Nathalie can help the sub-groups get off the ground, then to scale, each sub-group should become self-sufficient
    • Nathalie to post this week's notes & Bill to fill in on wiki
Add a custom footer
Add a custom sidebar
Clone this wiki locally