Hi all,
I hope all the mailing list issues are now sorted out. Linaro IT & I were doing some tests this morning. This list contains everyone who got the bi-weekly OpenAMP call invitation. If you wish to be removed, then please email me directly.
This Thursday's OpenAMP sessions have now been added the public Connect schedule, if you are on-site & using that to organize your week. I've pasted the Zoom links to both below if you are calling in.
9:00-10:30am PDT - "DTE Discussions: System Device Tree Discussion (Bayview Room)"
https://zoom.us/j/617455510
12:15-2:00pm PDT - "OpenAMP TSC Meeting (Sunset 1)"
https://zoom.us/j/4762224131
Best regards,
Nathalie
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Hi all,
As discussed last week, please find below a list of evolutions for OpenAMP and/or Linux kernel we can discuss next week during SAN19.
Regards,
Loic
Secure coprocessor support:
Add a generic rproc driver to support secure and isolated coprocessor thanks to some trusted services based on OPTEE or other Trusted OS.
Standard flow will be to load coprocessor firmware and its associated signature somewhere in secure/non-secure shared memory and then to request secure world to load, authenticate coprocessor image and then start coprocessor
Some tasks:
- Define a standard file format for firmware to authenticate (is ELF still relevant or should we rely on PKCS11 header like to integrate signature ?)
- Define TA API to control secure coprocessor (load, start, stop...)
- How to manage resource table in that case? Should we rely on some secure services or should we consider it as input for communication link (aka rpmsg) configuration between coprocessor and Linux kernel (and in that case could stay non-secure)
- ...
Improve Coprocessor debug capabilities
Today rproc framework offers access to a virtual trace file (circular buffer filed by coprocessor) which limit coprocessor debug capabilities.
Tracks to explore:
- How to store coprocessor traces in a log file (syslog like) to improve trace depth?
- How to get same timestamp between Linux and coprocessors to correlate trace
- How to control coprocessor debug infrastructure (coresight?)
- Is it possible to debug coprocessor firmware thanks to GDB/GDB server over rpmsg or mailbox?
Improve coprocessor reliability/recovery
Review remoteproc recovery procedure to be more scalable to product configuration
- Decorrelate recovery and core dump generation
- Create client (user space and kernel space) notification
- Be able to delay coprocessor restart after ack from all clients
- Silent coprocessor restart preserving resources and communication channels
Silent main processor reboot
- Don't reload coprocessor firmware
- Resynchronize Virtio and RPMSG communication link
- Notify main processor crash to coprocessor...
Generic Cortex-M33 support
- How to load firmware for new ARMv8-M coprocessor? One or two binary images?
- Could it be a generic driver?
Coprocessor 64bit support
- Ongoing elf 64bit support (almost OK)
- Missing 64bit resource table support --> need rsc table versioning
Rpmsg over virtio
Virtio_rpmsg is based on dma_coherent for buffer allocation. In the other hand, virtio vrings are allocated by rproc driver and not by virtio ring.
This is leading to an inconsistent situation where virtio is not aware of the way vrings and buffers are allocated and so consider them as "kernel memory" accessible via sg list and not dma_coherent one.
Virtio owns one flag named IOMMU allowing to allocate and handle dma_coherent memories.
Virtio_rpmsg and virtio_ring memory management should be realigned to work correctly on any CPU architectures (32 and 64bit)
System resource management via SCMI
- How coprocessor could access system resource? Could SCMI protocol be used on the top of rpmsg?
Rproc/rpmsg test farm
- How to test rproc and rpmsg feature set?
- How to check compatibility with OpenAMP bare metal/real time OS rpmsg implementation ?
Next features coming from ST
- RPMSG over UART serdev
- Virtual I2C over RPMSG
- Virtual SPI over RPMSG
Hi OpenAMP TSC,
This is the first message to our new TSC mailing list for the OpenAMP community project! It contains everyone who got the bi-weekly OpenAMP call invitation. If you wish to be removed, then please email me directly.
If you had the previous wiki page bookmarked for the notes, please update your bookmark to https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2019 . I changed it from the generic "Meeting Note 2019" title because now we also have meeting notes for the System DT calls (the first was Wed Sep 11) posted on the OpenAMP wiki, since it's the OpenAMP community project driving the System DT effort.
More shiny new things: we did a final round of feedback on the logo proposals from the graphic designer, and attached are the files for our project logo!
Our next call will be a combo face-to-face/call happening at Linaro Connect SAN19 from 12:15pm-2pm Pacific time on Thur Sept 26. The slightly later time is to give people a chance to grab their lunch, as this is the conference lunch period.
The System DT face-to-face/call at Connect will be 9:00-10:30am on Thur Sept 26.
Notes from this week's call:
https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2019#2019Sept12
Have a wonderful weekend,
Nathalie
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
