 Ok, je suis désolé pour le délai, donc let's get started. So this talk is about the use of RPMessage to unify communication between processors, and so to ease the transition between multi-suck solutions to multi-processor-suck solutions. So I'm Arnaupulika, I have prepared this presentation with Louis Pallardi who is not allowed to be here today. So let's introduce myself, Arnaupulika, I'm French, you're probably detected with my accent. I'm working at STI Microelectronics on the STM32MP1 project. I have a few contributions in the open-source communities, in Linux for ST drivers mainly. I also participated last year to improve the open-hump library and decrease its footprint. And I introduced the STM32MP1 platform in the field. So what is the scope of this presentation? So I will speak about multi-suck solutions, multi-processor-suck solutions. Let's detail what I want to say by this wording. Multi-suck solutions, it's a solution where we have several processors communicate together, but these processors are in separate socks. So communication is through a physical link. Here we will focus on a serial link. And multi-processor-suck solution is a socks that embed several processors that communicate together through a shared memory or mailbox or bus. And mainly, in this case, we use the rpmessage. So the presentation here is to explain how we can migrate from one solution to the other solution. But we will focus only on the intercommunication between processors. I consider that you have a distribution and OS that will help to switch from a platform to another platform thanks to an obstruction layer. But today, there is no real solution for the inter-processor communication to be able to preserve the application. An overview of the rpmessage. So ST uses some open-source solution. So on Linux, we use the rpmessage framework that is relying on a shared memory that is structured by a Vertigo framework. And for the co-processor, we use OpenMP library that offers the same kind of services. But for non-Linux kernel solution. What is the rpmessage? It's a simple message. You have a header, you have a payload. The header contains the source and the destination address. The source or the destination address can be local or can correspond to the remote address or the other processor. What is interesting on rpmessage is that it offers a system of services that can share on the same physical link. That means that you can provide a diversity of services on top of rpmessage. It will share the resource. And then it allows to implement different features on a co-processor. So a service is implemented in a channel. And then each application on driver can connect and un point that is a logical link with the co-processor through the channel. So our motivation, ST, I don't know if you know the STM32 family. But until this year, the STM32 family was made up of only MCU. So you can run several OS on it or distributions. You can use it in standalone but we have some customers that use it as a co-processor with an application processor. To communicate with this MCU, they use manually a serial link. Now we have a solution that integrates, embeds an mpu so an application processor and a co-processor. We still be able to run our solution as a co-processor and we run Linux on the application processor. This time we use the term memory to communicate for the entire processor communication based on RPMSage. So the challenge here is how can we help our customers to migrate from a multi-soc solution to our solution. Then when they use our solution, they implement several services on top of the RPMSage to initiate some communication between our application processor and the co-processor. But they can want also to extend the capability of the platform. So to add an external co-processor, that means that we go from an integrated system in one-soc to a multi-soc solution. So we have also to be able to preserve the application to offer the possibility to have multiple services on top of the serial link that allow to communicate with the external co-processor. And so we propose to use also RPMSage for this solution. So let's focus first on the migration from a multi-soc solution to a multi-processor soc solution. So what about the software to migrate from one solution to the other? On the Linux side, so on Linux on the left you have the solution based on a serial link. You want to preserve your application so to preserve the API you offer to the application or a client driver. So the solution is to implement the virtual driver over RPMSage. This driver is platform-maniponent. So it could be generic. I know that several companies already implement this kind of drivers. And with this driver you are able to simulate a serial link and offer the same API to the application. So here is some example of common serial link. So we can apply this to SPI, UART, SQC. It's always a kind of implementing a virtual channel over RPMSage. Now let's focus on the co-processor side. So as mentioned, you can run on the co-processor a proprietary solution or you can run some open-source OS, like Zephyr, ArmandBed, Arduino, on some other one. The main difference here is that you are OS-dependent. You should be still platform-independent because you have your OS that provides the abstract layer. But you depend on the OS. That means that you cannot have a generic solution for all the OS. You can just have a generic architecture solution. Here the solution is based on an open-name p3. And we have to adapt the driver to provide the wrapper between your serial API and the RPMSage. What is the status today in terms of implementation? We have already implemented on the Linux side the RPMSage TTY, the RPMSage SQC, the RPMSage SPI. We started the stream of the RPMSage TTY. On the co-processor firmware side, we have some examples available. We do not share it at this time, but we have some virtual driver available for our solution, so the STM32 cube solution, but also in Zephyr. Now transition from multi-processor SOC solution to multi-soc solutions. So this time, the concept is to implement RPMSage over the serial link. So you have to migrate from RPMSage over Virtio to RPMSage over a serial link. In this example, we have a new art peripheral, so it's a new art link. And what we propose is to replace the RPMSage Virtio bus that is implemented in the current RPMSage generation solution in Linux by a new RPMSage Serdev bus. So we will have the choice between use the Virtio solution or the Serdev solution. For the co-processor, it's quite the same story. We have to implement the Serdev bus, but this time we are O.S. dependent. So we also have to propose, I would say, a backend API of the Serdev or the UART bus, sorry. And we have to adapt a kind of RPMSage UART wrapper for each O.S. solution to be compatible with the API proposed by O.S. for the UART here. So the status for this migration, so we have implemented the Serdev bus. So now in our solution, we are able to choose between the Virtio and the Serdev bus. On co-processor science, today we do not modify the OpenMP library. It's more at the proof of concept level. So we implement some examples in our solution, but also on Sefia. But we do not modify the OpenMP library. Just also, we do not implement the solution for the SQC on SPI. Simply because we have no requirement on this for the moment. So what's next? So we plan to upstream to propose for upstream our solutions. So the virtual RPMSage drivers to be able to simulate Seria drivers over RPMSage. But also the Serdev bus to be able to perform RPMSage over UART peripherals. Then we will probably also modify the OpenMP library to do the pending modification for the non-linux processor. And when everything will be upstream, I think we will be able to propose some virtual drivers in the different ecosystems. That's all for me. If you have some questions. On the UART version of the protocol, is there any framing or error checking in addition to the fields that you show in that packet? So do you know error checking like CRC or framing like a... Not CRC in fact. We provide like a magic number to have a synchronization on the beginning of the message. And then we just check as a normal RPMSage. When you talk about shared memory between two processors on the same SOC, you talk about for example L2 cache sharing? No. In fact, when I speak about shared memory, it's a memory that is accessible from both processors. I don't know it's possible to use cache for this. Sometimes many... Sometimes there are a couple of cores that are sharing the L2 cache. Yeah, yeah, but yeah, no. I think about two clusters, different clusters that not share the cache in fact. But I don't think that if you can... I'm not expert to be able to answer if you can use... Because for example in the booth that you have in... the processor that you have on your booth there is two core ARM7 that are sharing the L2 cache. Yes, but I speak here about communication between the A7 and the M4, so two separate core. So it's only RAM. I think... I think you can have this kind of use case if you have some virtualization and you have two... I would say two OS running on one on each core. But I don't know if it is possible in this case to use the cache. I never test it. Ok, thanks. Do you have some measurement of the impact of the virtualization if you use the serial link with another processor and the RPMessage of front of it? So you mean the virtual serial link or the RPMessage over the... The RPMessage over the real serial link? No, we do not perform measurements. Now, I would say the limit is the max rate you enable on your serial link. Then it depends on your message if you have a big period comparing to the header it will be more efficient that if you just send two words in each message. Ok, of course. No more questions? Ok, thank you very much for your attention. If you want to see some demo related to this pitch, you are welcome on the ST booth or if you have some other questions related to this pitch. Thank you very much.