 Hello, I will talk again about the Yocto, but not really for a product for some specific tools we can use additionally on an image. I am a CTO of Smile ECS, Smile is a French company in Paris and several towns in France and some place in Brussels. I am a teacher and long term user of open source software. I am teacher, writer and bad English speaker. This is my favorite competence. I will talk about using build system for our industry all. There was several Yocto presentation today, so I will be very quick about the introduction. I will try to do a demo. It will be the third demo today and maybe the third demo will fail or I don't know because the two previous demo failed. Not for me, but no. The robot was broken, maybe the pie will work, I don't know. We will create a recipe, not for creating a recipe, but to use, in order to use some tools on the recipe to modify the recipe to update the recipe. We will try to build a kernel module with Yocto, inside Yocto or outside Yocto. The last part, maybe the most interested part is about CI, for example testing packages or testing functionality on an image. You can write some scripts to test functionalities. I will do lots of demos because when you do demos you don't speak a lot, so it's okay for everybody. When you have an industrial project, you have some necessary tasks, but costly tasks such as installing the VSP from Yocto, for example, or BuildWoot or PatexDist, which is the next conference. You have to create the SDK for building apps, it should be done with the same tool. You have to develop your applications, which is your job. Most of the time, nobody wants to sell and to buy a Linux system, it's not interesting at all for the people. They want the system to work and the application to work. And then you have to integrate and maintain the system in the long term. It's strange because it's not the last version of the slide, I think, but it's not programmed yet. So a build system, such as Yocto, is not a development tool, but it's a tool to generate the SDK, to create the VSP and to create tools in order to manage the system, the image and the install system. And I will show some tools to debug, not debug, but develop inside Yocto. But most of the time, Yocto is not a tool for development, it's a tool for integration and development is done outside Yocto. But it's still possible, for example, to compile kernel modules and to test to remote debug applications inside Yocto. And the developing application needs some additional steps, such as CI, to test packages and to test an image for complex systems. So some, the most tools are Yocto, B-root, OpenWRT, P-TXD, etc. But Yocto is the most famous. Today, all the conference, they spoke about Yocto. And the next one, except the next one, we will speak about P-TXD, but there are lots of Yocto users around. So Yocto is based on Open Embedded, it's a prefix for our international system of majors. And the Yocto main concepts are the metadata, the recipes, the extended recipes. So we will create the extended recipes with tools during the conference, the configurations, the classes includes. And the layer, which contains the metadata. And for building a recipe, you have to do a bit bake. Bit bake my recipe and we create a package you can install. So you can integrate the package directly in the image. Or you can install the package using package system, such as IPK, RPM, or DEB. My system, as it is a small system, I use an IPK. Ok, this is the principle of Yocto with the layers. And you have the in yellow, the Yocto layers, and then you have to add the BSP, example for the Raspberry Pi, etc. So if you want, for example, if you want to build a Yocto image for Raspberry Pi, you have to download Yocto, actuellement, the pocky sources. You have to get the Raspberry Pi hardware layer with the same branch. You have to create a build environment. You have to add the necessary layers for the first test. The only necessary additional layer is the Raspberry Pi layer. And you define the machine and you create a very simple image to test the board. And you put it on an SD card in case of a Raspberry Pi. You see that's an example of a very simple recipe, a very simple program based on CMake. We can build with the distribution. So I will show the build for example. I will remove the build to show there is no problem, but I will build it again. Ok, so if you build the recipe, you can see the package created with a single binary, which is on the board. I was afraid about the demo so I put it on the board before. Ok, well. In Yocto, there is a very interesting feature, which is a bbappen. With a bbappen, it's a quite extension of a recipe. So you start from a bb, a recipe, and you add a bbappen with a data, for example patch, etc. Or configuration for BuzzyBooks or Linux kernel or anything you want. And you can generate a different package with different data based on the same initial recipe. So the most famous example is the splash screen. So the standard splash screen provided by Yocto. You update the logo and you get a new logo. For example, with Yocto logo or Raspberry Pi logo based on the... If you start with the open embedded logo. Ok, the first very simple tool is DevShell. DevShell is just a shell you can start from Yocto to modify source code. So for example, it opens a new terminal so we will start with a recipe. And so we type bitback-devshell by Paximake, for example. You get a new terminal, very small. And you can edit the code, for example. And you don't use bitback tools, you use the standard tools. For example, you can copy the binary to the board in order to do a small test, for example. Yes, no. Yes, start. Problems are starting. No, it's not 4. It's 3. So there's a new example modified by the simple tool. Simple, but it's not that very interesting, but it's a possibility to do a small test. Ok, the next tool, which is much more interesting, is DevTool. So DevTool is a way to modify a recipe, not modify the sources inside Yocto. So you start DevTool on an existing recipe, for example. You can create this recipe with DevTool, but... And it will create in another layer, it will create a BBAPen, to, for example, to apply a patch to the initial recipe. But you can do that by hand, for example, if you create a new layer and you edit, etc. But if you want to do in a simple way, you can use DevTool for that. There are lots of functionalities in DevTool, but this is a very simple, example I can do in some minutes here. So for example, instead of this shell, I use DevTool, not with BigBake DevTool. Modify. Ok. So when you, it has a local directory, which is workspace, which is called workspace, where the DevTool copies the sources of the recipe. And you can add, and it's automatically add the new layer to the list of the layer. Ok? So you can go to the workspace. And the main difference is that the sources is managed by Git. So you change the source, DevTool, instead of the shell. You commit the modif. DevTool demo. Ok? And you just have to create a new layer. For example, create a new. Metaphos.dem menu. It exists. I will remove because I want to be honest. Ok? I create a new layer. I add a layer. But it's an empty layer. Ok, 3. Ok, there is nothing except some small example, which is not useful for us. And then you can DevTool. Finish. MyPack CMake. And you just give the path of the new layer. Or the new layer. Ok? So it's a bit... It creates everything to create a BB happen for the recipe. Ok? So as I said, you have to remove the workspace, which is not this one. It was the wrong line. You remove the workspace because it's not useful anymore. And now, you can build the recipe again with BigBake. And you should notice, if it works, that the version of the release will not be upgraded. Ok? But it's not a problem. Yes, because... Ok? I forgot something. So you have the... You have the result of the... of the modification. And the best way is the following, is to create... to change the version of the recipe in the... to force it to compile again. So with the package system, you can update the package much more easily. Ok? So you have a new package with the R1 version instead of R0. Ok? With Yocto, you can create... It's a very interesting feature of Yocto. You can create SDK, which is called Extensible SDK. You can install very easily on another PC Linux system with quite the same distribution. It creates a shell script, which includes the SDK. And you just have to run the shell script to install the cross compiler. And the SDK is mostly the cross compiler, a cross debugger. You have an Eclipse plugin. You can use emulator if necessary. And you don't need to know Yocto to use it. And it's very interesting because in most of companies, you have a team integrating and testing the packages with Yocto and system knowledge. And most of people, they don't know anything about Yocto. They build their own pack system. They build their own programs with their knowledge. And they give the sources. And once they test it, they give the sources to the Yocto team to integrate the new version as a package. Ok? So there is a specific documentation in the Yocto documentation about the SDK. A simple way to create the SDK is to use a big-peg mit-at-all-chain, which creates a basic SDK. And you just have to execute the shell script to install the SDK as follows with sourcing a script which is provided by Yocto. For example, I can do it. It's already installed, but I can do it. So you source the OPT, OK, 3D environment. And so the $cc is modified. So it's not a .co. Ok. But most of the time, you may have to integrate some specific libraries or scripts or anything you want. For example, when you use Qt, you have Qmake, you have some scripts. If you use Xenomai, the real-time extension for Linux, you have some tools and specific libraries. So you want to integrate the libraries in the SDK. And for that, you create an image, for example, an image including Xenomai. And you use the populate SDK function to get the SDK, which includes the same libraries as the image. And you can also include the kernel sources if you want to develop kernel modules with SDK. So you can do everything outside Yocto. Ok, so for example, if you want to compile a module, you do make kernel SRC equal, etc. And you give the pass to the kernel sources used by the board. Ok, for example, with a simple module, it's a kernel, it's a still yellow, and you copy the module to the board. And you load the module, for example, in smode.hello.q. Ok. Ok. Ok. Ok. Ok. Ok. Ok. So you have the module in the board. And there is a functionality to do the same with inside Yocto. And there is a directory which is used for the kernel recipes. If you integrate a module in the kernel in the recipe. But it is in the Yocto directory, not outside the Yocto directory. You can use it from Yocto. But I think it's not a good way, but you can use it if you want. It's a TMP workshop, etc. Kernel build artifacts. Exactly the kernel source necessary to compile a module. Ok. So the last part is to try to use some CI functionalities. So when you add functions or you modify a system, you want to check there is no regression on the system after an upgrade on the standard components. And on other application, you develop with SDK. And then you add packages, for example. So you have lots of methods and tools for that. It's very famous. And I don't want to talk about it again. And there are two functions provided by Yocto, which is a ptest to test a package. And test image to test an image. And of course it's possible to extend. There are lots of examples in Yocto for standard packages such as Busybox, Bluezy, etc. But you can define your own test for ptest or for test image. Ok, so we try to, for example, for ptest. In the local.conf you have to add some distro features and image features to include the ptest functionalities. And once you create a specific image with this modification, you have also a package including the ptest strips in the USR, Lib, etc. ptest. So my distro is my image in USP test. So for example you can see there is in USR Lib. You have, for example, in Busybox, you have ptest for Busybox, etc. And you have a command to see what are the packages including a ptest script. Ok. And you can test a package with a ptest runner command inside, on the board, or from SSH, which is much easier if you want to have an automatic test. So as an example we develop a small program which converts Celsius to Fahrenheit, which is very useful. Ok. And we want to check if the program is ok. So with the program we give a script with some script which is called one ptest. It's a simple shell script. And a list of data which is simply temperature in Celsius and temperature in Fahrenheit. And we run the test to see if the program gives the right value for Fahrenheit. So for example I do the ptest for. For. Ok. And you begin the test. And you have the result of the test. And of course you can do that from SSH. And you can do, if you type only ptest runner, you run all the tests. But it's very long. I will not do this. And another one is the global testing. It's quite different because instead of testing a package on the board, for example you want to test some functionalities. For example the network, for example SSH. And basically it's designed to be run by QMU, by the QMU target. But if you configure your CTO, you can make it run on a hardware board already running, for example. But there are several ways to test. You can test a booting target, you can test an already running target, etc. But what we will do with running target is much more simpler. So you add an iterate on the test image and you define the test suite. And there are lots of examples of test suite for example on the network with ping SSH, you can check the size of the disk, the remaining size on the disk. You define the way to test already finished. Oh, it's quite finished. And then you can do the test. For example, you can do that from the build environment, bit back minus C test image. Yes. Ok, you are at English time. Ok. So I will be slower. So you can run from the PC, you can run bit back minus C test image on the image you want to test and it will run the test. So for example, no. I will first try with a standard test. So ping and SSH are standard tests. Core, image, minimal. Ok. So of course the board should be... So I modified the local.com, so there is a smaller indexing of the packages of the recipe, sorry. But the most interesting, of course, you can add a new test. The standard tests are in meta layer, Libo, QA, etc., and time. And you can add your new test in your new layer and you write the test with the API provided by Yocto. It's a Python. And I just wrote a simple test today to show you. It's a test we check if the kernel modules are loaded. It's very simple. But first we will test with the standard features. Ok. Do test image. So all the two tests are ok. Then I add a new test. For example, I want to be sure that the module is loaded. So my sample module, I want to test on the board that the module is loaded. So I wrote a very simple test which use LS mode and say LS mode size should be more than one line. It's very simple. But well, why not? And the test is here. META, FOSDEM, Libo, OQR, etc., and it's called LS mode. You know. So this is a very simple test. You run a command from SSH, LS mode pipe, you see minus L and I check the result is greater than one. So I have to add the test and first, if I remove the module, there will be a failure, of course. So sorry for my old PC, it's a bit slow. No, it's not that slow. So there is an error, but because there is an error in the test. So you can see in the file, of course you can do some additional stuff that you will get a message. You will get a message, Karnel module is not loaded. So I insert the new module and I run the test again. And of course it will work. Ok. So, that's very simple, but if you have some additional components around, you can do some interesting things with some tools such as test image, ptest, etc. Do you have any question and you speak slowly, please, in English? Or you speak French with a south accent? No, I understand a little bit. Is there any way to flash the image after the building process and then test it? Yes, of course. I think so. Well, the answer is with Yokto you can do anything you want. You have to write, you can write a class to flash an image and to test the image and you can combine any tools you want. I don't know if there is, I think there is an existing configuration for test image for that, but I'm not sure, I never used it, but I think there is. Thank you. No more questions? Merci.