As discussed last week, please find below a list of evolutions for OpenAMP and/or Linux kernel we can discuss next week during SAN19.
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