OpenAMP remoteproc Subgroup Meeting Notes 2020 - OpenAMP/open-amp GitHub Wiki

Table of Contents

Introduction

This sub-group covers areas such as remoteproc, rp-message, virtio, big buffers, etc. The meeting cadence is every 2 weeks on Thursdays at 11am Eastern US time.

2020-12-31

no meeting

Next meeting will be Jan 14 2021.

2020-12-17

no meeting

Called off after 10 mins for low attendance. Mathieu Poirier (Linaro), Arnaud Pouliquen (ST), Ed Mooring (Xilinx), Bill Mills (Linaro),

2020-12-03

Attendees:

Mathieu Poirier (Linaro), Arnaud Pouliquen (ST), Ed Mooring (Xilinx), Bill Mills (Linaro), Suman Anna (TI), Loic Pallardy (ST) Ben Levinsky (Xilinx) Etsam Anjum (Mentor),

Topics for Today?

  • Kernel & Lib Updates as usual
  • Investigation of Ease of use
  • Documentation

Kernel Update

  • MP: 3 things on my radar
    • Greg on TI's PRU work (backed by Suman)
    • Ben's Xilinx R5 work
    • Detach work, Rob does not like description of binding on MCU sync
  • AP: working on next version of rpmsg control
    • this version reuses existing rpmsg char device
    • (discussion AP & MP about staging the functionality to patch series)
  • SA: sent two series
    • in kernel API to set firmware name
    • rproc state machine control patch that MP suggests something else
    • SA: upcoming patch series
    • rproc handle exclusive or not?

Library:

  • AP: zero copy
    • discussion w/ Kumar, he thinks it is OK
    • starting to integrate and test
    • EM: Ok as long as tests OK
    • AP: found some tests gaps and addressing
  • AP: libmetal
    • new platform: mediatek i500
    • new arch extensa
    • proposed tests, can't hand that right now
  • AP: cleaning up some github issues
    • related to old implementation

Ease of Use

Documentation

  • Need getting started guide
  • Doxygen comments need to be updated to match the new code
  • architecture & protocol stuff is out of date and hard to find

2020-11-19

Mathieu Poirier (Linaro), Arnaud Pouliquen (ST), Ed Mooring (Xilinx), Bill Mills (Linaro), Suman Anna (TI), Etsam Anjum (Mentor), Loic Pallardy (ST) Stefano Stabellini (Xilinx) Ben Levinsky (Xilinx)

Other People mentioned

  • Guennadi Liakhovetski (Intel), virtio audio using rpmsg
  • Bjorn Andersson (Linaro)

Topics for Today?

Library:

  • EM: Pull requests from Xar inc zero copy
  • AP: request KG to review also
  • EM: Looking at ease of use, target next meeting for presentation
    Master thesis
  • AP: Push patches to compile, using ARM cc and IAR compiler

CI

  • no update

Kernel Update

  • MP: Busy 2 weeks
  • MP: Not reviewing everything
  • MP: Alexander fixing DMA problem, Christ Dahl says we are abusing DMA API.
  • AP: To really fix CD's concern we would need to break legacy
  • MP: breaking legacy is not acceptable, but need a way forward
     kernel device to kernel device DMA parameter passing
     Does not like inheritance of DMA properties from kernel device to kernel device
  • LP: DT describes the super set of carve out and mailboxes
  • AP: Allow rpmsg node w/o rproc node.
  • MP: Name service modularity is first step in breaking up the big patch series
  • AP: I think I have added reviewed by for outstanding
  • MP: Still working with AP on bindings for detach etc
  • MP: Need ack from Suman on Tony Ling "drop platform native" drop HWMOD
  • MP: Gregor TI PRU
  • MP: Rashab add trace events to rproc core
  • MP: Google is fixing mediatek stuff

Roadmap

  • Detach is done
    • w/ crash recovery and core dump
  • Robustness
    • apps know when crash and backup
    • restart via udev or remoteproc chardev or just poll
    • documentation
    • example
    • rproc uevent? does not exist?
    • rpmsg EP uevent? poll?
    • RP knows when app dies
  • Big Data
    • using pre-shared mem carves outs buffer sharing
  • QOS?
    • virtio level?
    • TOS?
  • Linux as client (vhost)
    • Guennadi KVM for sound
    • Etsam two Linux guests under common hypervisor
    • Smaller core is master /
  • Documentation

2020-11-05

Attendees:

y Mathieu Poirier (Linaro), y Arnaud Pouliquen (ST), y Ed Mooring (Xilinx), y Bill Mills (Linaro), y Suman Anna (TI), y Etsam Anjum (Mentor), y Loic Pallardy (ST)

Other People mentioned

  • Guennadi Liakhovetski (Intel), virtio audio using rpmsg
  • Bjorn Andersson (Linaro)

Topics for Today?

  • zero copy in open-amp
  • detach bindings in kernel
  • roadmap status

Library:

  • AP: Want to discuss zero copy, w/ a little size increase 200 bytes, 10% increase
  • AP: Looked at Macro to make conditional but it only saved 100 bytes. Not worth it
  • BM: I thought we closer to 4K
  • AP: I have details here:
  • AP: I'll ask Kumar Gala's opinion
  • EM: No process for API's added
  • AP: Zephyr produces a document at release with Deprecated, Modified, Added APIs
  • AP: Zephyr wants to add RPMSG manager: for ease of use lib and thread context
  • AP: Next release is April '21
  • AP: only other things are bug fixes
  • AP: new option to wait for other side?
  • rpmsg: wait endpoint ready in rpmsg_send
  • BM: EP announce is not strictly required, user should have to opt into that

CI

  • no update

Kernel Update

  • MP: working on two patch sets:
    • name space modularity
      • Guennadi wanted a header file moved and I have done that
      • should be ready to send the next rev
    • detach
      • I believe things are in shape from a functional POV
      • Probably some discussion is going to happen on bindings and names
  • MP: DT Bindings for detach (& crash)
  • MP: R5 from XIlinx, waiting for Ben
  • MP: Qualcomm ?? Bjorn is already handling
  • MP: Name service modularity: Gnotty asked me to move a header and have done that
  • MP: really want feedback on the bindings I have in the patch Services

Other items

  • EA: Lots of features were discussed in the past
  • BM: Lets groom the backlog: next 6 months, 6 months after that
  • EA: Very interested in Linux on both sides of the link
  • EA: Interested in Zero-copy
    • BM: Including Kernel / User space? or just the open-amp lib
    • EA: yes we tried but did not really increase performance due to increased MMU / syscall overhead
  • EA: Proxy work: App Services
    • BM: Agree, the proxy use case work is being addressed by App Services group
  • EA: Use buffer chaining to support larger direct payloads
    • BM: Many of us have been advocating the Pass by reference model w/ pre-allocated large shared memory
    • BM: Guennadi is using larger direct buffers for audio, so would be interesting to get feedback
    • AP: We use shared buffers w/ DMA for audio
    • AP: reference is by offset into per-allocated memory
    • AP: RemoteProc is doing some data tweaks on buffers and kicks off DMA to HW
    • LP: The ST wiki has a lot of detail on what we are doing:
    • LP: This is typical for customer requests, want three tiers
      • super easy: tty, development and control
      • more complete raw rpmsg from user space, being addressed by Bjorn's work
      • big data, pass by reference. Used by kernel or by userspace
    • EA: Are we saying to only use the rpmsg for control messages? If so then big buffers in rpmsg is out of scope.
    • BM: I think we will evolve to allow configurable buffers sizes and count
      • Instead of supporting buffer chaining, we could just allow a big buffer pool and a small buffer pool
      • Much simpler model and does not waste as much space as having all buffers the same size
    • EA: chaining is supported in base virtio and might be used by virtio-net, *-blk Exchanging_buffers_with_the_coprocessor
    • BM: true if we need to expand the library to do chaining for app services then lower barrier to use in rpmsg

2020-10-22 (1st draft)

Attendees:

y Mathieu Poirier (Linaro), y Arnaud Pouliquen (ST), y Ed Mooring (Xilinx), y Bill Mills (Linaro), y Stefano Sabellini (Xilinx), y Suman Anna (TI), y Etsam Anjum (Mentor), y Clement Leger (Kalray), y Loic Pallardy (ST) y Ben Levinsky (Xilinx)

Other People mentioned

  • Peng Fan (NXP)
  • Guennadi Liakhovetski (Intel), virtio audio using rpmsg
  • Bjorn Andersson (Linaro)
  • Alexandre Bailon (Baylibre)
  • Pi-Hsun Shih (chromium.org)

Library:

  • AP: plan to do release this week,
    • no new features as discussed last time
    • some bug fixes, new cmake required
    • Fixed CI for compliance (checkpatch, etc) & build test
      • Linux user space, generic ARM, generic ARM FreeRTOS, and Zephyr
      • Zephyr build : NXP espresso, ST MP1 board, should be able to test on real HW
  • EM: I did the branch and drafted the release notes should be ready to go tomorrow

CI

Nothing new

Kernel Update

  • MP: Couple of new patch sets for review this time
    • Alexandre Balon: Mediatek mt8183 APU AI remoteproc,
    interesting, needs more followup by Alex
    • Pi-Hsun Shih: Mediatek fix for mt8192 SCP remoteproc
    • Peng Fan (NXP): i.MX8MQ needs follow up from Pang
    • Ben: Xilinx R5, looking for Stefano's OK before MP looks at it.
    • SS: Looks ~ correct, will have some style comments
  • MP: Patches for name service modularity
    • OK from AP, Need Guennadi to look at new version
  • MP: Detach patch new rev coming, push mechanism config to DT
    • Peng: did review and seems OK from his use case POV
  • BM: Any other reviews? Xilinx?
  • MP: 5.9 can attach to running proc, this new work allows you to stop or Detach
  • MP: Who becomes the lifecycle owner after the detach? Now moving this to DT
  • MP: Should be pretty small
  • MP: V2 should be out by next meeting
  • BL: are we looking for convergence in driver level?
  • MP: no, but if you could follow the TI R5 pattern that would be great
  • BM: Any other openAMP?
  • CL: Have not done much recently, what is there is working for our use case
  • MP: Are you needing / wanting 64 bit?
  • CL: Would be nice but we don't have the priority right Now
  • SA: I need to do V2 of 64 bit C7x
    • DT nodes pending, IPC only mode is needs to be done on upstream,
debug trace needs 64 bit
    • ELF64 is already done
    • vdev already supports 64 bit
    • other resources don't need 64 bit right now because using fixed carve outs
  • SA: R5 binding? Rob has deferred to Borhn, should apply to TI and Xilinx
  • SS: Today's call is on another topic but might be able to discus

Other items

BM: SystemDT directly after this call

2020-10-08 (very rough draft)

Attendees:

y Mathieu Poirier (Linaro), y Arnaud Pouliquen (ST), y Ed Mooring (Xilinx), y Bill Mills (Linaro), - Dan Milea, - Stefano Sabellini (Xilinx), y Suman Anna (TI), y Etsam Anjum (Mentor), - Poonam (NXP), - Bruce Ashfield (Xilinx) y Clement (Kalray), y Loic Pallardy (ST) - Nathalie Chan King Choy (Xilinx)

TSC topics

LP: How are the work groups linked? LP: SysDT seems natural LP: App Svc is less connected

    Want to expand to include rpmsg as well, not just bare virtio

Next 6 months / Next 12 months:

  • continued upstreaming of vendor patches
  • name service extension finalization
  • Detach model upstream
  * Possible protocol changes to support this fully
  • CI
  • rpmsg char create / destroy channels from userspace
  • rpmsg tty

Next 12 months:

  • Robustness
  * Restart / resync to peer on peer restart
  • Big data demos
  * via preshared memory
  * via allocated memory 
    * CMA/ION
    * Paged

Library:

EM: Putting the 2020.10 release, mostly bug fixes EM: Zerocopy is not in yet, still pending based on issues: EM/AP: adds 30% in size, 5K to 8K, no way to test BM: It is fine for you to define the requirements to be merged AP: Starting work to deprecate some parts of the API AP/EM/BM: 2yrs makes sense EM: The full support for C++ is still pending, some fixes

CI

Kernel Update from Mathieu

  • vhost /
  liked Kishon vhost RFC better than Gnoty, MP, AP, Vincent Witchchurch? (virtio contibutor)
  • Mediatek driver
  • Modularization of rpmsg (for better vhost compatability)
  • Detach V1
  * 
  * Hope for V2 work
    * Use DT to dictate policy for rproc stop/restart
  * RPROC starts itself will reannouce EPs etc
  * Linux starts but detach so it can outlive Linux
  * SA: pretty similar to removing rpmsg module and reinserting
  • R5 driver
  * SA: Rob came back, still has reservations, ok if Bhorn wants to take it
  * EM: Agrees that is the state, don't understand the SysDT concerns
  * EM: TCM is managed very different between Xilinx and TI
  * SA: In TI TCM is part of R5 SS, In Xilinx TCM is chip level mapped to TCM mailbox
  *     num mailboxes etc are different
  * EM: Hoping to follow TI
  * AP: No pressure to allign to common M4
  * LP: NXP has M4 w/ bindings very different than ST
  * LP: The way Rob is pushing it seems he wants a common driver
  * SA: reset driver, syscon reset, Rob said: different binding but same driver
  * AP: Thats what we tried to do in with carve out memory

2020-07-02

Attendees:

Mathieu Poirier (Linaro), Bill Mills (TI), Dan Milea, Ed Mooring (Xilinx), Stephano (Xilinx), Suman Anna (TI), Etsam Anjum (Mentor), Poonam (NXP), Arnaud Pouliquen (ST), Clement (Kalray), Loic Pallardy (ST)

People referenced in discussion

GL: [email protected]

CI

  • EM: LITE virtual sprint, spent most of my time updating LAVA and docker, still working on simplifing Xilinx build process.
  • BM: what was the context
  • EM: updating debian VM to do this work LAVA & docker, still targeting Xilinx QEMU then Ultra96
  • EM: CI is still priority for me
  • EM: currently doing Yocto build of world

Library:

  • AP: Not much, some discussion on cmake (would require newer min version)
  • AP/EM: 3.5 suggest

Kernel Update from Mathieu

  • MP: helper function from Suman, OK now
  • MP: GL has patch that uses host API that makes sure endianness matches host processor
    • AP: Have tested on ST platform, would be good to test on BE
  • MP: 10 new patch sets have shown up
  • Bjorn
  • Rashhab extend
  • glink & rpmsg
  • vpoc: signal API to rpmsg-char (may be glink specific)
  • vpoc: use signal API
  • Rashab: enhance coredump, v6
  • Suman: K3 R5F
  • Prepare/unprepare
    • Move what Paul had done to prepare/unprepare
    • SM: Bjorn picked it up, its on rproc-next
    • MP: Now this is done we can move fwd with MCU sync
  • CB mod MFS on qualcomm
  • Kishon, beefy patch set for rpmsg between host over PCIe, vhost NTB PCIe NTB (Non-transparent bridge)
  • LP: A lot of qualcomm patches get merge w/o multi vendor discussion. Need to get more discussion
  • MP: need to align on roadmap

Other items

  • MP: Ed, how is the openamp documenetation? People are asking me
  • EM: Its on the todo list, user docs are needed

2020-06-18

Attendees:

Mathieu Poirier (Linaro), Bill Mills (TI), Ed Mooring (Xilinx), Stephano (Xilinx), Suman Anna (TI), Etsam Anjum (Mentor), Poonam (NXP), Arnaud Pouliquen (ST), Clement (Calray), Loic Pallardy (ST)

Library:

  • AP: no big update today

CI

  • EM: Working on CI in Linaro LITE this week
  • MP: It would be nice to have CI for kernel side also
  • EM: LKFT may be doing some of that
  • BM: What are you trying to do in your CI
  • EM: Trying to test Xilinx R5 (will generalize to others later), get building first
  • EM: After get working on Xilinx would like to see working on other devices
  • EM: Using LAVA as framework today and Linaro has collection of Xilinx, ST, and NXP (also TI BTW)
  • BM: What would be target platform for NXP
  • P: Currently a layerscape device with multiple Cortex-A but we should be looking at a device with Cortex-A + Coretx-M or Cortex-R
  • EM: It will be a while yet, still working on getting build simplified, currently build uses lots of Xilinx tools & frameworks etc
  • BM: What exactly are you doing?
  • EM: Build on QEMU Xilinx first, then Xilinx HW, Build for R5 baremetal or FreeRTOS, and test against Xilinx vendor kernel
  • EM: Hope to get upstream kernel once the Xilinx R5 driver gets upstream (being worked by Ben)
  • MP: Really good to get even this level as it enables others to get do the work for thier platforms
  • MP: Would be good to have golden images for the RTOS side for kernel testing
  • EM: Want to test Linux userspace open-amp also
  • MP: need some CI due to the patch volume
  • AP: what do you want to test? We need to test some services. Need some specific kernel drivers as modules
  • LP: there is already some tests in kernel, maybe not enough but it should be common to all
  • AP: Yes service already exists in Zephyr could be adpated for baremetal and FreeRTOS
  • MP: Yes something simple would be enough for now
  • MP: Example, the endian handling stuff on list, for now need lots of tested-by signoffs but CI would help offload that
  • P: What HW would you like?
  • BM: What is your interest?, A<->A, M/R<->M/R are possible but most common is A<->M/R
  • MP: check with Peng Fang, what is his use case
  • P: We are doing A to A using Linux <-> U-boot
  • MP: Would like Peng's feedback on mcu sync patchset that is on V6
  • P: Maybe we can do presentation next week. We wanted to talk about rpmsg-lite also
  • P: Looking at LBI-21 in Linaro looking at robustness
  • MP: yes plan on working that but right now we are just working on the first step, rpmsg working with processor preloaded rproc

Kernel Update from Mathieu:

Pre meeting start

  • MP: some work on tty and rpmsg with ST
  • BM: I think tty is a great use case to prove rpmsg
  • MP: yeah but ST's version has made it very ST specific, hope to rework that some, may align

Main meeting agenda

  • MP: Bit quite due to kernel merge window
  • MP: Reviewing Audio between hypervisor and guest using rpmsg
    • Author knows that changing message size and number for everyone would break things, just want to get the RFC out, MP has suggested an approuch
    • Endian is being specified as always LE to match virtio spec
    • BM: This is good to get specified and probibly OK as most people are uisng LE today. Is anyone using big endian??
    • BM: Is microblaze always LE?
    • EM: No can be both. But don't use rpmsg for microblaze today (at least in main product)
    • BM: Estam do you use mixed endian?
    • EA: no big nedian
    • MP: What about Calray
  • Clem
    • P: NXP P220 would be powerPC BE but not using rpmsg with that config
    • EM: Wondering about PowerPC Xilinx, but would not be up to date kernel
    • AP: Should we define endian for the payload also?
    • EM: should not assuming anything about payload
    • BM: defined messages like name annoucment etc should specify endian
    • AP: so we can't use BE <-> LE?
    • BM: no it can be handled but should be up to the application to define the method, fix it at LE makes sense and should probibly be recommended approuch
  • MP: Working with Ben on Xilinx R5
  • MP: patch from Clement fixing memory leak
  • MP: Suman patches C66 and C71
    • SA: Just waiting for Rob for bindings on C66
    • SA: Need MP review on "helpers", will send e-mail ping on excatly the patch
  • MP: new rev of name extension, should be ready
  • MP: endian "conversion" patch
    • Need tested by from everyone
  • SA: Want to discuss Ingenic driver from Paul
    • first non-ARM platfrom, using MIPS platform that does not use PM runtime
    • got pointed to old patch for prepare/unprepare
    • MCU sync series does not have this and will need rebase
    • MP: surpised that Bjorn picked up patch and the problems it caused
    • MP: you want me to clearly suggest how to proceed
    • SM: Yes, currently we have basiclly two PM states, one in RP and one in PM RT, not great
    • MP: will reread again and suggest way forward
    • SM: have patches to fixup every other platform if we keep current structure
    • SM: We have auto suspend feature that this breaks
    • LP: prepare/unprepare was refused by Bjorn before so we found other ways, a bit funny that he picked it up now. Original idea was to power the core & memory not start the core. Can still be useful for crash case etc. Now we are doing prepare in platform specific load functions.

Other items

  • Mathieu suggested we publish the recordings
    • right now they are private to Bill for use with notes

2020-06-04

Library:

  • Ed: Working thru pull request backlog. An old issue pr 169 - NXP introduced zero copy implementation of rpmsg in 2016. Xamei wants to re-introduce. Add ~6 new API's, thus should be made at an expanded level. Not sure why the API's were removed.
  • Bill: Done in code size reduction efforts
  • AP: Agree. The feature is useful. Does increase footprint to 0.5 KB.
  • Ed: It uses reserved fields to carry pointers - makes me nervous.
  • Bill: If reserved becomes unreserved, problems followed.
  • Ed: Skeptical of overall utility since using the same buffer space. Apparently Xaomi has a use case for this implementation.
  • AP: Could have another solution - not release virtio buffer itself. If use reserve field, then tomorrow it evolves, we would have to adapt the protocol and can propose something else.
  • Bill: Agree finding solution at VirtIO level is better. Thoughts?
    • Silence
      • RFC patch for audio over rpmsg changed buffer numbers and size?
  • MP: Noticed. Recommend making this configurable.
  • Ed: Keeps coming up.
  • MP: Two variables. rpmsg to communicate between host and guest, so can tell them to use whatever size they want if configurable. Per Eds comment, changing # of buffers between host and ? which is different.
  • Ed: Missed the distinction. Also an issue that comes up periodically - kernel implementation & user space implementation - how closely should these be tied together?
    • Kernel or MCU user space?
    • Ed: Both. Still in realm of rpmsg, but out of scope of kernel rpmsg. Number of proposed extensions that could be done in kernel or user space. Need to decide how we want to keep aligned.
    • Bill: Answer: Library and kernel must be interoperable, common features remain interoperable, ?. Shouldn't hold one up for the other. example - audio use case - rpc breaks use case. kernel to kernel can do something different.
    • Ed: Will add note to docs. Really want to get this out there for approval.
    • LP: The size of rpmsg is fixed by virtio layer - for QC implementations, they do it differently, we need to get the app level size of buffer. A patch needs a user to integrate. Have to be independent from the way we send rpmsg - must be able to get the size. Need to be aware at user level.
    • Bill: Where are tty/rpmsg patches?
    • AP: Today, Bjorn wants tty in sha driver. Not aligned atm. Don't want to advance until find common solution.
    • Bill: Have a use case and current solution somewhat of a hack. Going thru tty system is pure overhead.
    • LP: Multiple use case requests from customers. Need to address different flows.
    • Bill: Even when using complex s/w w/ pipes, a simple debug console is important.
    • LP: Yes, and virtio console important(?).
    • Bill: Don't want disk/rpmsg, but tty needs the extra effort.
    • Clement: Not doing network control / rpmsg. A side channel on rpmsg instead. Data over the network. rpmsg used to send declaration of network devices.
    • Bill: Thought tty driver was using get message size and would now also use wildcarding in pinpoint name. Might be good example
    • AP: Yep could be. Would be interesting to have simple client that user can get on to status project w/ co-processor. Today it's missing. Linux today doesn't have a way to use it. May have to modify sha driver. Something missing at service level in rpmsg protocol. tty is one solution, a better one?
    • Bill: would like driver to be subtracted decode.
    • AP: Would be nice to comment on the series.
    • MP: Last time checked, thought a conversation over maillist w/ Bjorn - was Bjorn reply still need clarification?
    • AP: Replied to Bjorn, did I miss a message?
    • MP: Will research and forward Bjorn's answers in the list. Thought it was closed.
    • Bill: Bjorn proposed merging rpmsg into character driver, not sure like
      • LP: Schedule Bjorn call?
      • MP: Or ask Bjorn to join this call bi-weekly?

Kernel Update from Mathieu:

  • MP: Nothing controversial on ML. Patchset sent out were later revisions of existing sets, so a bit easier. 2 patches from Suman, all asks were there. Bjorn and MP have acknowledged. Bjorn sent out v6 of loader. MP +1'd. Vhost rpmsg API introduced by Gennady - 1st patchset is not controversial - just some refactoring. He is changing number and size of buffers for guest interaction which will require revision - will let him know what needs to change today. MP sent out new revision for remote P, started by bootloader a consensus reached w/ Bjorn. Both TI and ST looking to address this.
  • Kernel can start remoteproc
  • Bill: TI wants to prevent kernel from changing remoteproc state
    • MP: Pushed out to later revision of patchset after easiest use case was handled. Looking for reviews. Need solution for core part prior to expanding to other use cases.
  • MP: Last item: Ben's new spin on Xilinx for r5 processor - will start review today or early next week. Support for name extension in rpmsg protocol - Bjorn has asked for examples, need Suman's input. AP provided his.
    • Suman: will do that.
  • Suman: System DT. Rob involved asking about bindings. Do we know where we are with respect to this?
    • Bill: Ben's response spot on - System DT will take months, so get basic support in and then enhance.
    • MP: will continue to review and push forward Ben's work vs waiting for System DT.
    • Ed: Ben, Stefano and others discussed - Ben wrote on advice of those doing the work since he won't be ready externally for several months. May not be many Linux DT changes anyway.

2020-04-23

Attendees:

Don, Bill, Mathieu Poirier, Suman, Arnaud Pouliquen, Clement Leger (Kalray), Ed Mooring, Etsam Anjum, Rishabhb( QC)

Agenda:

MP: Kernel patch status updates

  • MP: Wang sent patch to invent new remote process monitor, haven't looked at, it's large, Bjorn suggested it should be in user space - not sure how will advance
  • MP: QC driver submissions - to be handled by Bjorn
  • MP: Arnaud patchset (decorolate virtio from core) that splits into Core. Allows vdev to be specified in device tree and adding more flexibility.
  • AP: Also includes adding some to ? to start before firmware.
  • MP: Agree - lots in there.
  • AP: Consider rework remoteproc virtio to make it a sub device(?) and how devices are managed.
  • MP: Discussion will be good, patch itself are so heavy it may make it hard for reviewers to review. Suggest cleaning it up and split up patchset to get people to review - have already spent 6 hrs and only up to patch 5.
  • AP: Lots of correlation - will investigate splitting it up.
  • MP: Can't advise - would take 2 weeks to look thru it all - recommend AP does best to break it up as he sees best
  • MP: Have made some comments, but plan now to move to other patchsets and await AP revisions
  • AP: Taking into account can probe everything at the same time. Want every subdevice probed for resources - if ok, start firmware. Took the implementation basis from DRM drivers.
  • MP: Rishab sent core dump patchset. Suggest this get reviewed - it impacts how things are done and modifies Core. Approach hasn't changed much. MP to review in a few days, would like others to review
  • MP: Sumant prepare/unprepare operations - should merge quickly. Bjorn has merged.
  • MP: Sumant - restore memory pool. Back to how it was in first version. Based on all requirements, not a bad compromise. Please review and comment if concerns.
  • AP: This looks ok to me (AP). Want to have capability to have large memory region for everything. Considering Audio use cases.
  • MP: Ben (Xilinx) - 3rd revision for R5 processor, Bjorn to look at, MP will look at later. Also some QC platform drivers. Would like QC to review these to make sure it is working properly.
  • MP: Currently looking into 2nd patchset from TI - also want to start addressing QC core dump patches.
  • Rishab: Sent character driver patchset. MP: Agree and plan to review in coming days.
  • AP: re Name Service to have extension to the service. Considering a template, any opinion?
  • MP: Haven't thought about, but isn't channel name the same as the part? Have to work on synchronization patchset first
  • MP: also want to follow thru with Bjorn's ideas, but want to get MCU Sync patchset out, then expect to be more involved in other conversations.
  • AP: will discuss TTY with Name Service Resolution patchsets later for review.
  • Suman: Cleanup patchset function rproc is in so can move forward from this.

Library updates

  • Arnaud: Prepare release of the OpenAmp limiter(?) library. Pull requests to update readme submitted. Added some How-To's. Attempted to update Travis.
  • Arnaud: Members of OpenAMP -
  • Bill: Agree TSC instructions.
  • Arnaud - how to follow requests for each release?
    • Can we track issues across repos?
    • AP: Yes can do this along with a simple Kan Ban. Can track project to do list etc. Might be nice to use.
  • AP: Check patch integration w/ status is working. Build check on OpenAMP is missing. Tried Git Lint integration.
  • Build tests will have to wait?
    • AP: Yes. Travis is working on generic Linux. What is missing is list of reviewers - just Ed and AP today, need more to assure compatibility.

Other Topics

  • Bill: Note on conferencing. Use Zoom today, aware of policies. If anyone has concerns, let Bill know. Bill's accounts won't route through China, could add passwords and waiting rooms. Could also do webex.
  • Bill: From TSC. Asking each subgroup to lay out 6 month plan. Shared goal of getting through technical debt backlog. Not sure will get through it, but that's the focus. A 1 year plan may include additional items. Like big data or robustness. Please share thoughts to the list. Bill would like to work on top down use cases to evaluate what kernel drivers and applications should be able to do. Attempt to find gaps from this analysis. Character device for remoteproc is a good example.
    • MP: We have some bottom up vs top down examples. Some bottom up may not be implemented optimally, won't know until get down the road, so should expect some rework based on this. Consider this an acceptable risk. The top down will likely make some of these issues more apparent. Also agree that removing technical debt is what needs to be the focus.
    • Bill: Need to have a way to test patches we're accepting is important. MP: Agree

2020-04-09

Attendees:

Don, Bill, Clement Leger (Kalray), David Kauschke, Etsam Anjum (MGC), Mathieu Poirier (Linaro), Suman Anna(TI), Arnaud Pouliquen (ST), Ed Mooring (Xilinx), Siddarth Gupta (QC), Rishab (QC),

Minutes:

Kernel Patch Status - Mathieu

  • Thought there hadn't been much movement yesterday, but 2 new patchsets this morning. Will be adding to review list. Both are second revisions.
  • TI - 3 patchsets. K3R5F almost done reviewing. Other two will start reviewing next week, but could take a bit
  • Conversations over previously reviewed sets. Have a plan for wildcard handling.
  • Loic sent crashed recovery - enough to move forward?
    • Loic: Enough to work with Arnaud. Proper shutdown of processors still being considered
    • MP: 2 other patchsets 1) Coredumps handling (Rashab) 2) Application crash handling or remote processes. Bjorn and MP have reviewed. Ready for updated patchset. Loic and Arnaud - would like to chime in for recovering crashed P's.
    • MP: Will come out next week with MCU Sync comment updates - most items have been addressed.
  • Alex has cleanups on MCU sync series.
  • MP: spin off patchset next Monday to make easier to review. Asked for MCU comment clarifications. ACTION: Suman to respond.
  • remoteproc character device
    • Arnaud asked Bjorn how to move forward based on comments. MP knows his own view. Could reply to list.

Library / CI Updates - Ed

  • Arnaud and Ed need to sync up on content on the release. Arnaud put up more checkpatch and CI content, Ed working thru this. Big one for next release is Test Suite and docs for zero copy bits.

CI update

Character Driver for remoteproc - Bill

  • MP: Move forward w/ Clement patchset. Add rpmsg to tty support. Bjorn would like that to be integrated w/ current upstreamed rpmsg driver. Has died since. MP has come up with another idea. May be best to move onto maillist so that Bjorn can see, but in meantime:
  • Bill: Still need to understand more. Open bound to boot and closed bound to shutdown seems problematic due to interactions with other components and state mgt.
  • Clement: PLE's (???) I/F not filling the gaps. Need to tie app to remote processor.
  • Bill: remoteproc App could get notified not running anymore as an option
  • MP: QC use case wanted app sync'd w/ remote processor.
  • Rishab: QC needs closed to shutdown to sync w/ Application. Need that mapping at a minimum. Open to boot - could do something else on that side.
  • Bill: would a message be sufficient to shutdown?
    • Rishab: Don't have i/f for remoteproc to decide so would be sufficient.
    • MP: Would have to resync on App Processor.
  • Bill: Moving boot to ioctl is one hope. How would work with Autoboot?
    • ....other details discussed I didn't catch...
  • Clement: Single use i/f. If open, no one else could open. OpenCL framework, when App starts deploy runtime(?) on remoteproc. Didn't expect access from others - may not be the case.
  • MP - A good idea to make platform vs core specific
    • Bill: platform and core aren't use cases
  • Exclusivity
  • Move boot to ioctl?

other topics

  • Bill: Do companies have sysfs test scripts that could be shared?
    • Suman: TI only use for stress test. All autoboot and autorecovery, so for most part, Apps not responsible for booting.
    • Loic ST: Sysfs used for testing, start and stop. Up to customer - not using autoboot typically.
    • QC: First time using remoteproc, so wouldn't likely use sysfs i/f. So not sure yet.
    • Xilinx: Ed - just getting this effort rolling. Not up to speed yet on testing. Basic use cases are start and stop, so sysfs not used (?).

2020-03-26

Minutes:

Linux patch activity

  • MP: Fair amount of patch activity. Suman has published ~3K lines. Will take some time to go through.
  • MP: Some other updates from Bjorn.
  • MP: Many patches still under discussion. Suman's updates... (audio breaking up).
  • MP: Have reviewed Ben's R5 remoteproc patchset. Have not heard back.
    • EM: Ben is consumed, will take some time from his end.
  • BM: Report Bjorn
    • MP: Bjorn is splitting platform driver work with MP. Bjorn will focus on QC Platform driver, MP on other drivers. Both will review Core Code.

Open-amp & Libmetal activity

  • AP: New pull request coming from Zephyr. Last was 3.17. Starting review. Zero copy getting integrated.
  • EM: A question has arisen: The proposed patches are using user space rpmsg ahead of kernel space. So zero copy, variable size messages, etc. - do we want 100% compatibility between user and kernel spaces? Or should User Space OpenAMP be allowed to go faster?
  • AP: what can we do to keep Linux compatibility? Can also use OpenAMP(?) to keep compatibility between Xen and Linux Co-processor
  • BM: How will be P know if compatible/capable
  • AP: Will depend if service on top has impacts. If like zero copy with no impact on remote libraries, then must look at each use case
  • EM: Changing rpmsg buffer size is important. Not possible in kernel. Would like to keep default compatible. A patch pending to get maximum MTU? AP: Yes, also to be able to get on Linux side; on Xen could be in resource table, then getMTU can get it. Not a perfect solution.
  • EM: So want to maintain default compatibility w/ remoteproc implementation, but would be good to extend user space implementation so that both ends can reliable know what both sides support (An arch goal). AP: Want something dynamic thru the resource table - must be static as first step.
  • EM: Want to highlight this - need group to weight in.
  • BM: Perhaps a protocol document that's independent to resolve these types of items from wire protocol perspective. IF common API model, then user discoverability would be in there.
  • EM: Been reviewing documentation, agree need a protocol spec.
  • BM: Should OpenAMP not add features teh kernel doesn't support? Think not
  • MP: How would that work?
  • BM: MCU to MCU example - gets used without kernel at all.
  • MP: In that case, then kernel shouldn't stop progress, but when talking to kernel, message sizes must be aligned.
  • BM: Volunteers to document the Protocol Documentation?
  • What is the scope?
  • BM: Take a doc project from another project and create skeleton.
  • EM: Internally on the hook, so will take a first cut (ACTION). Need to discuss user/kernel space consistency. A docs gap analysis is an activity ongoing as well to make this all easier to use. Target first cut in next few days. Will be good to get tech writer eyes on this at some point as well...for example, Yocto pays for Tech writer.
  • EM: Would appreciate any contributions from all on any existing content to Ed.
  • EP: ST Wiki has some content.
  • AP: https://wiki.st.com
  • etsam: https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol a proposed baseline but misses some of the use cases. Good starting point

OpenAMP CI activity?

  • EM: No recent updates.

Other Topics:

  • Deeper discussion of Mathieu's "MCU" sync patch set?
    • MP: No feedback yet, but Loic and Arnaud plan to review. Requested NXP feedback, but haven't gotten back. QC may have use case as well.
    • Suman: Will have some time to review and test.
    • MP: API to allocate remoteproc may need some tuning - a work in progress.
  • BM: From App Services call - some impact OpenAMP library and kernel implementation. Any thoughts?
    • BM: Topic: Adding a name service. rpmsg already has one. Would like to see enhancements to existing vs a new implementation.
    • MP: Haven't been involved, but enhancing what we have is preferred direction.
    • AP: regarding MP's patch from a couple months back...could be used for name services.
    • MP: so tty patchset w/ rpmsg has reached limitation, and MP newer patchset to extend this service would be a good place to start these discussions. Also note that Suman just reviewed - will review Suman's comments.
    • AP: Bjorn also suggested reusing rpmsg driver to extend name service. Could be a good example to start discussions around name services.
    • ACTION: MP to prioritize reviewing this.
    • Suman: will be needed for message char driver as well.
    • Service name exposed in sysfs. ...idea to get reference using device name.
    • BM: What is MTU of service? vid or pid? more info we need about end points? Would like to add request-response model to be able to use this with endpoints. Is standard request-response model supported?
      • MP: things like this could be part of rpmsg char driver, but might be too generic. Discovery services may need to be part of message exchange protocol Can't see doing this in a way that is flexible enough.
      • AP: Since name service endpoint, could create something similar for config to announce what is supported.
      • Suman: Additional end point messages could be additional command messages on that endpoint.
      • BM: if additional messages, how are ones not understood handled? Would wildcarding require additional messages? Suman: Yes would be good from compatibility pov. Additional fields / features - one option is a new version of name service endpoint and not break compatibility.
      • BM: Additional content in the announcement followed by query-response model. Want kernel space drivers to know end points support request-response model. Don't have to code into every driver...

2020-03-12

Agenda

  • Review Linux kernel activity
  • Review open-amp library and Libmetal activity
  • Review OpenAMP CI status / activity
  • Strawman poll about face 2 face in next 3 to 6 months
  • Other items

Attendees:

Don, Bill(TI), Mathieu(Linaro), Suman Ana(TI), Arnaud Pouliquen(ST), Clement Leger(Kalray), Loic Pallardy(ST), Prasad Sodagudi(Qualcomm), Etsam Anjum (MGC),

Minutes:

Linux mail list activity review

  • MP: Review
  • More than 15 active patchsets on the mailing list. Split into categories (waiting for new revisions, to be reviewed by MP or Bjorn, under discussion).
  • MP to be reviewed
    • Kick method review
    • Fix memory region support. Arnaud to review and test this
    • Bjorn - panic handling, needs Arnaud and MP review. Suman will look at as well.
    • New from Qualcomm - protection domain restarts - Bjorn to review this one.
  • MP Under discussions
    • Late Attach: MP RFC coming out as soon as today. Re-branding as "Synchronization between MCU's already running."
    • MP: Ben L. Xilinx - R5 remote proc support. Conversations in progress with some rework required to conform to structure used by multiple vendors. No showstopper, just refactoring.
    • MP: Need help reviewing - Wildcard matching for name service. Can Suman review?
      • Suman: Not yet but will review over the next few days.
    • MP: RFC from Loic - crash processor recovery. Being discussed in Alex Elder race condition patchset and MP Late attach patchset. Likely need to find a different way to fix than what Alex is doing.
    • Bill: Bjorn's panic handling relate? MP: No different areas of the code
      • MP: Bjorn's patchset related to collection of data, Loic's related to sequencing & mechanism to trigger the recovery of a crashed processor.
    • MP: Assume disable of recovery mode done in platform driver. Loic: Correct, not done thru debugfs
    • MP: Lots of people need to review this use case to make sure we cover the use cases.
  • MP to talk w/ Bjorn to split patchload to review. Need this to be more efficient with the outstanding number of patchsets to review
  • Arnaud: Working on VDEV in Resource Table vs DeviceTree. Continue to test with different memory configurations. ** MP: This is good so that don't have to embed in device table. Arnaud: uses bind/unbind of drivers more effectivly.
    • Loic: Can Arnaud send out an RFC for review? Need to make sure compliant w/ all hardware.
    • MP: Need to support legacy, but sounds ok.

OpenAMP/Libmetal status, Arnuad

  • Arnaud - one update. Support changing the size of rpmsg status and easier method to configure it.
  • Brings up a good topic for TSC, how should we do documentation related to the library. A wiki? Or another way for contributors to update docs.
    • Bill: Similar topic on protocol spec. Best handled w/ markdown and sphinx.
  • Arnaud - decided to stay on github. Need to discuss w/ Ed to add checkpatch integration into github pull request.
  • Bill: Have a list of things to get in for April 04 release?
  • Arnaud: zero copy - need validation capabilities for this feature. Will be main contribution.
    • https://github.com/OpenAMP/open-amp/pull/162
    • Plus the rpmsg size and check-patch items discussed above
    • And hopefully an initial version of the CI loop
    • Also a proposal (from Nordic?) to pass some coverity tests - no status on this. Bill expects this from Zephyr as well
  • Arnaud: Waiting for a year for Kumar to review some zephyr work.
  • Arnaud: also work to integrate into the Arduino framework.
  • Also an NXP patch w/o resource table. Linux-zephyr communication w/ resource table, RTOS/RTOS communication with out resource table.
  • Estam: Will the rpmsg size configuration be supported on Linux?
    • Arnaud, no this does not address the Linux side. someone (NXP?) had a patch but have not shared yet.
    • Bill: does your vdev rework help for setting rpmsg size on the Linux side?
    • Arnaud, no, at least not the whole story. No more a solution to help memory regions available for rpmsg. Need to add new API to get device address to physical address.
  • Etsam: Zero copy source? Arn: From NXP implementation done a few years ago. just re-enabling it
  • Etsam: Ed discussed large buffers for rpmsg in user space. Plans? Arn: No plans. Arnaud wondering how much we should put into the existing OpenAMP lib repo. Should we have the big buffer handling (and Linux side) in this same repo or move to a new one? A discussion that needs to be had in TSC.

Bill: OpenAMP CI - no updates this week.

Face to Face meeting Strawman

  • MP: Test water on F2F in next 3-6 months
  • Bill: Prohibitions on such are likely going to make this unlikely. Impractical to plan for a F2F. Evaluate in the fall.
  • MP, agreed, no desents
  • ELC in fall or Plumbers in August, but monitor this and revisit this summer.

Other items

  • Prasad: RAM dumps concern. Migrating to remoteproc. Seeing core dump - no synchronization and can fail in low memory situation. Any tools/apps that require this method from remote proce. Arm AP side.
  • MP: See remoteproc panic patchset. Prasad: When subsystem crashes, recovery info in vmalloc area.
  • Arnaud: After getting dump, app can restart.
  • Prasad: Why no user space app reading this dump?
  • Arnaud: ST has a demon that. Not triggered by event, but polling.
  • Loic: Need an action from User space to restart co-processor. Missing today.
  • Prasad to follow up w/ Bjorn.
  • MP: suggested to look at the rpmsg_char driver as he expects the application would get notified if the underlining reportproc dies.

2020-02-27

Attendees

Don, Bill, Mathieu, Nathalie Chan King Choy, Prasad Sodagudi (Qualcomm), Siddharth Gupta(Qualcomm), Clement Legar(Kalray), Ed Mooring, Stefano Stabellini, Etsam Anjum(MGC), Loic Pallardy(ST), Suman Anna(TI)

Minutes

Standing Item: Patch summary status

  • Coming up is work from Loic. Work that he and Arnaud doing for Late Attach using conditional statements in platform code. Leads to same patterns - Bjorn wants that reduced.
    • Last submission to list from Arnaud.
    • Found this to be unmanageable due to coding standards related to other architectures. Came up with a proposal to keep such items manageable. Will have ready in a couple weeks
  • OMAP support - yet to look at it, TI folks have commented. Will require "reviewed-by" from TI devs
  • Siddharth 2 patchset submital - Can't move forward since requires other "reviewed-by"s from other QC devs. Platform specific code.
  • Ben (Xilinx) to support Zinc R5 platform - yet to review
  • Misc patches
    • Suman - fix memory leak. Also fix some warnings.
  • Another patchset from QC needs reviewed
  • Mathieu sent out rpmsg bus patch. Suman and Arnaugh had solutions. Would like Suman to review.
    • Could Clement review this? Yes
  • Bill: Status of 64 bit ELF support and version resource tables - like Clement's approach. Awaiting next patchset from Clement?
    • Agreed
    • V5 - making some fixes - send tomorrow.

Standing: OpenAMP and libmetal

  • Ed: Not much on libmetal. OpenAMP - Xilinx example code updates related to interrupts and some bug fixes. One patch that Arnaud needs to review. Then get into pull request backlog. Currently 10 pull requests backlogged.
  • "x" next to pull request == CI failed on github. May not be merging or took too long to build.
  • List of these targeted for V4 release?
    • Want to discuss w/ Arnaud but off for a few weeks. He is out, but don't wait
  • CI Status: Only builds Xilinx. want to make more accessible. Want to bypass having Yocto in process and be able to write OpenAMP apps quickly. Ed would welcome feedback. Want to get the CI loop where OpenAMP repo vs Xilinx version is used. Making a little progress here. On QEMU but should work w/ Xilinx hardware too. Then must determine how fits into LAVA.

Face to Face meeting?

  • Mathieu: Connect BUD20 cancelled. So F2F meetings won't happen. If required, may need to discuss a Sprint.
    • ELC NA Austin may be a good venue for this. ELC Europe could be a target too. Plumbers in August a 3rd option

Collecting Carried Patch count info

  • Bill: Wiki page with pointers to patches, etc. Bill to create initial draft. Then may move it.
    • Could Loic share with Bill ST vendor tree link. Kernel, uboot, and all f/w for boards for Cortex M4 are in public github
    • Ed: The right person for Xilinx - will share Linux repos w/ Bill - share which ones to document.
    • Qualcomm: Anything to include as a pointer?
      • Yes, currently on CodeAurora. But will hold off a bit to share.
    • Clement: Full Linux tree - could add that includes remoteproc driver.
    • Mentor: For OpenAMP, using main github repo. Forked it but no patches to add currently. On Linux side, all in private repos, enable stand-alone rpmsg. Not much different than vendor trees.
    • Bill to add TI links

Etsam: re: early boot, any pending items?

    • Loic: early boot already there. added resource tbl mgt. and Late attach. Want to clean up crashed P that is still running and be able to recover from crashed state.
    • Share with Mathieu? Mathieu suggests waiting.
    • Loic: Send request for comment to Maillist. Will send two sets for discussions. Make sure applies to mainline. Will send mid-next week
  • Loic: Will there be a bug tracker? With priorities?

2020-02-13

Attendees:

Bill Mills, Dan Milea, Loic Pallarday(ST), Nathalie Chan King Choy, Sid, Mathieu Poirier (Linaro), Don Harbin (Linaro), Ed Mooring, Rishabhb(QC), Arnaud Pouliquen, Prasad(QC), Trilok Soni (Qualcomm), Xiang Xiao (Xiaomi), Suman Anna (TI), cleger

Minutes:

Revisiting Resource Table and 64 bit MCU's

  • Matthieu: Idea to update next gen table. Investigated on how this works today - if want to use same names in resource table w/ backward compatibility, then new RT must be added AFTER old RT. This is constraining. If have to order from oldest to newest not that good. Option: Spin off RT 2 from RT 1. Then just add to section header, order independent, and is backward compatible.
  • Bill: How does old kernel know to find old table if not first?
    • MP: Will reuse name for first one - does not change to maintain backward compatibility to old kernels.
  • Bill: Could have multiple RT's and new kernels could decide which ones to use.
  • Suman: Supporting multiple different RT's in parallel? RT has a header w/ version - can't just use that?
    • Bill: Use case to solve is f/w unusable unless know how to process new RT (64 bit). Old kernels won't know new versions.
    • MP: Haven't defined new RT format, just working on new RT introduction.
    • Bill: Per item version numbers might be overdesigned. Most cases handled by 2 RT's at most. Old and New. Then the mechanism could be simple (V1, V2, etc.)
  • Bill: Likes the idea MP proposed.
  • MP: This doesn't modify processes in kernel and tooling is the same, minimum rework.
  • AP: How to differentiate f/w is a use case to consider.
    • MP: If old kernel then won't work. Can only insure b/w compatible by including old tags.
    • AP: A RT is ??? of f/w.
    • Bill: going forward could differentiate, but older kernels won't.
  • Bill: Any objections on MP's idea?
    • MP: Contributing code to mail list are best ways forward. This depends on supporting 64 bit MCU's. Have been exchanging ideas. Is this higher priority than Late Attach & making rpmsg more robust? Need to have the priority discussion to determine where MP will contribute.
    • Bill: rpmsg robustness important. How big is late attach?
    • MP: Late attach part is working ok right now - not controversial. Still the first step in things to come. Can't do robustness if no late attache - a gateway task to others
    • LP: Would be nice to test ST patches as well.
    • MP: Agree, need to get TI approval to move this forward.
    • Suman to review patches in next 2 weeks. ACTION?
    • Bill: TI priority - 64 bit important but could handle on own. Getting basic patches and explore robustness are higher priorities.
    • CL: Will try to find time to test this out (?)
    • MP: Good note that CL is already working on 64 bit. May note be trivial.
    • Bill: If have complete 64 bit solution can you point it out CL?
    • CL: A github repo but a quick fix. Framework ready to accept 64 bit addresses, backward compatibility is big piece.
    • MP: Have any addresses using more than 32 bit in size?
    • CL: Yes. Went 64 bit.
    • Suman: Addresses still in 32 bit for TI.
    • Bill: QC have 64 bit co-processors coming into play?
    • QC: No. Only on app side, don't use remoteproc on the dsp side. Interest is loading DSP's and managing state side. Only use remote proc on app side.
    • ACTION: Trilok to check on need for 64 bit on device side of remoteproc. Sounds like "no"

Release update Arnaud / Ed

  • Ed: 20.20.01 is a catch up release. will go to .04 and .10 releases. A number of changes accepted on kernel side that need accepted on openAMP side. Would like to target .04 if can get test tooling in place. Though Xiaomi would provide samples to test
  • ACTION Xiang Xiamo to provide test cases in next month.
  • Arnaud: Also need to clean up pull requests.
  • Arnaud: any new development is welcome.
  • Bill: Any way in github to target a release like .04?
  • Ed: SC discussion - github flow vs kernel mail list flow?

Kernel Late attach? Trilok

  • Bill: A topic and mailing list patches going around
  • Mathieu: Conversation heavy on mailing list
  • Trilok wants to discuss use case
  • Trilok: Talkng w/ Bjorn, and have in house solution. Been using for all DSP's. See need to boot DSP early on. Certification requirements as well. Other use cases like charging. Currently 2 subsystems. Want to align from internal solution to community.
  • MP: Even if no patches right away, reviewing current solutions and feeding back what won't work will go a long way. Use remote proc mailing list. Late attaches being proposed right now.
  • ACTION: QC Prasad to review remote proc late attach patches and provide feedback in the next week.
  • Late attach next steps

Robustness

??

2020-01-30

Agenda

  • Review of Mathieu's pending patch list
  • Is Firmware compatibility across Kernel versions a value statement for OpenAMP?

Attendees

Bill Mills, Arun, B Levinsky, Ed Mooring, Etsam Anjum, Mattieu Poirier, Nathalie, Arnaud Pouliquen, Loic Pallardy

Notes

BM: Topics: • Discuss patches that Mathieu mentioned on the mailing list • Evolution of the resource table. Immediate need is for 64-bit resources and addresses. this brings up a meta topic - how much do we value forward and backward compatibility across kernel versions?

Mathieu's patch list review

MP: Mailing list since Nov - have noticed some trends. Would like to discuss those after looking at patches that are worthy of attention. Have a list of 6 patch sets. If there are others please bring to my attention.

OMAP remote proc - has seen a fair amount of revision. Sumant/Andrew Davis have commented on previous version. Now need to Ack or comment further. No action from MP and Bjorn until TI have had a look. BM: I’ll ping them to do that. MP: Would also be good if ST could try on their board and show that they aren’t breaking anything.

MP: Clement provided patch set to notify IDs(?). Consensus that it introduced jeopardy in stability. Need to wait for new resource table. Still open or someone working on this. BM: Started a wiki page organised in 2 areas. What do we need and proposals for mechanisms for new resource table. Want to get consensus. If FW requires 64 bit addresses case is black and white. Not all enhancements so black and white. MP: Would like to go back in the code and see what the kernel is doing right now. More research to be done on this. BM: Likely that we’ll need to come up with a resource table v2. Don’t want to see a succession. Would like to see FW able to publish multiple resource tables. AP: Just added some ST requirements in the wiki page. Split into needs and enhancements.

MP: Patch set to get MTU size. AP: Allow to get maximum transmission size mainly for virtio support. Would like to have API and then restart around client. LP: Proposal was to have tty flow control. Bjorn would like to see some RPmsg flow control to avoid that one client consumes all the buffers. ttyrpmsg client upstream is ongoing in ST. MP: Suggest to do a respin of MTU as it is with Suman’s ack on it. Leave the rpmsg tty driver out of it. Can have the conversation at Connect with Bjorn. Seems to be a good way to proceed. BM: Thought we were already fixed 512 byte messages? LP: Fixed today but there was a proposal to be able to customize the size of the buffers. Sent a proposal years ago but it was a long discussion. Bjorn would like to not have a fixed size or fixed table of buffers. Not going right direction for zero copy. MP: Max buffer size is still 512 in the code. AP: Also a 16 byte header. Client is not aware of it. With this API for the virtio - virtio decides the size. MP: Glink for QC does that.

MP: Patch set from Loic - support for coprocessor loaded and booted before kernel. Think need Suman etc from TI to build consensus. BillM - could you pass the message along. BM: Believe he looked at it and said it was Ok. LP: Yes discussed at Connect and did a review with Suman and discussed with Bjorn. Changed the name of the feature to “pre-loaded”. Propose to send a new version with same content but add ST remoteproc driver to show how it’s used. Will do that as soon as RC1 proposed. All questions from Bjorn were answered on series 1 & 2. MP: Having Suman explicitly ack this will go a long way.

MP: 64-bit ELS support in ELF loader. If in favour of it, please ack it, otherwise propose something else. Believe Clement has achieved good balance. Have asked Clement to respin version for when 5.6 RC1 comes out. BM: Will take the action. AP: Tested with coprocessor. Can test latest version. LP: Maybe some people from Xilinx can test since they have 64-bit support.

MP: Patchset for post mortem debug support. Some shortcomings with it and work is moving forward on this after some conversations.

MP: Don’t see any QC-specific patch sets. Believe there are people on Code Aurora that can review them. Are there any other patch sets that people want to raise.

AP: Patch set giving something more dynamic for “service name”. Suman also sent a patch related to services. Implements an ops to be able to respond to a service name dynamically. Allows to have some sub-services for instance on a serial virtual link. MP: this is an older patch set? AP: Yes MP: Respin a new patch set with some of the topics that were agreed on - then start working on it. AP: Will reply to it.

BM: Like to have a less than 10 minute discussion - how do we want to keep this (patch set tracking) going. Do it once a quarter? Try to track it weekly? Collect a staging tree? MP: Doing this every couple of months would be a worthy exercise. Don’t want to track it on the wiki. Staging tree - would like to talk to Bjorn about me keeping a tree with patches that we think are ready for mainlining. Would people like to see it. BM: Think it’s useful to have one place to go to. Also for all the dumb ideas/hacks. MP: Trees exist in TI and ST. Pointing to them in a wiki would suffice. BM: They’re consumable but not by a casual user.

EM: Xilinx has a similar tree - it requires some dedicated attention to do something. Trying to get back to making building a tree with reasonable openAMP infrastructure easier. Need it for Linaro work as well. BM: Have tried to go through Xilinx tree and it’s not easy to find things (like TI tree). EM: Long way to being able to type ‘configure’ or ‘make’ and have a tree with OpenAMP in it.

BM: Forward and backward compatibility. We want old firmware to work with new kernels. MP: Think that’s feasible. BM: How real a problem if new firmware may get used with a vendor kernel (new features) and a stable Debian kernel (old features) MP: We want to support this? EM: How old? Do we want to go Intel/IBM route? BM: No, make improvements. Latest tree but also has to work with Debian stable that is 2 years old. Do we use lowest common denominator? Could have 2 resource tables or resource entries. Not sure how practical to support 3.18. Could say we want to support 5.4 and anything newer for the next 6 years. MP: Old way of doing things has to be present in the FW as well as the new way. Depends on what we want to do as a community. BM: could have lowest common denominator and bring shiny new version. AP: If we add new section to resource table for new version. If we name it kernel can load the old or the table with the new section. Means you have to embed both in the FW. BM: Think it’s a good mechanism. MP: Make it up to people to embed it or not in their firmware as they want.

AOB

EA: Want to know about the release schedule for OpenAMP EM: Arnaud and I are in the process of getting out 2020.01 interim release incorporating safe changes and then get us back to regular .04 and .10 releases. EA: Any date in mind? EM: Either today or tomorrow. Going around final details of changes to some of the Xilinx demos. Release tag not yet created. AP: Branch associated to the release exists - 2020.01 BM: Will meet again in 2 weeks.

2020-01-16

Agenda

  • Progress on resource tables?
  • Progress on CI?
  • Status of Release of open-amp and libmetal libraries
  • Progress on kernel staging?, none

Attendees:

Don Harbin, Mathieu Poirier, Bill Mills, Tomas Evensen, Arun Bala, Clement Legar, Dan Milea, Ed Mooring, Nathalie C. Chan King Choy,

Minutes:

  • Arun Bala - Xilinx first time joining.
  • Progress on staging tree / Resource table
    • None, Bill to create wiki page and others to comment

Progress on CI

  • Ed published readme to rebuild QEMU software, Bill got this to build. Steps for CI?
    • Ed: Would like further requirements. Also working with LITE. Want to dive into OpenAMP w/o hardware. Working with Paul Sakalokski on LAVA integration in LITE.
    • Bill would like to see LITE and OpenAMP efforts in this be a bit more open and colabrative instead of making Ed play man in the middle all the time.
    • Won't likely get Paul S to join this mail list

Release Status of open-amp and libmetal libraries

  • Making OpenAMP release
    • Arno and Ed actively working on this. Tag teaming. Agreed on content, tagging strategy, and release notes. Will put out an RC1 in a couple of weeks.
    • Just cleaning up and testing, no new major features.
    • Want a 2020.01 (existing process) that is catch-up. A lot depends upon SC Group wishes around process changes.
    • Ed/Arno talking 1:1 - will use old mailing list once RC's begin.
      • Bill: Plan to retire old list.
      • Ed: 2020.04 will be using the new process
    • Can we use the new mail list now?
      • Ed: Not fast process since entrench in many places.
      • Bill and Ed agreed that both lists should be copied for the release process. Fixing all internal references can wait until 2020.04
      • Action: Ed to have wiki's point to new mailing list.
      • Bill: Secondary concern - can we make the process more transparent? Would like to see conversations occur on the list.
      • Ed: Sounds ok
      • Bill: At a minimum, publish release plans to the lists
      • Action: Ed to publish release plans for RC release to the list (both lists)
  • Dan M: Questions on Release and CI
    • Notes ... source of release is on github. Instructions were to get the ball rolling on CI. Goal on QEMU is to have a working environment into which code can be written for OpenAMP and run under QEMU. Code for remote processors can be there too. Toolchain choices as well (Xilinx and others).
    • Ed
      • Build OpenAMP on Linux R5.
      • Have a turnkey way to play w/ OpenAMP that's amenable to H/w development.
      • Bill: First priority - testing OpenAMP Github repo versions. Simplified build flow. Also need to test w/ upstream kernel w/ minimal patchset that could be rebased for every kernel
      • Ed agrees. Mainly want CI loop running.
      • Bill: Just want to know what's running in the CI loop. Using Xilinx QEMU is ok, but need to test against upstream. Also need to get to testing on real h/w.
      • Ed: April-May targeted to get environment set up.

Pre-allocated notify IDs

  • Clement: Pre-allocated notify IDs
    • currently a lot of applications that use ?? and expect Linux ??
    • Pre-allocated ID's are defined in stable. Have mailbox generic description in device tree. Patch resource table into device tree. A single cluster starts other clusters. Allocate multiple mailboxes ???

Can we make progress on resource tables?

  • Bill: No progress on Wiki page for resource table evolution. Can this be done Clement?
    • Action: Yes, Clement will comment on resource table evolution on Wiki once Bill sets up the Wiki
⚠️ **GitHub.com Fallback** ⚠️