 Hello? OK, I think I'm going to get started. It's better to finish on time or early on than not finish at all. So for those of you who now know me, my name is Alejandro Hernandez, and I am currently the Yachto project tech lead at SILINX. And I've been a Yachto developer for a few years now. And I'm going to present to you this one bill to rule them all, Building Free Artists and Linux using the Yachto project. There's a Tolkien reference there, of course. So the outline of this presentation, I divided it in three parts, basically. The first is a very small introduction on why this is important. Talking about heterogeneous systems, RTOS is Linux and Burmese applications and how their workflows differ. And the second part of the presentation is going to be on the open and better development that happened for this to be achievable. Free Artists on the Yachto project, what is new live in lip gloss, how that's wired into BitBake, and then actually creating a layer, Meta Free Artists, that can be used. This layer has a class, recipes. What's the BSP? What's an application? How can we run it on QMU for testing? And actually, how can we run automated tests on these applications using the open and better infrastructure that already exists? And the third part of it, it's actually how can we achieve one bill to rule them all, which is where I'm going to touch on concept of multi-config built and multi-config dependencies. So first of all, heterogeneous devices, I think there's more and more every day, we're seeing devices that have a myriad of different architectures inside them. The obvious silencs example here is the virtual architecture in which, well, silencs is an FPGA company. So it has an FPGA fabric and also has, which is called the programmable logic part, and also has a processing system part, or PS part, which is the part that I work on that runs Linux. It has an A72 Cortex-A72 processor, which is the application processing unit in that runs Linux. And it has a real-time processing unit in an R5 that can run on our TOS on it, along with a microwave, for example. And well, the reason for this is when I was in grad school, I had this professor of computer architecture, and he was explaining to us like pipelining, or hyperthreading, or something. And then after explaining, he would ask us, what's the right answer for this? And then the answer is almost all the time it depends. Like, there's no single answer for your problem. For some application, Linux is fine. For some other application, an R2OS is fine. You might need deterministic behavior or something. For some other application, you can use Burr Metal. So there's no one single answer that's gonna solve all your problems. And yeah, in the embedded space, we have this, right? Like we can, even on this device, you can run different things depending on what you want. You can run Linux and an R2OS. You can just run an R2OS. You can run Linux and a Burr Metal application. You can just run Burr Metal. And the problem comes here where they all use different workflows and it becomes really hard to get everyone together and be able to develop this in an easier manner. So Friartos and the OCTA project. The point that I'm gonna prove today that I'm trying to prove today, is that you can do this. And I used the QMURMB5 machine. When I started this, it was QMURMB5. But it was moved now to QMURMB5, which is the Versa-Titanline 2.6, I think, BSP. And that's already an OECore. That's the reason why I'm using that. Now, the other thing, if you look at Friartos documentation, you're gonna realize that what you need to build an application for this, it's the Armour and Better Toolchain. And they just say, just go and download it from somewhere. And once you get the toolchain, you look at it and what's in it. So you got the GNUC compiler, you got Binyutils, GDV, and you got NewLiv. And I think the first three components were pretty much all familiar with them. And the last one, we all may not. So I'm gonna put, explain what they say on the webpage, it says, NewLiv is a C-Library intended for use on embedded systems. It is a conglomeration of several library parts all under free software licenses that make them easily usable on embedded products. And if you translate that to English, it means that it's a very bare bones C-Library that it's meant to be used on either a bare metal application or an RTOS. So that's what's on the Armour and Better Toolchain. So some of the previous work that I'm not gonna focus on this presentation is what it's actually getting, NewLiv and LibGlass recipes and the wiring, this DC-LibC NewLiv wiring that happened on Open and Better Core to achieve this. It's just worth mentioning. And by the way, NewLiv is the C-Library part and LibGlass is the BSP part in a very high level. NewLiv contains a lot of WIC symbols, which allows the program to link and then on the LibGlass part of the application, you override whatever, depending on the hardware you have. And then the other part is like creating the actual layer, right? So Metafriartos is the name of the layer. I had to create a distro for it. That the problem comes here where in Linux, you have an OS and you have applications on top of it, but in an RTOS, the RTOS itself is the application. So that's where things become a little confusing. And then also I try to abstract the concept of the OS, the BSP for that kernel, for the Friartos kernel, and what the application part of it is. And to achieve this, I use a class, which I'm gonna show you in a little bit. And lately, I'm sorry, lastly, what I wanted was to be able to run automated tests on an RTOS application using the open embedded testing infrastructure because that was already there. That's being used every single day on the auto builder for Linux and there's no reason why that can't be used to test something else. So first the distro, the distro, that is a distro.conf, it's not very complicated. It's pretty much a placeholder. That's just the name of the distro. And then the important part there is the tclibc variable that specifies the build system that is gonna, we're gonna use newlib as a C library. On a normal distro, like on poc or something, you would see either like muscle or glibc in that part. Let's see the time. Okay. So then this is the class, the Friartos app class. And the idea here is that be able to provide a single class that recipes can inherit. It makes it easy for different applications to be developed in this manner, right? The, I declare some variables here. The first one is the first Friartos version, which is 10 to one, which at least until the beginning of this month was the latest. SRCRI is where it's gonna get the source code. And as you can see, there's only two there. One, it's coming directly from Amazon Friartos Get, which is the official one. And the other one is coming from my GitHub because that's where I get the BSP part of it. And then I just, these are just the checksums. There's nothing funny there. Here's when things get a little interesting because now that I got the BSP separated I got the kernels, right? And now I have a BSP or a port of Friartos that I want to use. And that gets downloaded from a different repo and basically I have to copy it to the kernel code so it knows about it, right? It knows it's gonna build that application. I do have to declare some variables here so the make files know where the code resides and stuff like that. And then I do create some tags for it to make it, make bit big things that is building an actual Linux image basically. So for example, I need a do image task. It does nothing, but I need it to exist. Part of the class as well is the QMU wiring that allows us to run, use the same infrastructure as I said, from open embedded to run QMU for a different operating system. So in this case, basically I'm saying I'm gonna use QMU system arm and my architecture is gonna be versatile PV. That's the interesting part of it. I'm gonna use a binary as my kernel. And as I explained here, this whole next part is necessary to create the wiring for QMU. If you look at your deploy directory once you build a Linux image you end up with your image and then a file that ends with QMU bootcamp and it contains the configuration that run QMU knows how it's gonna run it. So this part is necessary for that. And while this might seem a little convoluted, the idea is that no one has to look at this. The class, you should just inherit it and then focus on your application. So how does a recipe actually look like? And this is a recipe for an application. This is a complete recipe. So it inherits the class. So you don't have to take care of all the QMU stuff and anything like that. And then I have two sources here. One is that, well, in the class I have the kernel, right? So I get the kernel now from Amazon. I get the BSP from somewhere else, the port for Versatile 9.26. And then here I have the application code, only the application code. And I just have a small patch for the make file to use NewLiv and that's pretty much it. The application that I used, I got it from an open source project which had a port for the ARM 9.26 EGS and I added some extra functionality to it. So whatever you find on this repo, it's this plus some extra functionality to use the Task Notify API from free artists to wake up a task. There's two recipes on the layer right now. One is where you get the source code for the application from a Git repo. So this is called, this is actually freeartosdemo underscore git. And then the other one is freeartosdemo-local. So the application code itself, it's locally on the file system and it looks like this. These are all the files that are necessary and that's only the part of the application. It doesn't have the freeartos kernel, it doesn't have the BSP, the port, nothing like that. It's just the application, right? And that's the whole recipe, it's simple. This is what the tree of the whole, I think this ran out of battery. This is what the tree of the whole layer looks like. And as you can see, those are the files that I just showed you. Two recipes and the distro come there. I'm gonna show you a demo of how this works and I thought it was better to use a video. Not that it wouldn't run, but I want to stop at some point that I think they're interesting. So I have three videos, hopefully you can see it, right? So first of all, this is just a clone of Pokey, that's it, I just did get clone and then the Pokey repo, along with the meta freeartos layer. So that's very basic. After that, it stores my environment, just like as you would normally do. I'm gonna show you what my config, my local.conf looks like and it has, I'm gonna pause it there. So it has a machine, which I, like I said, this is for QMAR B5 for testing. The distro name, which is the file is gonna use that I just showed you before. And then since I'm gonna be running automated tests, as you would with Linux as well, you inherit the class test image and then you, I created a test suite for freeartos, which obviously it's not the same as Linux. So that's what you decide what to test. For your application, you would have to write your own test. I just, that's just zooming in to, so you can see it. Also there, just FYI, I already, like this, this is gonna be built from STCache, so it was faster. I just didn't wanna have to type all this and lose time on that. So there, I am gonna build the local demo, right? I call bitbake freeartos demo local. It parses the recipes. I'm gonna pause it there for a second. So you can see here in the target says, it says that it's building the EAVI, which is the embedded tool chain for ARM in this case. And again, the distro name is there and stuff like that. So I'm gonna let it build. It's quite fast because it's from STD. And this has way less dependencies than Linux, so it builds way faster anyway. So it runs all the tasks for the recipe. And at the end, that's it, it just built it. If I do a list on my deploy directory, I see that I just built a binary, an L file, a manifest that's needed for the test cases. And like I mentioned, the QMU boot.com file, which is necessary for Run QMU to understand what it's gonna run. So the next step is, just after you build a Linux image, if you wanna test it, you just type Run QMU. And I just built free RTOS and I'm just gonna type Run QMU and that's it. That's all I'm gonna do. I paused it. And I'm gonna pause it again there. So there you can see the full command that QMU is using. Again, you can see, for example, the machine that's using is versatile PV, 128 megabytes and stuff like that. Everything, all of this stuff, it's taken care of on the class. And then it starts running the actual application. So free RTOS sample application, that's where it starts. And then it says the text may be entered using a keyboard and will be displayed then when enter is pressed. And then I have a periodic task that runs every 10 seconds. I have another task that is just called task one and it runs every one or two seconds. I don't remember. And then I have another task that it's blocked. And I have to type something and whenever I type something, that task will get unblocked. So here task one run and then the other task got blocked. Task one run again. And then I type A and it unblocked the task that was blocked before. So we receive our notification, it unblocked the task and then it blocked again. So it's waiting for something else and I type B, same thing happened. Task one keeps running and then I type ELC 2019, I unblocked the task again and then it over and over again, right? And then I think, yeah, the period, it's been more than 10 seconds, so the periodic task that was supposed to run after 10 seconds runs again, deterministic behavior. So there I just exit wrong QMU, just normally as you would. And the next part of this is now I wanna have this run, I developed my application, I want it to run automated test on it and I wanna make sure if something broke, someone broke the code and this is important for me and I can run it every day or whenever you want to, right? On your CI. So the way it works on Yachto is that you call bitbake and then the image name and then you call that see test image. That's, and then you decide the test suites that I just showed you before and that's how we test, that's how Linux has tested for all the different applications. In this case, it's gonna test the Free Arts as one. Again, oh, this is gonna be building a bit more dependencies because test image actually requires a bit more extra dependencies. And then it's gonna run the test image application and it's gonna run it for 15 seconds. It's at 11, I don't know if you can see it but it says 11 seconds there and then I put some warnings there that are not necessary. I just wanted it to be yellow. Basically it says the test passed and it was a very simple test. I'm not here to tell you how to write your test but basically I just counted the amount of periodic test that happened in 15 seconds and that to me, at least I asserted that it's still working. It run the program and it's still working. I'm checking the output of QMU and it's still working and then I get a result and it says the test passed and you get a summary exactly the same as you would with Linux. Okay, video number one. Now, if I go to the next one. Okay, so the second video is, I hope everyone gets this, it's a joke. I modified the local version of the source code just to show you that you can easily modify just the application code. And everyone's familiar with knock-knock jokes, right? Okay, hopefully. I can't take credit for this. I just Google programming jokes and it came up and it's in-fitting. Anyway, so there I am just showing you that I modified a couple of files in the actually just modified main.c and receive.c. I can't show you the changes because otherwise the joke will not make sense. But anyway, I just modified two files. And then after modifying the files, I am gonna run BitBit again and rebuild the application, which obviously doesn't have to rebuild the tool chain or anything like that. It's just the application. It's really fast. So yeah, it unpacked it again and it built it, right? So I have my new built FreeRTOS application there. And when I run QMU, okay, so again, knock-knock and then who's there, right? Who's there? Java, okay. Don't take it personally, it's just in-fitting. The point is that you can modify your application, it's still gonna work with the BSP, right? And then, how am I on time? Okay, so after that, so the one build, I can move again, the one build to rule them all, so how can we achieve this actually? Because right now I just show you that I built FreeRTOS, but I just built FreeRTOS and that's it. So now I'm gonna talk a little bit on how does this gets all wired in. So for a device like, I'm gonna go way back. So for a device like this that has multiple architectures and that has multiple OSS or applications or something, how can you just use one single build and then get everything that you need for that? So this is where multi-config builds come into place. This is taken from the mega-manual of the Yocto project and it says you can use a single bid they command to build multiple images or packages for different targets where each image or package requires a different configuration, multiple configuration builds. That's just the hierarchy, the file system hierarchy of what you need. Usually you have your build directory, you have your com folder and a local.com. If you want to use multi-config, you just add a multi-config directory and add whatever multi-config you want. In the case of the manual, it's using an x86 comf and unarmed comf. And where it gets a little more complicated is the multi-config dependencies part. So I'm not gonna read that because there's a lot of text in there, but the point is that let's say if you want to build, for some reason, let's say you want to build your Linux and your Linux depends, for some reason, on your free artist, this is the way to achieve it, right? And the syntax is a little convoluted, but once you get used to it, it's not that bad. The idea is here, for example, on the last line it says, do image, the bar flag is MC depends, MC, which stands for multi-config, and then x86, arm, core image, minimal, do root of s. So I'm gonna translate you that, what that means. That means that the task, do root of s, from the core image, minimal, recipe, from the arm config is depending on the task, do image, from the x86 config. So I'm building an x86 and an arm, different configs, and that if I do bid bay, core image, minimal for the x86, the arm one is gonna be built as well. That's just the example that's on the documentation. So how can we build Linux and free artist? And don't get me, I don't wanna confuse people. This multi-config builds, they don't have to be for different operating systems, they can be for anything, they're literally just a comp. You could be building the same architecture, you could be building, let's say you wanna build, for the same architecture, you wanna build two different distros, or the same distro and one distro, you wanted to use CSV in it, and the other one wants to use a system D, right? That's what they're for. In this case, I'm just taking advantage of that to use, to be able to build two different operating systems at the same time. And so again, I just see it in 2Poke, whatever, when I clone it, I source my environment, and I have a specific multi-config environment there that I have. And then if I'm gonna look at what my local.comp looks like, and the important part here is this bbmulti-config variable, which declares, it tells BitBake, what am I gonna parse? In this case, I name my multi-config file, arm-free-articles. And then I created what I just explained to you before on the dependencies. I said, the do-image-task from the free-articles-demo recipe, from the arm-free-articles config will depend on the do-image-task from the default config. Please look at this, there's nothing here. It's an empty string, that means it's a default config. The one coming from local.comp. So if I do a less-comp-multi-config, I'll have a file, like I said, that's named the same as what I declared in this variable, arm-free-articles. And then if I look at that file, what it contains, it says it has the machine that I'm gonna be building that for, the distro that I'm gonna be using, and the temp directory that's gonna be used for that. So there's three lines on that config, that's it. And now, I'm explaining that I'm using, I'm gonna build the default config, the one for local.comp. So I say bitback mc, and then column, and then nothing would mean to the default one. And then after that, I'm gonna say core-match-minimal. So what's gonna happen there, technically it's, I'm asking just to build core-match-minimal for local.comp. But since I have this dependency there, it should build both of them at the same time. I passed it. So here is the interesting thing. Here's where the configs are shown of what you're building. On one side, on the local.comp one, I'm building QMUX8664, I'm building the distro Pokey, and I'm master, and that's it, right? And on the second one, I'm building the QMU-RMB5 in the ARM config, the freeRTOS one. So those two configs I'm building, and it's gonna be really hard to pause at the right time here, but, okay, so that does it, that's enough for me. So here is the run queue of the tasks that are running, usually, and as you can see here, I never put anything about ARM when I try type bit big. I just said core-match-minimal for the default one. And in the run queue here, I have two tasks. One is running for the local.comp, which is core-match-minimal, and the second one it says MC ARM FreeRTOS demo. So it automatically started building the other config because of that dependency. And once it runs, it keeps running both configs. Obviously, I did this on shared state, so it's really fast. It creates a Linux image, and there you go. So now, I'm gonna look at the deploy directories, and if I look in the deploy there, I can see I just built an image for QMUX8664, normal core-match-minimal, no changes. And then if I look at the deploy directory that I defined for FreeRTOS, I can see that I also built a newly FreeRTOS binary at the same time. Now, here's things would get a little bit confusing because I just built two different configs, what if I type wrong QMU, what's gonna happen? Well, I think it's a little obvious. It's gonna take the one from local.comp. So if I just type wrong QMU, it's gonna run Linux, and the core-match-minimal that I just built, and it works just fine. I think I let it boot there. You can do it, there you go. So I'm gonna get a login prompt there, I built that, and then I exit wrong QMU. But also, the QMU wiring that I keep saying and saying and saying is that you can pass that as an argument to run QMU. And if I pass that as an argument to run QMU, the QMU boot come from the FreeRTOS one, it's able to run that as well. You see now, I just run run QMU for different OSes in like three seconds. Okay, I think that proves my point. Now, what time is it? Okay. So future work, there's some multi-config optimizations that I have to do. Some of them are sharing estate cash between multi-config, which is gonna be a lot easier now with the changes that happened in CS, which was just released a couple of weeks ago over the last week. And then there's parsing optimizations as well. There could be more ports or more architecture supported or BSPs, whatever you wanna call it, on the layer, on the Meta-FreeRTOS layer. And I'm sure there's some fine tuning on the layer that has to happen, but I just haven't gotten to that point because I don't have more ports. Once you get some more ports, you test it and you realize, oh, I'm missing this part or this other part. And I also have to upstream some of the test infrastructure for FreeRTOS so it knows how to test it on open embedded core. And yeah, I mean, the takeaway from this presentation is that the OctaProject and BitBake specifically provides scalability. I think a lot of people complain on how it's complicated to use at the beginning, but I think it's, it might be a con, but the pro is that it provides scalability, allows you to do some kind of thing like this. FreeRTOS was just used as a test case. It's just what I found. It could be anything. You could run a bare metal application. You could run Sefer, whatever you want. It doesn't matter. So we could technically support more OSS or application open embedded. That's a question that I'm not going to answer right now. And the idea here is that you unify workflows across teams within a company. If everyone's using the same thing, you can, for example, produce. This can produce an SDK and you have control over the tool chain that everyone is using and that gives you reproducibility. So whenever you, someone, hopefully not a customer, someone finds a bug and it comes to you, you know exactly what they're using. Because otherwise, they might be using some different tool chain or some different flag and it becomes really like way more complicated. So this is my last slide. And I'm going to run it. I miss type tanks, but thank you guys. I just run the FreeRTOS application. And yeah, thank you. Thank you for attending. Does anyone have any questions? We have like three minutes. Yes. You could. Yeah, actually, you could. It depends obviously on the device. But technically, the binary, the FreeRTOS image that gets built actually gets an RPM. So you can technically install it on the root file system of Linux and then you can flash the other memory or whatever in your own way. So it's possible. I have not had time to try any other ports yet, but the idea here is to abstract that and to make it easy to get ports there. M0, RISC-5, it should not be that complicated to do. So the wiring, what I wanted to provide was a wiring there and adding more ports to it should not be at least not as complicated as it would be on other occasions. Well, each multi-config uses its own cross compiler. So it doesn't interfere with one another. Yes. I think the fact that the TC-Lipsy new live is there, the wiring, it would make it work now. I'm actually going to take a look at MetaSephora, but it should not be complicated. Yocto is able to provide you a tool chain with, and it's just a tool chain. It's not easy, but it's still no rocket science. So yeah, does anyone? Yeah. Yeah, I will share the slides. I was just having problems with the video because they wouldn't let me upload it. But yeah, I'm going to upload them. Sure. Not immediate plans, but it's kind of that it would be a nice road to take. Like it would simplify things. We just need to port it to the different architectures. R5 in this case. Well, yeah, in that case, there would not be necessary because the tool chain, you would get the tool chain from here. And it could. It could, yes. I think we're out of time. So thank you guys for coming. I hope you enjoyed it.