-
Notifications
You must be signed in to change notification settings - Fork 291
OpenAMP remoteproc Subgroup Meeting Notes 2021
Bill MIlls edited this page Sep 23, 2021
·
20 revisions
This sub-group covers areas such as remoteproc, rp-message, virtio, big buffers, etc. The meeting cadence is every 2 weeks on Thursdays at 11 am Eastern US time.
Mathieu Poirier (Linaro) Arnaud Pouliquen (ST) Ed Mooring (Independent) Bill Mills (Linaro) Tanmay Shah (Xilinx) Suman Anna (TI) Hari Nagalla (TI) Bruce Ashfield (Xilinx)
- Terms update
- Bill to send discussion from TSC list to openamp-rp list
- Ed/Arnaud to figure out plan to rename github branches from master -> main after the October release
- Xilinx R5 driver upstream
- TS: Start small with just remoteproc driver, add rpmsg in second round
- HN: TI: Heads up, New Driver AM64x for Cortex-M4 coming soon
- AP: Joint kernel tree at kernel.org
- Mathieu and Bjorn will be able to push to this tree
- In place but not yet defined as the official path
- Baylibre support for NAI APU
- Interesting work that uses DRM w/ remoteproc and rpmsg
- Getting ready for release
- Possible PR:
- Compiler inlining help
- New Linux demos
- Possible PR:
- rpmsg tty
- patches for new version will be coming soon
- new version is simpler (got rid of sideband control)
- old version had support for RTS/CTS signaling
- define vdev in DT (see presentation)
x Mathieu Poirier (Linaro) x Ed Mooring (Xilinx) x Bill Mills (Linaro) x Suman Anna (TI) x Hari Nagalla (TI)
- Hari Nagalla is new from TI on IPC
- Hari will take over most of work from Suman
- Suman has a new role but will still attend openamp meetings at least for a few months
- MP: reviewed patch from Martin S: Always on feature for amlogic media processor
- needs minor fixup in V2
- MP: reviewed Suman's recent patch, not much out of the ordinary
- MP: 7 line patch for mediatech T8195, will probably get to review this
- MP: Will be on vacation Aug 6 to 23
- Patches Qualcomm specific handled by Bjorn
- SA: what is the status of rpmsg char driver updates?
- MP & AP agree work is done
- makes it a module
- split control & data path
- keeps qualcomm mode untouched
- Bjorn has not picked up
- looks good for 5.15 (but next LTS _might_ be 5.14)
- EM: lots of linting fixes, a few real bug fixes
- Lots of ambitious stuff but author goes away after a bit so don't complete
- Manual Cache aware work got accepted, uses existing libmetal primitives
- Mathieu Poirier (Linaro),
- Arnaud Pouliquen (ST),
- Ed Mooring (Xilinx),
- Bill Mills (Linaro),
- Suman Anna (TI),
- Etsam Anjum (Mentor),
- Loic Pallardy (ST)
- MP: Working w/ Suman & Arnaud on their patches
- MP: Rob sent patch on bindings changing for spec stuff but should not
- SA: Have taken first look, confused a bit about what Rob is trying to do
Will follow up with Rob
- MP: Sidharth char driver fix working with Greg KH
- SA: 2020.10 U-boot will support early boot of R5
- AM64x, will be picked up for next
- lack of reserved memory binding in yaml casing dt check problems
-m is making checks more strick
- ipc-only mode for "all" SOCs
- AP: working with MP on rpmsg
- limit the ability of userspace to delete create/destroy rpmsg device
- AP/EM: PR for not inline (for rust compatible)
- globally disable static inline
- change to inline with external C ref
- Why not use a disabled inline option
- Need to optimize libmetal in general
- AP: ~900 Bytes for libmetal on ST platform
- Cached memory with manual coherency ops
- config switch
- libmetal?
- vrings
- config switch
- Stratos
- virtio in Zephyr using virtio layer in openamp
- Vincent G.
- Note: Zephyr openamp repo is an automated reformating
- No functional patches are carried
- No pull requests accepted there
- virtio in Zephyr using virtio layer in openamp
- Mathieu Poirier (Linaro)
- Arnaud Pouliquen (ST)
- Bill Mills (Linaro)
- Suman Anna (TI)
- Etsam Anjum (Mentor)
- BM is working on a doc / spec structure
- looking at Zephyr, Yocto Project, and EBBR
- Started with EBBR, moving build CI to github actions
- Will be a prototype for OpenAMP-docs
- AP: to send Bill a ODP version of
- EA: docs he wrote are now Incorporated into OpenAMP wiki
- AP: Libmetal PR #159 Add Symbols to Library
- User is interested in Rust integration and static inline is cause problems
- AP: request to manage the cache (request in Open-AMP but probably will be libmetal)
- AP: redirect syscall between two Linux systems??
- Proxy does semi-hosting
- Perhaps proxy use case is better handled by app srv model
- Perhaps make a better demo / example app
- Generic Service user Generic Service pub
- Proxy does semi-hosting
- MP: waiting for next rev from everyone
- AP next rev for rpmsg char enhancement
- SA IPC only mode on TI platforms
- AP: ioctrl can create lots of RPMSG device
- AP is this safe?
- could create lots of end points, some could bind to existing drivers
- Lets discuss when we have code to look at
- AP is this safe?
- Mathieu Poirier (Linaro)
- Arnaud Pouliquen (ST)
- Ed Mooring (Xilinx)
- Bill Mills (Linaro)
- Loic Pallardy (ST) first 30 min
- Suman Anna (TI) joined after 30 min
- Ed is retiring, willing and able to stay on as maintainer
- all agreed keeping Ed as maintainer would be good
- Bill to follow up with TSC if needed
- Github actions CI
- today is checkpatch & build test only
- some linux user space test on libmetal?
- not running linux to linux tests today but probably could
- no easy pass/fail results today
- Would be nice to test on QEMU
- Possible on Xilinx QEMU but is appears all or nothing
- Xilinx ZynqMP is not AMP usable upstream yet
- Using generic QEMU or generic upstream on Xilinx QEMU would break log jam
- Would use of Zephyr's user space mode help at all?
- Linux 5.13 now has virtio i2c
- AP hacked Resource table vitiodev to new ID and it was enumerated as I2C device
- would be nice to do this all the way for a demo
- multiple virtio devices would be good. 1 for rpmsg and 1 for I2c
- AP already have work that does multi virt queue from Resource table
- Doing in resource table makes i2c appear to user space but kernel can't bind devices to it (at boot anyway)
- AP has work to declare remoteproc Virtio devs in DT but review/acceptance is slow/hard
- ST has demo based on RPMSG I2C using 2 LCD panels
- Zephyr on M4 uses one LCD and presents I2C interface to Linux
- Linux can update the other LCD panel but can't see the first one at all even if it tries.
- From a couple of years ago, using ST demo code
- Suman K3 R5 incremetal patch for AM64 SOC
- seems stuck
- MP we should be able to push it through
Next meeting will be April 08 2021.
Mathieu Poirier (Linaro), Arnaud Pouliquen (ST), Ed Mooring (Xilinx), Bill Mills (Linaro), Loic Pallardy (ST), Etsam Anjum (Mentor), Suman Anna (TI)
RPMsg buffer size negotiation based on Xiang Xiao's proposal (rpmsg.pdf)
- BM: discuss point without Xiang participation?
- MP: can start discussion without him, but will need to share discussion with him
- AP: sump-up of Xiang Xiao's proposal is to use the VirtIO configs space to give requirement about RPMsg buffer size
- RX and TX RPMsg buffer sizes can be different.
- Bjorn finds this reasonable, main concerns about proposal is that each size should provide its expected TX size.
- LP:
- ST proposed the same few years ago: [PATCH] virtio_rpmsg: make rpmsg channel configurable
- same concern from Bjorn + would like that RPMsg clients can request a tuned size for RPMsg.
- LP feedback: not suitable for small system with memory constraint (need to pre-allocate buffers)
- BM: size defined by client and pre-allocated buffer is 2 different codes.
- EM: Xiang's patch seems rejected as not complicated enough, seems because no negotiation
- BM: if each side negotiates own size, the resource table entry could be view as minimum size, host can tune it bigger
- LP:
- no dynamic allocation possible for some remote processor
- the remote processor know the max size it can support (RX +TX)
- if need bigger buffer should use some other mechanism ( indirect buffers)
- it is the rule of the resource table to give size information because fixed in coprocessor firmware
- BM: a feature bit has also been defined, for which purpose?
- AP: to enable the use of this configuration or not( so default size)
- LP: when ST proposed similar patch: Bjorn other concerns was how to access to this config:
- need to know the structure on both side
- need a version
- RPMsg has direct access to the resource table. strong link between RPMsg and resource table format.
- BM:
- Would be nice to have representation at VirtIO level to abstract from remoteproc
- initial size seems needed at RPMsg init.
- LP: Right, at least for announcement
- MP:
- mainly agree with that, else need a buffer rebuilt step
- like Bjorn suggestion keeping things in VirtIO, so without strong coupling
- We need a patchset to restart the conversation and move forward
- LP: agree, a new series rebased to relaunch discussion, including new comment such as version field in structure.
- EM:Could be done in the library and ignore kernel, with a versioning for compatibility?
- BM: still need a proposal working for the Linux Kernel
- EM:
- A versioning to recognize other firmware
- The OpenAMP library could take the lead over the kernel in term of feature
- AP:
- We need to ensure that we not fork in term of features
- main risk to integrate features without kernel Acknowledgement
- BM:yes, pretty fundamental for feature that impact both.
- AP:
- 2 ways to implement the VirtIO , legacy(split) and Packed virtqueue.
- seems that packed virtqueue imposes static allocation and so could have to take into account for buffer sizes
- Packed virqueues not supported in Linux kernel remoteproc
- BM:
- the problem of the VirtIO config is that there is a very poor implementation in the remoteproc framework
- in other VirtIO get config and set config are used in a very dynamic way for negotiation.
- AP: do we need this kind of implementation?
- BM: if implement such negotiation in virtio-rpmsg for the buffer size, that would be an easy statement for other system.
- BM: i assume fw_rsc_config struct is part of the resource table
- AP: part of an area at the end of vdev struct
- LP: it a free area, just need to know offset and size. free in R/W access
- in ST patch, update it before remote processor kick, relying on loacl and remote constraints
- allow also asymmetric buffer allocation for RX and TX
- BM: The story could be:
- With remoteproc, information comes from the resource table, Linux reads config and update it if needed before the kick
- Without remoteproc (using a VirtIO device) could be similar with a negotiation between host and guest, guest gets what has been negotiated
- LP: make sense
- BM: to document if we implement with remote proc only as a first step
- LP: Legacy support could be based on size of the config.
- BM: So what would need to be change for this patchset
- AP: This patchset is a good starting point for discussion on mailing list, could propose to Xiang to resent it.
- LP: would be nice to point over old patch to merge both, to have a common solution.
- AP: I need compare both.
- BM:
- looking at OpenAMP side, access to the config area is hardcoded
- what about number of buffers for RX and TX is it symmetric?
- SA:
- number of buffers pick-up from the Vrings
- concerning config space could be have different config structures ?
- what about extend vring structure ? so, with a new version of the vdev resource type, as for 64bits support
- BM: for the config space we can have feature bits and/or version field.
- LP: yes, these two fields would be useful
- BM: any issue for 64-bit? For 64 bits no upstream right?
- SA: TI has not issue with 64 bits.
- BM: can address could be in 64 bits
- AP: RFC from Clement Leger [Openamp-rp] [RFC,] Resource table and 64 bits addresses/fields
- BM: what do you think about a new vdev version with 64bit support.
- AP: means that we would support buffer size negotiation only with a new version of the resource table
- SA: resource table actually hardcoded for 32 bits. Need a new structure to properly support 64 bits
- BM: is this something that block you Suman?
- SA: no, address is in 32-bit space even if it is a 64-bit processor
- Discuss Xiaoxiang's issue/feature and their suggested solution
No meeting on this day.
Mathieu Poirier (Linaro), Ed Mooring (Xilinx), Bill Mills (Linaro), Suman Anna (TI), Loic Pallardy (ST) Bruce Ashfield (Xilinx),
- Arnaud Pouliquen (ST),
- Guennadi Liakhovetski (Intel), virtio audio using rpmsg
- Bjorn Andersson (Linaro)
- xiaoxiang@xiaomi.com
- Get back to patch of Dec 18th: detach
- Arnaud is only one to have commented
- Pang has sent new versions for iMX8.M (two versions)
- Martin Bl* has patches for amlogic
- Arnaud 2 line patch taking long to review, return EBUSY when device is busy
- Ben: Xilinx R5 new version
- Alex and few others Qualcomm: Let Bjorn handle
- Suman PRU support: change make checkpatch happy
- targeting V2
- Adapting to mcu sync will be later in month
- Arnaud work to add ioctl to rpmsg char driver
- MP: will try to take a look
- LP: it would be good to get 2nd opinion from MP
- LP: we need more information from Bjorn
- EM: some bug fixes
- xiaoxiang: TCP 3 way handshake
- Servers know of the client connect and disconnect
- Special meeting to talk about this perhaps at a new time?
- Meeting on 1/28 will be canceled
- Next normal meeting with be Feb 11
- Look at possibility to have a special meeting on protocol enhancement
- Look for a time as early in Ed's day as possible so we are not too late for China