Welcome to this session. It's titled Embedded Linux Development with the Jocto Project. I'm glad to see there's actually an audience. An embedded track at the NDC conference tends to attract a small subset of the crowd. And if we're building Linux, maybe an even smaller one. There's a handful of people here, so welcome. It's good to see you.

Who am I and what do I do? My name is Isaac Steve. I come from Gothenburg, Sweden. I work as a product concept and software developer for a company called Vinter. We work with M2M and IoT devices in those segments. It's a pretty broad range of devices from bare metal sensors to more higher-end aggregators and routers, usually Linux-based.

Oh, look at that. So I had a last-minute failure. I set up my Linux presentation on a Windows partition. I shouldn't have done that, so I see this isn't the most recent version of the slides.

But I hope most of it should be here. We've been using the Jocto Project since 2012. So I'm going today to show you a couple of steps to how you can get something to build. Who are you, then? And why are you here? How many of you are in Room 9 at the moment?

Those of you who didn't raise your hands are in the wrong session. Most of you are in the correct room and are pretty engaged for a talk. How many of you are not from Norway? Two people not from Norway. Okay. So most of you are from Norway. How many of you are embedded developers?

About half. Doing embedded Linux development? Almost half. How many of you do BSP support or maintenance for a product right now? One and a half. Okay.

Let's have a look at the session outline for this session. We're going to start talking about why use Jocto in the first place, or why build something from source when there are distributions to choose from. What is Jocto? What's the background for it and some of the core components? And then we'll try to get started. And we won't actually be doing things here. I didn't want to clone things off of a conference Wi-Fi,

so I've prepared the work and I have slides to show the work, so it's not going to be very interactive, but I'm going to show you steps for what to do. I'll give you access to the slides later so you can retrace the steps and do it yourself. We're going to have a look at some of the graphical build tools we can use.

Hob and Toaster, if you don't want to use the command line or just want a more overview of the Jocto project. Then a brief look at the build system. We'll try to add our own minimal distribution, add our own software. Targeting real hardware, if we have time for that, I don't know.

But also just briefly, I haven't brought any hardware and we can't flash it on and boot something up, but I will talk about how to create a BSP layer for that. And then just to wrap up where you can learn more and some questions, then it's food time again. Why use Jocto? The inevitable question. Why not use any of the already existing distributions?

There are a couple to choose from and we don't need to go through the hassle of building and to just get us started, right? Well, picking an existing distribution makes good sense in a few cases. If you have a board off the shelf or an evaluation board, there can be a distribution that you can just put on this and get started,

and you don't really need to build Linux. And it's a good idea for some cases if you are doing a one-off solution, a do-it-yourself home automation thing. And maybe if you don't need a tool chain, you don't need to compile something, maybe it's Python, you can do this. And it seems like an easy way to get started in the general case,

but there are a few caveats you need to be aware of because you can end up in a world of problems if you go down this route and actually try to release a product on an existing distribution. Of course, you get a lot less flexibility for your own design if you pick a distribution. You can't really pick and choose what you're going to ship. You get something to ship, and that's that.

You get a strict dependency to upstream release management and what their cadence is. You need to know if there is an upgrade path for the distro you've chosen, or if it's basically end of life the second you receive it. There are distros that are claimed to be Ubuntu for instance,

that come with evaluation boards, but they're really patched distributions with hardware support, and you can't really step up Ubuntu or whatever distribution it is, because that distribution is meant to boot up your board at the moment you get it, but not really to maintain your product over time. So do you need support for your product, and can you get that over your product's life cycle?

If we have a product perspective and not just a hobbyist perspective, we need to think out maybe 10 years or more. So building from source makes it easier, it takes care of a lot of these issues. We get a lot more flexibility and control when we control what type of software we put in our distribution

and ship in our products. We know exactly what we have included. We know what their versions are, what their patch levels are. So if we get a CVE or receive a CVE for a package, we can just go and maybe look through our build logs and see, do we have shipping products that uses this package? So do we need to start working on a patch?

So then if we develop a patch or we get a patch externally, we can just rebuild the firmware for this product, and we have a hot fix in, well, not no time, with a very short time to market. And if you are relying on an existing distribution, it can take a very long time, if at all you get this update.

We can also fine-tune the image size. Devices get bigger and bigger, they get more and more flash, so we aren't as constrained by image size now that we used to be maybe ten years ago. But there are cases where you really want to know what your image size is. If you're doing over-the-air upgrades, you don't want to send stuff you don't really have to send and things like that.

Also licensing issues. I can see that LibreOffice isn't really agreeing with PowerPoint on the spacing here. I hope that works out for the rest of the presentation. Licensing issues are easier to handle with confidence if you put together it yourself. You get a complete bill of materials for what goes into the build, what type of licenses do they have,

and this can be crucial for some segments where you release your product. So again, why use Yocto? If it's such a great idea, why isn't it more common? And I don't know how common it is, but I have a strong feeling that it could be more common, and probably should be more common, that you build your own Linux. Because there is an attitude that building your own Linux is arduous and hard,

and it takes time, and it's brittle, a setup you need to maintain, that doesn't really have to be the case. It's still nooks and crannies you may need to go through, but in the general case, things like Yocto takes care of a lot of what used to be problematic. So it's now less of a hurdle to jump to get something to boot.

This also allows you then to focus on your products. You can focus on what makes your product a product, and not spend development hours getting a Linux to boot up. Okay, that's it for the why. What then is the Yocto project? This is just a screenshot of the Yocto project homepage.

You have the URL there if you want to check it out later, or if I'm boring you, maybe you want to check it out while I'm talking. This tagline here, it's not an embedded Linux distribution. It creates a custom one for you. It's pretty key for the Yocto project, and it turns up in all presentations about the Yocto project, so I felt I had to show it as well. But it's really an open source collaboration project

to provide these tools and methods to help developers build embedded Linux, their own Linux distributions. Where does it come from? Some background. It dates back to 2003, when members of the open source project felt they needed a new build system.

They were using buildroot at the time, and, well, they just needed something else. So they looked out, and they found the Gentoo Portage package management system, and said, that's a pretty cool idea. Maybe we should try to do something like that. So they worked on it for a while, and they accepted some patches from neighboring projects, and OpenEmbedded was born. So OpenEmbedded and OpenEmbeddedCore was used to build firmware

for a couple of different products, a handful at that time. But the idea was there to maybe we can have a core build system that we can use for different products. This turned out pretty good. They experienced fast growth. A lot of developers came in, added more recipes, added more machine support, and maybe the fast growth was a bit too fast,

because issues with stability started to come up, and package recipe quality. So if you were deploying a product, and you were relying on this quality, then OpenEmbedded weren't as great an idea, because you couldn't really maintain that over time.

So as a reaction to this, Pocket Linux was created as a subset. So within OpenEmbedded, but as a subset, Pocket Linux was created to, quote, focus on stability, package quality rather than quantity, solid core set of packages, and a well-integrated demo stack. So that's sort of the goal statement for Pocket Linux.

And what they did was they threw out some of their hardware support, and they threw out a lot of the recipes that didn't really have the quality they needed. And instead, they were able to focus on delivering things like IDE plugins and quick emulator integrations that are used today in Yocto. In 2010, then, the Yocto project was founded.

The Linux Foundation announced it as a workgroup under the technical lead of Richard Purdy, who's a Linux Foundation fellow. In March of 2011, the Linux Foundation then said that we're now going to align with the OpenEmbedded community to advance Embedded Linux and try to bring some order to the Embedded Linux chaos at the time.

And finally, since the 1.1 release in October 2011, OpenEmbedded and Yocto now shares OpenCore. No, OpenEmbeddedCore. And maintain it together. I don't think there has been an OpenEmbedded release since 2011, but the core is the same.

That's the important part. And of course, the best thing is from Pocket. So that forms the base of Yocto. So it's really an umbrella project. Yocto itself contains lots of different projects. I just picked out a few. OpenEmbeddedCore I already talked about. AutoBuilder is a continuous integration and QA server for building.

I'm not going to talk about that. I haven't used it much myself. We tend to build Linux the same way we build all other software through Jenkins or whatever. But I know others use it. BitBake is the task executor that runs the builds. BuildAppliance, we're going to look at that.

Hub and Toaster are graphical build tools. Poky then is actually an internal project that works by pulling all the other projects together. So there's a confusion about what Poky is. Is it a project or a distro or a repository? Or what is it? Because people talk about Poky and it tends to mean different things.

So I already said it's a project that pulls together other projects. It's also the name of the repository. If you go to Jokto and say download, you're actually downloading the Jokto build system, which is called Poky. Mightily confusing.

So that's it about the Wwise and the Watson. And it's time to get started. Although, as I said, we won't be doing any hands-on here. I will just show you some work. We'll start looking at the system requirements for what you need to build Jokto. There's also a Plan B called the BuildAppliance if you don't fulfill the system requirements at the start.

We'll look at the release cadence and versions for Jokto. Cloning the FIDO branch of Poky and look at images and the supported machines. How we source up the environment, build an image, and run it using an emulator. System requirements then.

Building Linux and building all the software you pull in, it's going to eat up a lot of your disk space. Even though 50 gigabytes may not be considered a lot of disk space, but still it's worth considering. Especially if you dual-boot, as I do, you need to make sure you have enough disk space to do this. You should be running a supported Linux distribution, which means a recent release of Fedora or OpenSUSE or CentOS or Debian or Ubuntu.

I'm running 14.04, which is fairly recent and that works, even though it's not the latest. And then you need to have some appropriate packages. I guess most of us have Git 1.7.8 or later and tar 1.2.4. Python 3 is not supported. I don't know if it's supposed to be supported in the future, but that's how it is right now.

You also need a bunch of other packages that vary by distribution and what you're going to do, so I'm not going into exactly what you need. Also, something that isn't a requirement, but it's going to give you a great return on investment, is if you're building Linux and all of it,

just throw as much cores and memory and disk space as you can on that problem because you're going to get an ROI on that investment. It's pretty easy to just time that and show it to the people with the money and you will get help. Okay, plan B. If we don't fulfill the system requirements, there is something called the build appliance.

It's actually a VMware image that we can run on whatever host is able to run VMware. The intended usage scenario for the build appliance, though, is really to test Yocto, to figure it out and explore it. It's not really meant to be a development tool, so you'd use the build appliance on a Windows host to actually develop for Yocto,

because if you run it in a virtual machine like that, build times are going to skyrocket. If you build Yocto and Qt and a web server, you're looking at hours and hours of build time and there are better things to do with your time. Okay, understanding release cadence and versions.

The Yocto project is releasing on a stable release cadence every six months, April and October. Every release has a name. FIDO is the latest and a number, of course. For one year or two releases, there is a stable release branch that is being maintained and supported.

But then after this year, it relies on community support. There is at least one LTSI kernel and one more later kernel included in DC. As you can see, there were two LTSI kernels for different reasons. This means that as a product developer, you can choose, do I want the latest and greatest features,

or do I want something that is going to have longer support because I'm going to ship a product on top of this. But FIDO is the most recent one, so that's the one we are going to clone. So, git-yocto-project-org-pocket.git, this URL is on the Yocto homepage if you want to see it.

We clone that and we can navigate into the clone directory to see the files. We have BitBake, as I said, it's the task executioner. Documentation, really no need to go into the documentation.

It's much better documentation on the web, so go there instead to see the documentation. And then these things, let's start with meta, are actually layers. And layer is a concept in Yocto and in OpenEmbedded that pulls together functionality, so a bunch of different recipes comes together in a layer to provide it as a package. We have two init scripts that are used to source the environment,

and we have a script directory that includes the tools we are going to use. So, before we source the environment, we'll just have a brief look at what's supported out of the box. In the meta directory, we have a couple of QEMU targets that we can run.

QEMU is the quick emulator. How many here have used the quick emulator? One, two, three, okay. And there are emulator targets for ARM 64, MIPS 64, PPC and x86, 32 and 64 bit.

There are also a couple of Yocto-provided reference machines, like the BeagleBone and the EdgeRouter, that are actual machines. There is generic x86 as well. Images, though. There are quite a few images that you can start from, that deliver different kinds of features if you just want to boot a target,

or if you want to have different kinds of graphical environments. We have an image for X11, we have Western Wayland, or if you want to go directly to the frame buffer, or core-image-minimal, you just want to boot, that's all, nothing else fancy. We're going to be looking at core-image-sato, that's actually a graphical environment based on the GNOME Mobile UI.

And we're going to build that and boot it. What are we doing with the time here? Well, okay. So, before we start, we need to source the environment. These scripts, they set up the environment for us and they create a couple of files. So we go source, we init buildenv.

There is also a memres version that sets up the memory resident thing, but we don't go into that here now. When we source this script, we automatically end up in a build directory, as you can see down here. We can provide the name of that build directory as an argument to this source script. That's good if you want to build for different machines,

where you have a build server that sources for different builds or whatever. So this is what the build tree looks like when it's created. Well, we have two variables added to the environment, or rather, well, to the path, so we can run things in scripts and in bitbackbin without having to spell out the path.

Under build, we get a conf directory that has three files. Two of them we're going to look at, the local.conf, where we do most of our initial configuration, and the bb layers, which tells bitback what layers we want to have access to when we build.

So, we want to build for a QEMU arm machine. We go into the build conf, local conf file, and, yeah, I've got everything here. We specify the machine to QEMU arm. We could have specified this on the command line when we sourced, but I want to do it like this because it's easier to see the whole picture now.

We set machine to QEMU arm. Question mark equals means set machine to QEMU arm unless it's already set to something else. Machine question question equals QEMU x eta six says, if no one else sets it to machine, set it to QEMU x eta six,

unless someone later on sets it with question mark question mark equal to something else. This can get really confusing, but there are tools to see what really ends up when you build it. And when you layer things on top of each other, if you're not in the top layer and you make changes, someone on top of you can just wipe your changes. So, it's pretty fun. These two are very important.

Download there and estate there. There is, of course, a directory for where we download all the files we pulled from the net or whatever we pulled them from. And there is a directory that has shared state caches for builds. And we're going to end up downloading quite a bit of files from the internet. So, just from the beginning, set up a file repository where you do your downloads,

and especially if you're a team, so not every team member downloads these files. I'm just chosen to put them in my home directory on the job to downloads here. And the same with shared state, job to shared state cache. Shared state works if you're building with the same host architecture twice. The second time you do it, you can check the shared state and say,

what do I need to redo when you can save a lot of time by doing that? I like to set up one shared state there for developers and one for my build server. That's just because I'm paranoid. I'm told it's perfectly fine to let your build server share the shared state cache. That's how I want to do it.

These final two lines, number threads and parallel make, those are instructions to the build system. How much work can we spawn at the same time based on our machine? We used to have been required to do that. In FIDO, I really didn't. I just added those to show you. So maybe it figures that out automatically now.

A good idea though, if you have a monstrous build machine with lots and lots of cores, maybe you want to reduce it and not use all of them when you build Yocto. Someone might show up and tap your shoulder that you're overusing your precious hardware. Okay, but that's what we need to do to start in local conf. Oh, well, we don't need to change the download directory, but I think you should anyway.

Another thing, it's easy to start tweaking local conf when you build, and then you add more tweaks and more variables, because most of what you can configure, you can configure from local conf. But remember that this is a generated file, and you really want this to be done by your build system. You need a script that runs source and then patches this file with whatever patches needs to be made,

because you don't want to start shipping products based on a manually edited local conf. The question is, do we normally keep local.conf and blair.conf source controlled? And no, we don't, because they are generated when you source it. So instead we have a build script that does the sourcing and then uses sed to replace or add stuff to local.conf.

So the configuration for our build is in the build system. I think Mike is going to talk about that in another session. Yep. Okay, blair.conf, we don't do any changes to this right now.

I just want to show you, and this is how the layers are pulled into BitBake. And it's the absolute path to where we have stored them. It's the open embedded meta layer and the jokto and the BSP layer for jokto. There are three types of layers, we can talk about that right now. There are BSP layers that provide machine support and allow you to boot in a machine. There are distribution layers or distro layers that pull together a bigger picture so

you get a real distribution, a named distribution under your name if you want that. And there are just software layers that just contain software recipes. And you have examples of these three here. And then the second one, bblair is non-removable.

That's actually only used by HOB that we are going to look at later. So it doesn't mean anything to BitBake, just configuration entry for HOB. Okay, we set it up and it's time to build our first image. Any more questions, by the way, before we continue? No? So we run our builds with BitBake and we specify that we want to build this core image, Sato image that I showed you previously.

This is the output when it's done. As it works, it's going to print the task that it's working on and everything. It starts off by parsing through all of the recipes to make sure that the recipes are in...

...they have all their dependencies and you can actually build it. It also prints out the host environment and what it's building for and the features. This is very good in your build logs because then you can go back and see for a certain release what version did we build with and what host did we build with and so on. So this takes a while for the first time.

A while depending of course on what machine you're building on. With my dual core i7 it takes about one and a half hour to build Sato, I think. A brief look at the build directory after the build. We've got a few more files here.

We are going to look under temp, the temp directory, and under deploy our output ends up. We're going to look more at deploy soon. Work is where everything is being unpacked and patched and compiled, so that's where the work happens to put stuff together.

Sysroot is where everything is staged before we package things. We will look at an infogram of the entire build process later. Then there's a couple of other cache and log directories that we don't need to look at right now.

The deployed outputs. Under temp deploy we get our images, the licenses information, and the RPMs for every package that we are building. Under images it's sorted by the architecture we are building for, and we build for qemuarm. And then under the qemuarm directory we have the root file system as tarball and as an ext4 and a kernel image.

So there's a readme in capitals here. Do not delete files in this directory because it doesn't work like an ordinary build system where you can just delete the output and the build system figures out, oh, I need to rebuild that. But instructions are in that readme. You need to actually use bitbeg to explicitly rebuild if you throw stuff away from this directory.

Okay, now we have an image, so we are going to use runqemu, a script that's in the script directory. We need to provide the machine name. There's probably an easy answer to why we need to do that. I can't figure it out because runqemu figures out

what image we built and things like that, so it should be able to figure out what machine we were building for. But we need to state it to runqemu. The first thing that happens is that we need to set up a tap interface so we can boot. But that's pretty simple, and when that's done, we can see our first Linux build boots to a desktop.

And this is actually a timeline, so qemu comes up in a window after you have provided your password for a tap. You get the pretty standard boot up information, you get a splash screen, it defaults you up to splash screen, and you boot up to this gorgeous set of desktop GNOME Mobile.

Okay, yeah, well, that's really it. You now have an image you can start working on and start tweaking to your own desires. So let's briefly talk about the two graphical build tools that you can choose from. To the left here is hob. It's the older one of the two, it's about to be deprecated.

You run hob just out of your build directory. The other one, toaster, is, as you can see, a web framework, a web front end. Not a framework, a web front end that you can use from any host, and you set it up on

a build server and you can use it from a Windows host or whatever to start builds if you want to. Hob, as I said, run it from your build directory. It's a GTK-based user interface, and it just runs on top of bitbake. It parses and overwrites your local conf and bblair.conf files. So if you've spent time on those files and you just open and close hob, it's going to jump and stomp all over them.

Previous versions of hob didn't do that, but that had its own set of problems because then you configured a build with local.conf and then you started hob and it didn't build what you expected. So it depends on where you're coming from, I suppose.

Hob is also available through an Eclipse plug-in in this IDE support type of work that was done. Benefits of hob is it gives you a better overview of your build status and it also supports saving image recipes. You can explore different layers and you can add and remove packages and create

new configurations and then just save as and you have a new image configuration. Toaster, as I said, is a web-based interface. By default, it runs using Django and uses a SQLite database to set up information and build history and statistics for builds. If you want higher performance and you want to set it up in front of a build farm as

you can, you can swap out Django and SQLite and use other tools that may be better for that purpose. It's supposed to be used over the network, but it can also be set up for local use. So you can source the Toaster script in your build directory and run it there if you want to.

Only now in this latest release, 1.8, can you actually start builds with Toaster. Before that, you could only look at old builds, which made it kind of a less useful tool. But now you can do that and that also makes it able to, as of 1.9, I suppose, completely replace Hobb.

So the build appliance tool is going to start with Toaster instead of Hobb then, I suppose, I hear. Yeah, that's about it. There's a link for the Toaster manual if you want to see more about how it works. But let's take a step back down then into the build system and the build system workflow.

From the left here, we have our configurations. We have the bitbake recipes and we have machine configurations and distribution policy configurations that are being pulled in. Bitbake takes those and parses them and it starts out by doing fetching. It does more than this, but this is a simplified view of things.

It starts out by fetching sources. This can be a tarball from an HTTP or a local file system or a git repository or a subversion or lots of other SCMs. It unpacks that data in the work directory, applies any patches we may want to patch with,

configures. This one says outreconf. Depends on if it's an AutoTools project. It doesn't have to be. It outputs files into different staging areas based on the dependencies and what packages are being used. You can select from one of three package generations if you want RPM or DEBS or IPK.

And when this is done, there's a number of QA tests. For instance, licensed QAs that make sure that you are only building software that fulfills your license policy. For instance, do you want to include GPLv3 or not? Things like that. And if you try,

if you say no and you still try to pull it in, your build is going to fail. The output of this is a package feed. And the package feed is then used for two things. We can create images and root file systems. And we can create a software developer kit that is tailored exactly to the image we are building.

Which is a good thing because then we don't need to have a separate project trying to set up cross-compilers with the right libs for the target we're using and trying to keep those in sync. This is a really good way of getting out a working SDK for your project. So the build system then, it consists of Bitch Bake and this metadata.

And there's really three main types of metadata. You have the configuration files, like the machine configurations and the distro configurations. You have something called classes that are reusable pieces of functionality where you have support for build systems like Autotools or CMake or SCons or WAF or whatever.

It gives you support for packaging and so in a recipe we can just state that this is an Autotools project. And then Bitch Bake figures out that oh, if it's Autotools then I need to do configure and then make and then make install and that's how things work. Recipes then describe the software or image to the build. What packages it provides.

A recipe can provide zero or more packages, so packages aren't metadata in Yocto, it's an output of building. It tells you where to get the source, as I said, local file, repository, whatever. Where to unpack it, you can tweak the work directory where you want to work.

What to patch, what build system to use and where to install things. Can you see this? Yeah, okay. BitBake is a task executor and the recipes, they configure what tasks are supposed to be run and how they are supposed to be run. And if you want to see what tasks a certain recipe provides, you can use BitBake to, in this case with bash, say bitbake bash minus c list tasks.

And it will show you the tasks that you can run. And then you can run a specific task by going bitbake bash minus c, for example, fetch. To try to fetch the source code for that, if you want to fetch that before you're building.

If you're setting up a source repository, you can do fetch all world and it will just fetch everything. So it's going to be there when you build later on. I pulled in the bash recipe or other in include file because there are several bash recipes depending on version. To show you a couple of examples on what a recipe looks like.

It's a summary. It just tells you what this is. Home page reference and a section where it should go when you configure your builds with graphical tools. Then it states what it depends on. And there are two kinds of depends. Depends and are depends. And depends or build depends. So what do we need to have to be able to build something?

And are depends is what do we need to have to be able to run, but we don't really need that to build. For instance, image files or icons or manuals or whatever. Inherits is where we pull in classes. So we tell BitBig that this is an auto tools project.

So that tells BitBig what to do with it. We also need get text for translations and a couple of update alternatives for a couple of other things. We can tell BitBig that when you do the reconf, we want to add to the standard exclude auto header. To the flags. And when you do configure, add enable job control.

So even though we're telling it to do things automatically, we can inject more settings into the build. Update alternatives. I'm not sure if you're aware what that is, but this is the way to tell it what alternative it's supposed to be, what priority the alternative is. All of these classes have ways to inject only the things that differ for this recipe.

So it's a kind of nice inheritance model here. Then the tasks can be totally overridden, or as we see here, we can prepend things to them or repend things to them. So do configure prepend, it tells BitBig that perform the do configure as you usually do, but before you do that, I want you to run this bash script.

Or perform do install as you usually do, but when you have done that, add this bash script after that. We can also replace it completely by saying do configure and then add the entire configure statements in this task override. Tasks come in two versions, not two versions, but in two forms.

They are bash scripts or Python scripts, and you need to figure out what they are. And sometimes you need to figure that out the hard way. And I think if you do an append to something that is a bash script, you have to append with bash. And if it's a Python script, you need to append with Python. But you're going to figure that out pretty quickly.

Questions on this? All these recipes for all the things you want. As you mentioned earlier, there are already file system images. So how, if you do this layering thing, I guess you take a file system

image and then you layer, like if you wanted a custom type of shell or something. Yeah, so the question Mike asked is do you write all your recipes by yourself? Because there are file system images, so couldn't you just take that and add your own software? And yes, that's what we do. I haven't written that bash recipe, it's provided.

And I'm going to show later that there are thousands of ready-made recipes that you can pull in if you need a piece of software that you didn't write yourself. Of course, if it's your own software, you probably need to write the recipe for it. But what I think we should do now is to try to add our own distro image.

So I will show you how to create a distro layer, how to append to an existing recipe. I see that the time is flying, so we need to do this pretty quickly. And it says generating an SDK. We're not going to do that here, but okay. Creating our own distro layer. Like a good TV chef, I've already prepared it, and this is the structure of it.

Every layer needs to have a conf directory with the layer.conf. Then, just to make it a distro layer, we add a distro directory with the name of the distribution, .conf. So we're creating an ndc distribution, obviously, since we're at ndc.

We're also going to append to a recipe. So we take a ready-made recipe and we just add stuff on top of it. And we're going to add our own recipe that isn't really our own, but I'm going to show you that later on. The layer config, not much to say about that. There's a matching statement in the beginning that matches in the layer every recipe's dash something, bb and bb append.

So if you add your own directory like this, you should name it recipes dash something. There's sort of a convention for what you're supposed to be called, like recipes, graphics, recipes networking, recipes extras. But you don't need to adhere to that, but it's a good thing maintenance-wise to do that.

Then it's just the distro name again and a priority for if there are different distros, what should be pulled in. Distro config, I choose to do a very lean distro config. We name the distro, we give it in two ways.

We give it a full name as well, who's the maintainer. And then in this file you can add a lot of image features and say for this distro we need this software. I didn't choose to do that, I'm just showing you it can be done. And then appending to an existing recipe. So the splash screen that you saw when you booted up says jockto project, obviously we don't want that on a product that we are shipping.

So we take the p-splash recipe and we append to it by saying I want to include this p-splash and the c-image.ping file. And that's actually all we have to do for that recipe. There's also the depends on gtk pixbuff-native.

So now we want to add a recipe for something. But before we do that, and as Mike was asking about, we should really check layers.openembedded.org if someone maybe already has written a recipe for this. And this is just an example, I search for nginx and nginx shows up and says

yep, there's an nginx recipe and it's really actually part of a layer called meta-webserver. Oh, so meta-webserver-layer, I wonder what that includes. Oh, this is just the attributions and things like that. Well, in the meta-webserver-layer there's lots of other recipes as well, like Apache 2 and whatever we might need.

Not whatever we might need, but a couple of different. And there are really thousands of recipes at this site, so go there and check what you need. And this is shared with OpenEmbedded, so if you're using OpenEmbedded already, it can help you. So now we add our own recipe to the layer, this isn't actually mine, I haven't written it.

It's an example on the internet that's based on a Yocto example, so I figured I could use it with proper attribution. We give it a description, simple hello world application, license, MIT is fine for us. This license file checksum is pretty important because it allows us to pull in external software and say I'm fine with this license

and I have a checksum for what it looked like when I decided I was fine with it. So no one can really swap it out under our feet, because if they do that the checksum is going to fail and that's going to fail our build. We also prepend to the file sector pass that we have a files directory, so you should probably go there and look for things.

This source URI tells BitBake that we should get software from GitHub, dynamic-devices-dbexample.git and we provide it with a certain source rev that says this is the revision we are going to pull out. Of course as long as we pull the same revision the license is going to be the same, but if we don't have a source rev it's going to pull the latest.

And if we pull the latest, we've chosen to version this, bbexample 1.0. If we pull the latest from git there's a convention to name it underscore git.bb. That means I'm tracking some branch here, it doesn't have to be head.

Okay, and S is where we put the stuff, so we clone from GitHub into our work there and git. And we tell it that this is an autotools project. Also this is interesting, we were setting up parallel make before, but for some reason for this recipe they have decided that we can't do parallel make.

This is a way to, for this recipe, use another setting for parallel make. Oh, yeah, we aren't only pulling from GitHub, we're also adding a patch, because we don't want the standard behavior, we want to make it more ndc-like of course.

And this is the actual patch, this is just a regular patch file, but what we want to do is swap out jock the world with ndc2015. bbexample is a command line tool that has a library that twice prints hello world and hello world from a shared library, and we want to change that.

Then a new image recipe, we require recipe soto images, score image soto, which means whatever soto does, that's what we want to do. But we want to remove soto games, because we aren't going to play games at the conference. And we want to add bbexample. And then we want to make our distro available to bitbake, and we do that by editing bblayers to add

meta ndc, and we go in, again we don't have to do this, but I do it for the overview purposes. We just go into local.conf and we switch out pocky to ndc, so distro question equals ndc instead of pocky.

Yeah, so there is another way to do it. They are generated when you source your environment for the first time. If you source your environment and the build directory isn't there, they are generated. That's true.

So now we can build a new image. So bitbake, core-image-ndc, and we get a new image. And here it's quite a few tasks, as you saw before when we listed the tasks. Every recipe has a lot of tasks, so this takes a while. But it was able to reuse quite a few of them due to shared state caches.

Okay, run qemu and we get a new splash. This is much better for our product. We can now add a browser or something and full screen and a session overview, and we have a kiosk product for ndc. We can sell it next year. Excellent. Questions on this? I was starting to be a bit stretched on time, so I fast forwarded through this, maybe too quickly.

So, no? Nothing? Oh yeah, of course. We want to start the terminal and run bb example, and it says hello ndce.

So that worked as well. We managed to patch and we managed to install this utility into the root file system and it boots up with run qemu. Achievement unlocked. We managed to do what we set out to do. But running in an emulated environment, it's a good way to get started, but it gets old really quickly, because it's hard to sell that product.

Look, you can run this with run qemu. So we need to target our own hardware, of course. It's about 15 minutes left, right? It should be.

And when we do this, since we aren't silicon vendors, we're probably basing our designs off of existing silicones. And a lot of them already have BSP layers that you can use. FreeScale, for instance, that we work the most with, they have meta fslr and fslr extras that you can pull out.

Intel has one, so you can actually build Yocto for a rack server, because maybe we constrain ourselves too much when we talk about embedded. But really, think of it more like anything that isn't a desktop PC.

So you can build a tailored Linux for a rack-mounted Linux station. Texas Instruments has them. Raspberry Pi, if you want to build your own distribution for Raspberry Pi, you can do that. So you need to get that, and I'm not going to go into the details on that, because it varies with what distribution you have.

Actually, I'm going to show you a machine configuration that is an existing machine configuration that we have. And it's a FreeScale configuration. And if you work with FreeScale, they provide their own BSPs. There's a community BSP and a supported BSP. So you should go that route. So if someone works with FreeScale, they're probably going to say, but you're doing this wrong.

I'm not aiming to show you exactly how to create a FreeScale BSP here. I just want to show you the general steps. So again, this is a BSP layer, and the conf and the layer.conf you've already seen. Here we add a machine configuration, and there's an include file we don't need to concern ourselves with.

And also pretty common for a BSP layer is that there's a recipes BSP and a recipes kernel that tell what U-boot or what bootloader are we going to use. U-boot is fairly common, but it doesn't have to be U-boot. And recipes kernel, what Linux version are we going to use. Here also we have the board patches and the config patches for U-boots, and the device tree and some other patches.

And of course, these can take quite a while to get for your new board, but that's not joktor related, you need to do that anyway. Anyhow, this just shows you how to get it into your build.

So layer config looks like the previous one, with one exception. We set up a layer depends for this. Whoops, that shouldn't say NDC. No, NDC BSP, that's correct. Layer depends, and it depends on fslarm and fslarm extra. So if we use, for instance, a tool to pull in this BSP layer, it's going to say, hey, you need to get the freescale BSP layer as well.

A machine configuration then. We require our include file, but we don't need to look at that. Silicon on ship family, just, no, we don't need to talk about that. But we need to tell what device tree are we using. When you boot up this device, what device tree file are we going to, or device tree blob are we going to use when we boot.

We give a configuration to U-boot, so since we're building U-boot and we're building it for our own hardware, we need to just say build U-boot with this configuration and pull that in, it's supposed to work.

This preferred provider business down here is pretty interesting because a recipe by default provides the package with the same name as the recipe. You can also provide other things with the provides keyword. And there can be several recipes that provides the same thing. For instance, virtual kernel, there can be lots of Linux recipes that all provide virtual kernel, but you can only use one of them.

So you say preferred provider for virtual kernel is Linux-Stella, which is our patched version of Linux to be able to boot this device. And it's the same thing with U-boot. There is another one called preferred version, if there are multiple versions of a recipe but you need

to use, and the default is to use the latest, but you need to use an older one. You can set up preferred version to point to an older recipe and pull in that instead. Okay, custom bootloader recipe. These aren't appends since we are...

No, that's right, these aren't appends because we are adding stuff under a different name. We can only append if we append to something with the same name. And we aren't doing that because there is no U-boot FSS with Stella recipe in the stock distribution. PV is the packaged version that we set with the Git version.

Sourcereb, you saw that, we state what branch we are using. So when we are going to Git to get stuff, it's going to pull out that branch instead. And we add our patches, the board patch and the config patch to the source URI.

It's a pretty lean recipe because most of it is set up correctly already in U-boot for us. We just need to add what's really different for us, which makes it easier to maintain. And also a Linux kernel for our custom hardware. It's the same thing again. We require an existing kernel, we add our patches.

We've chosen not to include a dev config here to use the default one, actually. And then when it's time, and this is what we can do instead of tweaking local.conf. When we source, we can just specify machine and distro on the command line. Because as we saw, it sets those unless they are already set.

So we set the machine to our new machine. We set the distro to ndc, source the script. We add the bsp layers to bblayers.conf. You've already seen how to do that. And we build the new image. It's supposed to be able to be flashable onto our hardware.

And then what we can do is bitbake core-image-ndc saying for this image, and of course with this configuration, populate an SDK for this hardware. Then we get gcc, it's 492 something right now in FIDO, that builds, tailored for this hardware that we have chosen with the correct optimizations and things like that.

So the question is, do we ever use cross tools? And no, we don't.

Yocto takes care of building the toolset for you. You can choose to use an external one. For instance, if you want supported toolchains, you can buy them from Mentor. That's Yocto project participants. Or you can just use your own entirely. So it's possible if you for some reason need to go through that pain. But you get one for free here, and that's really good.

Where to learn more? Yocto project has really excellent documentation. And they have managed to separate them into different areas depending on what your interest is. There's a BSP developer's guide, or a development manual that's more general,

a Linux kernel development manual, a quick start that I've actually stolen some of the infograms from, and a reference manual that's a full manual that concatenates everything. Go there and check it out.

The amount of documentation is huge, so it's pretty hard to wrap your head around. But it's also a fairly good community on the net if you want to ask questions and get good answers. Check the conference books then. I haven't checked this myself, but I was asked are you going to promote a book or something,

and I'm definitely promoting this one. As I said, the level of Yocto documentation is so much. And printing it into a book would be stupid because it's a moving target. But there's this book, Embedded Linux Development with Yocto Project. You can flip it through before you leave. And it's pretty small. It brings up the basics and it can get you started really good.

It's very good to have on your desk. I'm not an author, as you can see. It's written by Octavio Salvador and Diana Angelini, so I have no stake in this game. I just think it's a good book. Okay, there's been a couple of questions as we've been going. Are there any closing questions?

No? I've been able to satisfy your questioning needs. Well then, thank you. We are finishing slightly early. We get a chance to beat the queues down at the food courts. Thank you everyone for showing up. As we are leaving, remember the buttons.

My session is different from all other sessions. You can actually pick the yellow and the red one as well if you want to. Everyone else says pick the green. But if you pick the red one, come up to me and talk about what was wrong. It's better feedback than a red blob on a sheet. I'd love chatting with people.

Again, thank you for showing up. See you. Bye.