 Hi, thanks for joining us today at the talk for the OpenEMP project and its working group. We're going to be talking about standardizing interactions between the operating environments in a heterogeneous embedded system. I'm Natalie, open source program manager working with Xilinx open source office and my co-presenter is Stefano who is system software architect and virtualization lead at Xilinx. Both of us were involved with the relaunch as a linear community project. So what are we going to cover today? So we'll talk about what OpenEMP is trying to solve. We'll give you some information about what the project is and how this project that started with a repository of code and some interested collaborators grew into a more mature open source project with working groups that are now tackling a wider scope. We'll cover examples of OpenEMP in industry to give you an idea of the breadth of use cases and of participation. We'll point you to resources where you can learn more and we will let you know how you can get involved. So I'm going to leave this slide up for a couple seconds if you want to take a screenshot or a photo of it. These are the acronyms that we're going to be using later in the presentation and Stefano will take it from here. Hi everybody. I would like to talk to you about what kind of problems OpenEMP was born to solve. Nowadays, system on chips, so SOCs in short, are becoming more and more complex, more and more rich in terms of hardware resources, capabilities and functionalities. So once upon a time, you typically add one cluster of CPUs or a few CPU cores and a bunch of devices. It's not like that anymore. So now, often you have more than one cluster of CPUs. So if we take as an example the Xilinx and PSUC, we have a cluster with four Cortex-A cores and then we have on the side a cluster with two Cortex-R cores. So these are both ARM cores, but actually they support different instructional sets and they're very, very different CPUs. One focus on real-time and small application, the other one can support very rich OSs. We can also, we also have all other kind of cores. We have micro-blaze cores that are not, you know, they're not using an ARM instruction set at all. And we have a lot of programmable logic. So you can deploy multiple soft cores as we say. So CPUs in programmable logic, there can be micro-blaze. It can be other CPUs too, like Cortex-M. So in other words, an SSE of today, it looks a bit like a whole data center on chip. So there are with many clusters of different, very different cores running alongside. Some of them, like the Cortex-A cluster, which is the largest, with multiple execution levels and very different software runs at each level. So you have user space, conos, hypervisors, and secure world with multiple execution level, a secure world too, with secure real zero, secure real one. So it brings us a very rich ecosystem of software and operating system that needs to be installed and run and coordinate across the SOC. So Linux, it's very important especially on the Cortex-A cluster, but it's not the only operating system that runs. So you have Zephyr or Friartus, all the RTOSs on the Cortex-R or the smaller cores. Burmental application is still very popular and used. So a little tiny application plus just enough functionalities to initialize the system. So that gives us really a combination of firmware, operating system, larger and smaller real-time and non-real-time that can be very complex to configure, coordinate, and make it work together in an efficient way. So typically people still, without open-arm, there is really no solution for deploying and managing such a complex system. Everybody is really hacking together or cobbling together the system as you can because it's really difficult. So there are a number of difficult problems to solve from just the configuration to resource management, life cycle management, communication, and more. And as you can see, all these problems need to be solved with interfaces. So you cannot really just code away the implementation and expect it to be used by everybody. There are so many different communities, open-source projects with different cultures, proprietary vendors, so many components and pieces that they need to communicate and come together to make the system work. And this is how open-arm was born. To solve these problems through reference open-source implementations, through common interfaces designed by the community and open standards. And by reference open-source implementation, I mean that as the best possible way to get a new interface adopted quickly is to have a reference implementation that anybody can look at, see how it works, and then use it as a reference for the running implementation in Linux, Zephyr, all the rest is really anywhere. And through the proper documentation of these interfaces being introduced and a proper management of these interfaces, then you get to the point that you have a standard, a very strong standard that the community stands behind. So the the vision for open-arm, I'm going to read it out loud, is for the open-arm project to seek the standardized interactions between operating environments in an heterogeneous embedded system through open-source solution for asymmetric multi-processing. This is really the condensed version, the summarized version of everything I said so far. So open-arm, as Natalie mentioned in the beginning, started small, like all open-source projects. It started with a couple of repositories on GitHub, the RP message and remote pro repositories, and they are for to solve very core problems that open-arm is trying to solve. RP message is a protocol based on for communication between clusters. And remote pro is for lifecycle management, so that one cluster can start the other. But open-arm is not just any open-source project, like I mentioned, the key of open-arm is really solving the interaction between different components and the creation of standards through collaboration and community discussions. So since the beginning, open-arm had meetings, regular meetings, a few city con vendors and other companies working together to make the vision a success. Initially, open-arm was under the multi-core association as a working group. Over time, so it grew, it grew a lot more repositories than just RP message and remote pro. We now have different subgroups and we go through them later in details. We also created a bit more structure around the project. So it's normal to start small, but it's good to actually give a little bit of structure to the collaboration as you grow and you grow more members. So one of the first things we looked at a couple of years ago is to move open-arm under a proper foundation or an entity that could actually represent open-arm, something along the line of an open-source foundation, for instance. So we looked at the various options and eventually we started open-arm as a, we relaunched open-arm as a Linaro community project in September of 2019. So Linaro community projects are fully open-source projects for collaboration. A bit like a Lino Foundation project. So they're different from Linaro as an organization that is a much larger organization. So anybody can really join a Linaro community project. You don't need to be a full Linaro member to do it and you just need to join the project itself. And it can be, usually there is a very, very small fee associated that usually anybody can afford. So the good about having open-arm as a Linaro community project, the good thing about it is now we have a legal entity so we can have a budget. So we can pay for testing if required, we have a bit of money to pay for events, for locations or for interns as needed. Aside from the entity, the legal entity, the other thing that we did when we relaunched the project as a Linaro community project was to look at the governance. So I'm an open-source guy as many of you in the audience. So I really dislike, in a way, too much structure or too much bureaucracy or retake. But it's good to have in a project a tiny bit of information and clarity and transparency on how the fundamental processes work, such as in this case, how the budget gets decided and allocated, who decides about the budget. Or more importantly, actually the technical city committee, who is part of the technical city committee, what are the decisions that TSC makes? Or as a contributor, how do you become a maintainer? So these are the very simple questions that we answered with the governance that we introduced in September 2019. And really the idea is to make the process and the community transparent so that anybody can see how it works and can join or can become a maintainer or more involved with the project as they wish. I should say that open-hump is also true, as I mentioned, in sub-projects. It is so, but it still stayed true to the core. So the mission of open-hump is really creating standard and interoperable interfaces so that multiple components on such a complex heterogeneous system can work together and coordinate. And all these sub-projects are related, in a way, to interfaces and standards, including, for instance, just to mention a couple of new ones, the proxy operation work that we are doing, so that one cluster can access files on the file system of another cluster. Definitely requires coordination and very stable ABIs and compatibility interfaces between all these components. I'm going to let Natalie take it off from here and talk about what's the latest on that one. Thanks, Stefano. So right now, with the OpenAMP project, we have some additional working groups, and they build upon the OpenAMP framework that we started off with the multi-core association project with. These are now tackling problems that are related to what OpenAMP framework started with. And as Stefano mentioned, we sort of leveled up in maturity as an open-source project. We now have official maintainer roles, the technical steering committee, the board, the governance, the budget. And I think the part that the group had the most fun with in the relaunch was the logo. So as you can see, we have two P's in OpenAMP. They are different, so it's heterogeneous, and they are connected, and so they can communicate together. So what's really important, I think, is that we have the very diverse member points of view from a technical perspective. So although this is a Lenaro community project, as Stefano mentioned, it's not necessary to be a Lenaro member. Our members represent both ARM and non-ARM use cases. Linux, RTOS, environmental use cases are represented. Use cases with high-performance systems and resource constrained systems are represented. And it's really great that the discussions are very focused on trying to solve technical challenges. So I'll go into a bit more detail about the OpenAMP project working group. And what's really nice is this is an effort by many companies, and so we have different companies leading the different working groups. So the OpenAMP RP working group is the one that focuses on the original parts of OpenAMP, so remote proc, RP message, VertIO, and LibMetal. The main repositories we've got are OpenAMP and LibMetal, which just had a release in April. And then active work that's going on in this group is around big buffers, around improving testing through integration with lava continuous integration. And Lenaro has a lava lab, which is Lenaro Automation and Validation Architecture. That's what that's sent for. The group is working on getting patches upstreamed to the Linux remote proc mailing list for remote proc core. And I guess the most notable recent event is that some of the work on support for 64-bit L files is now part of the 5.7 kernel release. Another working group that we have that is ramping up is the application services working group. So that is led by Martin from One River. Oh, I forgot to mention OpenAMP RP is led by Bill from PI. So for application services, they're focused on what is needed to build on top of OpenAMP. We got together in San Diego at Lenaro Connect last year in the fall and had a meeting and a call with everybody who was interested. And the topics that were application developer issues that resonated most with everyone who was in the discussion was remote file access, so reading and writing files remotely, access of a console of a runtime remotely, proxy ports, and messaging APIs. So Wind River has been working in this area and taken inputs from the working group and they are working to put together example code that can be used as a starting point for more detailed discussions. They're proposing that application services would use operating system drivers for console, socket, file access, and networking from Vert.io largely as is. And then OpenAMP would provide the memory APIs, inter processor interrupts, and remote proc, while Vert.io would provide the runtime integration and collaboration using existing drivers and existing specifications of the driver protocol, which would significantly accelerate development, and also hopefully make adoption easier. And I'll hand it over to Stefano, who is the system device tree working group lead to tell you about the system device tree working group. One of the issues that we have with such complex heterogeneous systems is that we need a way to describe it, or in all its rich complexity and richness of resources. So the system device tree working group aims at extending the device tree to describe such a complex system, such an heterogeneous system. And the way we do it is by adding the concept of multiple CPU cores, multiple CPU clusters and multiple views to the device tree. So the device tree you probably know is a very commonly used standard in embedded to describe the hardware available and typically for one operating system. So one classic usage of device tree is, for instance, to be passed from the firmware from you to Linux, to let Linux know what's available, the device is available, the amount is the number of CPU cores, etc. So we took device tree and looked very closely at it and we tried to extend it so that it's not just the description of what Linux is, but it's a description of everything, including the Cortex-R cores, including microblades, including anything that is on the platform. In order to make this happen, there were a few changes to the device tree bindings, but very, I mean, not very verbose in terms of change, but very meaningful because, as I mentioned, device tree is typically a single view description. So it describes the system based on the view of one OS. Now it's a system device tree, we can describe the system with a multi-view, in a multi-view manner, so that each CPU cluster, for instance, we can describe, can have a different address mapping. So a device could be visible only by one cluster and not by the other, it could be routed in a way so that it's only reachable by one and not the other, or if it's reachable by both, it could be at different addresses. So these are the kind of problem the system device tree is solving. There is another set of problems the system device tree is tackling and is about firmware and software configuration. So firmware and software configuration typically does not belong at large in the device tree. There are some core pieces of it so that they are there, and the one that we are working on are about resource assignments. So you can imagine that in a system with multiple clusters, you're going to have multiple operating systems, each of them with running at maybe a different execution level of these clusters, and also we're going to have a bunch of memory that is their own, they're only going to have some memory to communicate with others, share memory, the interrupts which you send messages across, they're going to have some devices uniquely assigned to them. All these core configuration on basically what the software running on a cluster can see, can access and can use is what we call together an execution domain. So in system device tree, we define the execution domains available on an SOC. So for instance, we define the execution domain running on the Cortex R5 and the execution domain running on the Cortex Z. And then we define which memory is private to both execution domains. So all, you know, it's their own to use. And also the pages that are used for communication between the cluster. We also define the devices that are only accessible by one and not the other. This is really what system device tree as a specification is today. But system device tree is not just a spec, there is also some code and tooling involved. And the main one is called Lopper. Lopper is the English word for, you know, a gardening tool to chop and, you know, a tree or a bush, you know, to reduce the amount of leaves that you have. So it's really, it was a word chosen for this tool because the main goal of Lopper is to take a system device tree as input and chop it into different traditional devices. So system device tree is useful as a description, even at runtime, to pass to an operating system. But it was really never the goal that OpenMP system had to learn about system device tree because, well, why would a system device tree like Linux should know about what's running somewhere else that you cannot really access or add control over? I mean, useful information, but it's really not necessary. So since the beginning, one of the goal is to be backward compatible. So it's to be able to provide as output from system device tree multiple traditional devices. So the idea is you have a full description of the old platform, the system device tree. Then you can use Lopper to cut it down, to chop it to just a single device tree for one execution domain, the one you care about. So you can generate the device tree for Linux, you can generate the device tree for an Arthos, and you can generate the device tree even for a Bermeter application. And then of course, doesn't mean that one day, the thing where like you would or Linux itself might benefit and learn and grow out to learn, out to parse the system device tree and become aware of it. So speaking of Arthos, one of the things that we are seeing is that system device tree and Lopper are being used to generate a device tree not for necessarily the runtime, but also for the build time or very small operating systems or Bermeter application. And the device tree is basically used in this case for configuring the build of the Bermeter app, so that then when it puts up, it already knows all the addresses and what's available. So the latest information on system device tree is, so we have many lists, we have regular meetings, we are definitely welcome to join us if you're interested in this problem and these solutions. So one of the things that we're looking at is bus fireworks. So it's often the case, and it's the case on the board, and it's the case on all the city conbenders as well, that you have tools to actually protect memory accesses from one cluster to the other, so that you can actually prevent, let's say, the cortex A from tampering with the device that was supposed to be uniquely assigned to the cortex A. For instance, on Xilin Sport, this component is called XMPU. On other vendors, there are a very rich ecosystem of these tools to be able to offer protection. So system device tree is really a natural fit for this kind of problem because it does already this concept of resource allocation to different clusters and different operating systems. So it's really natural to add protection to this information. And these are the binding that we're working right now together with ST, micro, electronics, coming up with a definition together and a proposal that will show soon to the community. Hypervisor interfaces is another working group that we're going to start in the near future. Hypervisors, as their main goal in embedded, is to start multiple VMs and assign devices to virtual machine, maybe set up shared memory for communication. So as you can see, the problem space is very similar to AMP, to heterogeneous computing. It's still about giving unique access to devices or setting up shared memory or these kinds of problems. So it's really fitting that open up is also looking at common interfaces for hypervisors in embedded. And what is, let me go a little bit into the detail of what this working group is going to try to achieve. It's getting more and more common for OpenSys project to get used in more and more environment, vertical and markets that were never used before. Some of them require safety certifications, such as, you know, automotive and avionics need safety certification for the software. So in Zen project as well as other OpenSys project like Zephyr, we're trying to work together making the OpenSys software more easily certifiable, providing more of the tools, the artifact, the documents, the tests, so that users can take them and do a certification if they wish to or if they have to. So as part of these safety efforts, for instance, in the case of Zen, we have a special interest group called FUSA, special interest group. So we are trying to produce safety documents. So you should know that safety certifications have very high requirements, very on documentation of external interfaces. So this document needs to be incredibly precise, need to contain all the details analysis interfaces work. In fact, this document, they need to be so detailed that it's common practice in safety that the team working on tests is expected to write a test just looking at the documents of the interfaces, never looking at the implementation, the implementation done by a different team all together. So this is really, when you look at these ways, these documents are really incredibly detailed interface documents. So there is no reason why we cannot come together as a community to standardize these interfaces to work together on these documents so that they can be useful to everybody, not just Zen project, but all the right advisors open source of proprietary, everybody could use them for safety or just as an interface documentation or even maybe just as a standard. So if we work together on this document and we use these interfaces in different projects, and it becomes also easier to have compatibility interfaces to become natural, you can just become just one interface for everybody to work against, become easier to write software and guest operating system running on this hypervisor on switching from one to the other, prototyping with one open source hypervisor, switching later maybe to a proprietary provider, for instance. I think with that, I'm going to leave it to Natalie to continue on examples of open applications. So we have a couple of slides coming up of all the ways that different companies are using and have contributed to OpenAMP, and what this will go to show is how we're really solving problems that are important in industry and that benefit from standardization and collaboration by multiple companies that have a variety of use cases, and it shows the active involvement of the member companies in the project and in using OpenAMP. So at Xilinx, OpenAMP is the default AMP solution for Zinc 7000, Zinc Ultrascale Plus, MPSOC, and Virtual Devices. These devices have a Cortex, a application processor unit, and MPSOC and Virtual Devices have a Cortex, our real-time processor unit, so APU and RPU, which Stefano mentioned earlier in the talk. And so either APU or RPU can act as master. And as Stefano mentioned earlier, we also have microwave soft processors that can go in the FPGA fabric. So there's also microwave OpenAMP support. Mentor graphics, they use OpenAMP as the core for the mentor-embedded multi-core framework and multi-core framework product offerings. They expand upon OpenAMP by adding functionality to support Linux as a remote, large buffer support, zero-coffee proxy support for Ethernet, and additional development tools. And they also created a version that is focused on mixed safety-criticality systems where mentor-embedded multi-core framework handles the communications between the safe and non-safe domains on a single MPSOC. TI has been working in the OpenAMP project to enhance the Linux kernel implementation of Remote Proc and RPMessage, to define the wire protocol between processors, and has contributed a limited scope version of Remote Proc loader into UBoot to handle starting auxiliary cores before main Linux starts. TI uses the OpenAMP implementation for RTOS and for bare metal environments as an interoperability reference for its own implementation. CalRay leverages OpenAMP capabilities as a standard message-passing solution within its homogeneous mini-core architecture on MPPA3 processor. This support works across multiple systems when MPPA3 is used as an accelerator using VerdiO over PCIe, as well as inside the processor itself using VerdiO with shared memory. The Zephyr RTOS open-source project has a general integration to make OpenAMP available. Nordic Semiconductor has an example in Zephyr where they use OpenAMP to provide a Bluetooth host controller interface so that within a single SOC the application core can run the Bluetooth host and interact with the network core running the Bluetooth controller. Linaro hosts the OpenAMP project through their Linaro community projects division and some areas that their engineers are involved are through Zephyr, through the OpenAMP RP working group, and through the Lava testing. ST Microelectronics integrates OpenAMP and its multi-core and multi-SOC STM32 solutions for inter-processor communication between OpenAMP to OpenAMP or Linux RP Message to OpenAMP and ST uses the OpenAMP library with bare metal sorry with free RTOS and with Zephyr. WinRiver provides OpenAMP and participates in the OpenAMP working groups to accelerate the ability of developers to create edge compute applications and ARM has played an active role in the discussions to shape the system device proposal that Stefano talked about earlier. So where can you learn more and how can you get involved? We have a GitHub project so if you go to github.com slash openamp you can check out what we've got there. Also Stefano mentioned Lopper so Lopper lives at devicetree.org's GitHub we have an OpenAMP wiki. If you go there you can check out the notes from previous calls and there's information about features that are being worked on and features that are under consideration for future work. We have a community project website and we have mailing lists so Stefano had mentioned the mailing lists we welcome everyone to sign up you can go to list.openampproject.org we have calls for the technical steering committee and the working groups the call invitations are sent to the mailing list so if you're interested do sign up for the mailing list right now the one that is meeting most frequently is the OpenAMP working group they meet every two weeks and then the other groups TSE and board meet sort of as necessary. We welcome participation it's not necessary to be from an OpenAMP project member company do you please check us out and after you get to know more about the project and what we're working on if your company wants to become an OpenAMP project member it's not necessary to be a Lenaro project member company the member fees support administration for the project and infrastructure and what membership would get each company is a vote on the technical steering committee and a vote on the board so as Stefano mentioned we wanted to make becoming a member company really as easy as possible so all you would have to do is have a company representative sign the membership agreement in charter there's a $2,500 annual fee and this is our list of current member companies so we have ARM, Calray, Lenaro, Mentor, Nordic, ST, TI, Wind River, and Xilinx and hopefully soon we will have a 10th member company that's in the work and I just wanted to also thank everyone from the member company contributed some information towards this project and these slides Hi if you have any questions this is the right time to ask them we will be very happy to take any questions and answer them I can see that we have the first question already the question is about the status of large buffer transfer so I don't know the very latest and we'll have to get back to you on that maybe on the Slack channel after the talk I do know that there was a demo showed based on pre-shared memory and it was not then zero copy per se and I can also get back to you on whether it was using DMA buff I think it's probable that was using DMA buff on the Linux side any other questions on any of the topics I guess while we are waiting for any other questions to come in I just want to mention that the open AMP RP working group they have their next call scheduled for tomorrow morning at 8 a.m. Pacific I guess if anyone is interested in joining that ping me on Slack and I'll forward you the invitation the hi Francisco so there is a question on whether Xen will parse system advisory and that's a good question and yes so Xen should parse system advisory so one of the goals of system advisory is in fact is to make the configuration of an AMP system it's more I mean similar and aligned with the configuration of a static hypervisor so especially the static configuration of Xen wisdom zero less and guests that are pre-defined should work with system advisory same way the configuration of an AMP system would be done with system advisory so for that to happen Xen needs to parse system advisory to understand the virtual machine that he needs to start and you should also know that the zero less work so that the configure the advisory configuration for Xen to start multiple BM in parallel is already in a way a precursor of system advisory because it's following many of the same principles and idea also is not by the letter of system advisory yet so it will need some improvement and adaptation to support the future of the advisory does open AMP suffer from the share cash issues then solve with cash coloring so that's a that's another very good question so it yes whenever there is a share cash and typically when open AMP is used what may be the most classic scenario is between a cortex R and the cortex a cluster or between a cortex M and a cortex a cluster and there is no share cash in this case in these cases so the share the true cash that can be a source of interference inside a single cluster it will not be present in that case however if you're using open AMP to communicate between two virtual machine on the same cortex a cluster that does a share that you cash then yes the cash interfere an issue the cash coloring is addressing will be present so question from Matthew if there's any support from multiple processors or marketing controllers working on the same board but not on the same processor die so ST uses open AMP for their multi SOC solutions so I guess the answer would be yes a question from Andy I like the question when you have a system device tree what do you pass the data structure to if there is nothing running that that's a good question so well then with the premise that one day there might be a runtime usage of system device tree with then the data structure be passed the same way the device tree is passed so today is mostly using beforehand that would be a build time so you pass system device tree to lopper that will then generate normal device tree out of it and the normal device trees are passed as usual to Linux at runtime or for instance at are not those build system that will consume it at build time there are firmware however for instance you know an overall monitor of a platform that could consume system device tree at runtime today because this is one of the few components that actually need a description of everything that's present on the platform so that would be an example of something that could use system device tree right now any other questions from the audience so a question from Drew so in bigger board I am interested in different cores I'll use a communicate with Linux so the communication side of open up it's it's typically solved by setting up shared memory between the let's say the small core a cortex arrow cortex M and the cortex a core the memory is pre-shared beforehand as system configuration also where there is also f board going on in trying to make it more dynamic and flexible so so the mention of view boot so you know open up is looking at a number of interfaces that are useful on in an amp system so I'm so probably you would will not use a ring to communicate with the cortex are for instance it's not really typically needed but it might consume system device tree the system device tree is likely going to be passed to you would because in case of hypervisors or or for that kind of static configuration when there are multiple entities then you would need to be involved you want to pass a richer description of the system and you both is a typical one of the typical component that would need it any last question we still have a couple of minutes if you have any other doubts or question or comments and I guess if you think of any after the talk you can at mention us in the slack channel that was popped up on your screen a short while ago okay I guess thank you everyone for joining our call today and see you on the slack have a great day