-
Notifications
You must be signed in to change notification settings - Fork 291
OpenAMP remoteproc Subgroup Meeting Notes 2021
Bill MIlls edited this page Jun 3, 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 (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