 Thank you for coming. Last day after lunch, it's not very easy to come here. The topic of this talk is about integration and the easy solution and development on constrained IoT devices. This job is being done by me and Tushar and the ARM team. I'm basically in Lisbon, Portugal. I've been working with Leonardo for some time. And now I'm working in ARM landing team to try to bring these solutions to upstream. And I've been working with Tushar at ARM, which is on the IoT platform team. And we're trying to more or less create a reference platform for these kind of devices. The hotline for this talk is basically we'll be talking about why the motivation for these IoT systems, for them to be created and existing. A simple hardware system overview regarding a platform that is more or less like an example that we are working on, try to define the constraints and what is a rich IoT platform. And then we go to the software side of stuff and overview and explain more or less like the tenification integration parts that we have done to reach the solution that we are halfway there. And we have a small demo only to show you that something is working already, some future work that we intended to do, and Q&A. So basically, we try to find the motivation for these kind of systems and why there is a demand on these kind of platform. Basically, it looks like there is a necessity to have offload for several parts of the workload in IoT. And you can have Cortex-A as your application. And this increase and the wider range of application that a IoT device can have. So also with that in mind, security is also a lot of on the news today. And basically, we will try to show what in this aspect can be increased and updated on this field also. And why Linux and try to make it on these kind of systems also to make it work and so on. So in here is more or less like a hotline of hardware system of review. This is an example. It's a platform that ARM developed. It's called Corestone 700. And it basically has a secure enclave, class M. Normally, it's an M0 device. Then it has firewalls between all the components in the system. I have an A class subsystem. In this case, in this platform, it's an A5 or A32. And you can have a variety of Cortex-M doing the all the tasks that you want and need to do even in real time constraints and so on. So basically, they have a firewall dividing all these access and normally the firewall is set up by this secure enclave that set up everything including memory and RAM and ROM and what can see what and so on. It's a constraint system regarding the specifications. And this is basically what is used. So we try to reach to a definition of what a tiny system would be. And in this case, we try to constrain the memory to four, eight megabytes because four, really the workload that you can do on four with Linux in class A. It's really limited. Eight on the flash to allow you to have a more robust OTA system like A, B, and B image. So you have this kind of a mix between the Cortex-A and M's doing different kind of workloads in your system. And this can be customized for IoT agents that normally will be running and you can have different SOC solutions based on this kind of architecture. Regarding software overview, so on the secure enclave we can have a firmware, a bootf firmware. We are trying to port it, TFM also, to run in here. So this will be the responsible to set up and put everything in memory and then we'll take the other CPUs from reset state. And the communication between these devices is handled by a message handling unit. And on software level, you communicated using, for example, OpenM is what we have today. Doesn't mean that needs to be the solution for this. So then you have the class A where you can have some trusted service in the trusted execution. Linux kernel with XIP, executing plays, root FS, and an IoT client, for example. And then you can offload to the Cortex-AMS, what any other workloads that you can have it. So what we tried to do here was, in this first stage, was to integrate already stuff that is there, out there, and try to make it the integration. So we started using Try2Nify, inside ARM, the build system. So Yocto was selected for this task. We created our own distro around it and tried to build the image using the tools that Yocto allowed us. So at the end, we have that image that you can see there. So the output image, you can see that the kernel XIP, more or less 2.2 megs, the weak image, it's 8 megs because we are creating all the partitions that we need in there, so it's using the whole space that we have. But the Chrome FS XIP is 1.8 megs. Regarding the kernel, we're trying to use what it's upstream. We don't have any special kernel in here. We didn't change nothing yet, but as we will try to improve this kind of tenification, we will for sure do something more extensive on this part. But so we needed to add some options to disable, for example, multi-arch in ARM, because with that, we cannot use kernel XIP. We tried to reduce the sets of CPUs that we support on this configuration. We enabled some too, and you use a very reduced F config. So this is more or less like what we have the results of run, or after a boot of a system. You can see that the total, this is the kernel memory line, and this is the free command after the system is running. So without any load, it needs to be set, but we have a system with 1.8. And a lot of, not a lot of memory available, but we can run applications in there. So regarding the root 5 systems, we choose ChromeFS, because it allows us to use XIP also for the root FS. So we choose it, and we want to thank Nicholas Petr, over there in the back, for his work on this part. It's working out of the box very, very good. So we didn't have any issue with this. So it has direct access flash. It doesn't go with the RAM and caches and everything. You can just overwrite and go over that, and you don't need to increase your RAM users, because of this. So for the read-write file system, we were looking for solutions also. But one of the file systems that looked better for us, and it's more compact, and it's done in taking an account, and it was development thinking on real-time OSes. So memory allocations are really little, and you can more or less know what you will expect at the end of the day. We choose this little FS. It's an ARM file system that is being used on several real-time OS. It has all these features that normally are a good file system for these kind of devices needed to be, it's power loss is resilient, we're leveling and bounding. It has a design, and it's a block pair update. It's very compact, and it's easy to use in this kind of environment. Right now, I'm trying to port it from scratch to Linux, halfway there, a little bit more. Try to upstream it, let's see if it landed there or not. But we will try to make some measurements and see even though the specification also for this file system is in evolution, we will try to implement it and try to bring it as a spinal nor, yeah, only 8 megs of nor flash. We are charging it. So this is halfway there. Just adding some more and then do all the tools that we need to create to have it on the upstream kernel. We need to have fuzzers. We need to create a lot of user-land tools that support and test all this kind of system. So I'll try to show you. It's just running on. So basically ARM has its own models. I don't know if anyone knows what models are more or less like Qmoos, but ARM has a concept of emulation of their systems using software. So this is basically running on the platform that I told you ARM corestone 700 FPP. And I will just run the image that we saw there. So I'll try to explain. So this is based in the middle. You have the two. This is a Cortex 832 running in emulation. And on top, you have the Cortex M0. Running the Cortex M0 there, it's the secure enclave that just allowed the A from reset. And you have an M3 in there that it's not out of reset. So I will just let me try to take these away from your front. So this is the logs of the secure enclave. So the secure enclave of the boot ROM on the secure enclave just loads everything in memory. The BL32, the TB, and then it brings out the OS from reset. And then this is the boot log of the kernel with this image. It has a constraint system. But you can see that you have. And this image is completely built with the Yocto. This is available for you to download, to build from scratch and everything. Regarding the model, that part I don't know. This is you need to check up in ARM how to get the model. It's not so easy, as I believe. And basically, that's the system that we have run. Then after to have more features, we for sure need to increase here the memory usage. And for sure to have some dynamic on the system. But as a reference booting system, this is what we reach now here. So regarding what we will do next, for sure finishing and try to upstream little of us if there is interest to have it in a kernel. I think we'll be. I saw, for example, yesterday, a presentation from Airbus where they also have something like this interest. Instead of M class devices, they have R class devices to offload critical stuff to Cortex-Rs in there. So it looks like there is interest in these kind of systems. And this kind of, and even the Cortex-R that they are using are MMU less. So a file system like that maybe makes sense on a system like that. There are a lot of compilation optimizations that we can do. We will start maybe try to use Clang to use LTO jointly with them too. Also, there are ARM team. There is development feature for Clang that is basically outline. It's more or less like the inverse of the inline to save space. So they already reach good results in Zephyr. 10% reduction in size. So looks like promising stuff in there also. They didn't try on Linux kernel. But maybe that can be also a good optimization part. And then when we reached to some specific workload necessity, we can target and try to make it really, really optimization on that workload. Right now, this is a reference platform. And it's not specific to any workload. But we're trying to make as ARM a generic platform. So we won't have it like that. So basically, that's it showing the work that we've been doing on this kind of. You can have all these. In here, you have the resources where you can fetch. There is a complete Yocto builds layers. You have a meta-ARM layer. In top, you have a meta-Corestone 700 layer in there. You just need to fire up the normal Yocto commands. And in the end, we'll reach an image like the ones that I showed you. And you can also check the product specifications that ARM already have in there. Regarding ChromeFS GitHub from Nicholas Pete, I have the tools and have what you need to know. And littleFS, it's on ARM embedded tree. He has a very nice comprehension spec and description of the file system. So it's really well documented. So basically, that's it from our side. Questions? Yeah, but since I don't know what Kimu has in terms of running this kind of stuff like 2Ms and the MHU communicating between, I don't know, the emulation part, if it is ready for this kind of, sorry. Ah, OK, OK. So the question was, if we thought to run these on Kimu instead of using ARM-specific models that are not so available to everyone. And my question is, we didn't try it. And I don't know if it is prepared Kimu to have all these infrastructure that we need to emulate all these software. Sorry. Ah, OK. Yeah, we used, for building, we used as main distro. It's on top of Poke Tiny. Basically, if you go with Yocto, you have Poke and then there were work to create a tiny image. It's Poke Tiny. And this generated with the busybox and so on. So a muzzle, muzzle. It was on the slide. I forgot to tell, but it was on the slide. It muzzled on this. Sorry. Yeah, that will be the, we are, so basically that is a way to do the OTA, the upgrade. So basically, our image could fit in four megs of spinor. We are just giving eight to guarantee that if anyone wants to use that kind of OTA. No, we are not, we don't have an OTA. OK, thanks. We don't have that. I think that is very specific to the implementation. That's the other case where, no, not that, not that. Yeah, so basically with access with the spinor directly as mapped, in memory mapped, spinor. So the spinor is memory mapped. So you can, if you have a AB system, you can directly download it or because these are XIP. So it's uncompressed and everything. So it needs to fit in there. And if everything goes wrong, you still have. But if you go, I think on this, it makes sense to have an AB OTA solution. Yeah, yeah, it's already there. Yeah, let me take your mic. OK, maybe I can tell a bit about ChromeFS because I'm the author of those modifications. So the thing is, within the file, you can mark part of the file that you want the kernel to access with XIP. So for example, if you have an ELF executable, the read-only segment will stay in the flash and will be stored there uncompressed. Whereas the data segment, which is modifiable, so it has to be loaded in RAM, that part will be compressed on the flash since you have to copy it anyway. So why not store it compressed? The tool that creates the image right now, it has the ability to detect those segments in the ELF format. But it could be extended for other file formats. For example, if you want to notice that you have a JPEG file, which is already compressed, you don't have to try to compress it again so it can be accessed with XIP. So all those things are already upstream. There are in the tool as well. Is it each block or just the ELF section? It's each block which are part of some of the ELF sections. So you can do it block by block? Yeah. So I guess it needs to be in the tool. It's in the tool right now, but the only thing I implemented is to decide which block are part of specific ELF sections. But it can be adapted to whatever you want. So it's done. It's there. OK. Thank you. They are on there. Tushar, you have the. No, first you, Tushar. I'm not. Tushar, Tushar. Have you ever considered about using a unicorn for the size reduction? Sorry? Unicorn, maybe long place. I ask the question, long place. OK, never forget about that. Any other questions? So basically for upstream, just missing little affairs. Everything else is already. So you can boot it with DCS on Linaro repos. If you go get Linaro landing teams working, you can grab all the source codes that I'm running here. You can grab all. It's built from source, built from scratch. Everything is upstream. The only thing missing that is also not running on my demo, it's little FS support. It's the only thing that is not running everything else. You can download it with the source code and everything is upstream. Even support for this kind of platform, it's on TFA already. So it's upstream on TFA. You would, we have two or three out of three patches, only to make some last minute changes on memory addresses and so on that we moved around a little bit to fit on this. But you can go and check the Yocto layer that has all the recipes. And you see that all rep repos are upstream repos. We don't have anything. We are working to create a meta arm. It's already, you have a mailing list on meta arm called, on the Yocto open embedded called. And it's already, I think there is already a placeholder for meta arm layer. It will be upstream to open embedded real soon. Right now it's on there because we are merging also other arm other departments also had their implementation of the same recipes. So we are trying to join everything to go to open embedded.org to have that. You will find all the arm related recipes. And we will try also to port all other platforms from arm to be upstream directly to open embedded. We use this platform for our development but the changes are really generally for the platform. Yeah. FPGA landed last week in our tables. I don't know. This is more arm than software. Also 700 is a reference platform. You can contact Tom, actually, to buy that. And there is a PGA for that and there is a model for that. So we have a couple of partners. Yeah, you already have some marketing stuff in there. And you can search in there. Any other questions? Thank you very much. Thank you. Thank you.