Introduction to Embedded Linux Part 2 - Yocto Project | Digi-Key Electronics

last time we went over why you might want to use embedded linux and i showed you how to create a quick custom linux image using build root this time we're going to create another custom image but we're going to do so using the yakdo project instead let's dive in [Music] before we look at the command line let's take a moment to review some terminology as it can get a bit messy first is the open embedded project this is a community driven project founded in 2003 to create a suite of tools to help people create custom linux distributions for embedded devices the yakto project was started in 2011 as an official linux foundation project it relies on many of the tools and reference files created by the open embedded project and open embedded is one of the collaborators in the yakdo project this is why you will see many files with the open embedded or oe prefix when working with yakdo the yakto project tries to maintain support for a number of popular architectures like x86 and arm the open embedded tool set calls any files used to configure the build process metadata these can be things like settings or source code locations a recipe is a specific type of metadata used during the build process that contains instructions on where to download source code configure it and compile it the build system groups metadata together into layers which are nothing more than directories that contain the metadata files most layer directories begin with the meta dash prefix although that's not always the case a board support package is a special type of layer that defines how the build system should configure things for a particular board it might contain recipes for downloading and compiling drivers unique to that board bsps are often maintained by vendors if you are creating your own single board computer or module and want to have support for it in the yakto project you will need to create your own board support package a distribution is a specific implementation of linux much like ubuntu fedora and arch linux are all different distributions by using these tools you are creating your own distribution the machine configuration refers to the physical architecture and board that the system should build for it usually points to a specific board support package to assist in this process an image is the output of the build process it contains the custom linux distribution you just built which includes the kernel any necessary boot programs drivers packages and the root file system you'll often flash the output image onto an sd card or other non-volatile memory on your board the official yakto project documentation has this great diagram showing how the build process works we configure any necessary metadata which the build system reads to figure out where to download the necessary source code it applies any sort of patches required tests the generated packages and creates the output image or images you might get more than one image depending on your settings in the metadata the variety of images give you options in setting up different boot chains or choosing different file systems you can have it generate a software development kit to make writing code for your particular board easier note that creating board support packages and software development kits is a lot of work that we won't get into in this series the idea is to get you used to working with the yakto project to create your own images and begin writing code for your custom distribution if you did not do it in the first episode you'll need to update your package manager and then you will also want to run upgrade in order to upgrade all of the necessary packages this can take some time if you haven't run it in a while so just be patient with it so then after running apt update we'll run apt upgrade this will cause your package manager to upgrade all of the packages say yes if asked and wait a little bit of time while it's doing that i'd like to point out in the yakto project reference manual there is a list of supported linux distributions these are the linux distributions for the host machine that have been shown to work with the yakto project you're not necessarily required to run one of these but it's highly recommended because they come with known good packages and they've been tested by the yakdo project community i would normally say go for something like ubuntu one of the long-term support distributions however i am running linux mint because i don't know i like to be different and the machine that i'm running it on is low power you will also need about 50 gigabytes of free space i would say at least 50 gigabytes of free space on your hard drive and i would say at least four gigabytes of ram this poor machine only has about two gigabytes of ram so we're gonna have to trick yakdo to work with that and i'll show you where to do that in order to run the tools in the yakto project we will need some packages and tools that are dependencies i recommend using apt or whatever package manager you have to install the following you will probably want to look at the yakto project reference manual to get an idea of what else you need to install as you can see i already have these installed but for you you might have to wait a little bit to install them the other thing that i found is that specifically for the stm32 mp1 build process in yakdo you will need the development version of the ssl library and that is for some ssl packages that they require you to use when building it if you just try to type python it will not work and that's because python requires you to use either python 3 or python 2 and since we installed python3 we can alias the term python or the command python to that so use something like vi or whatever text editor you want in vi scroll down to the bottom hit i and then we're going to type alias python equals python3 so now when i type python it will execute python 3 instead hit escape colon wq to write and quit and then we're going to call source on that bash rc file so that we run it again and now when i type python and spell version correctly you can see that it will run python3 in this case 3.8 from my home directory i'm going to go into that projects folder that i created in the first episode all i have in here is build root so we're going to put yakdo project next to build root and we are going to download the pokey reference distribution using get when i say that pokey is a reference distribution pokey is not yakdo project and yacto project is not pokey a reference distribution is all of the metadata layers board support packages bit bake and various other tools that make up the yakto project or even open embedded where it will generate various images in a known good fashion and that's our reference distribution so pokey is a good place to start when you're working with the yakdo project using pokey we can then add our own layers to create a customized version of our own distribution once pokey has downloaded go into that folder and you can take a look at what's going on in there bitbake is our main tool that we will be using to read in the metadata the recipes the board support packages in order to create our custom distribution and generate our images all of the meta meta dash pokey metadash whatever folders those are our layers they consist of various metadata that is used by the bitbake process you can also look at the various scripts and documentation that comes with this but those are the main folders that we need to be concerned with when working in the yakdo project you will want to make sure that all of your branches of your various repositories match to start i recommend looking at what's available for the various yakto project releases and these should line up with what's available in the pokey reference distribution generally you'll want to look for long-term support which are supported for at least two years the big thing to pay attention to here is the code name this aligns with a specific yakdo project version and everything we do whenever we download layers from other vendors or board support packages you will need to check out the version that lines up with this code name if you have a mismatch between the yakto project version and your various layers you will likely find that things won't compile or build correctly so you have to pay attention to this we will be using the st microelectronics meta st stm32 mp board support package this whole thing is a board support package that st has created in order to support their various single board computers or reference boards or evaluation kits for our purposes the stm32 mp157d dk1 is supported in here and it allows us to import all of these files into the yakto project supplementing the pokey reference distribution and then creating a custom linux build the important thing here is to look at the various branches these names should line up with what you saw available from the yakto project releases and this is going to be the case for nearly every vendor that has its own board support package regardless of which board you're using you will want to read the vendor's documentation to figure out how to include the board support package this is of course assuming that vendor supports the octo project so here we have dunfell and this seems to be the recommended branch the default branch for this particular board support package if we go back dunfell is indeed the long-term support release for the octo project and we need those to line up if you include other layers maybe things that have security or you find something that has graphics drivers for your board and it's not part of st's board support package release or something else that they have done you will also want to make sure that it has the dunfell release when you go to check out a specific repository branch so once we're done confirming that all of the releases line up we need to make sure that we check out the releases for every single layer including the yakuto project itself or the pokey distribution calling git branch will show us the local available branches that does not look like dunn fell as a part of that in this case we can call dash r with branches to see what's available and you can probably find dunfell in here so you can see origin and the various names that are available so i can scroll down and sure enough origin dunfeld is available as a branch which means i can just call get checkout dunfell which is the name of that branch or release once it's checked out you should be able to call git status and see that you are on the branch done fell once you've checked out a particular branch i recommend looking at the distribution config file in order to see some information about it at the top you should see that you're working with the pokey reference distribution we are working on the dunfeld branch and that should line up with any layers that we will download in the future if you scroll down you should see a variable listing the sanity tested distributions these are the distributions that this particular reference distribution was built on so your host machine they built it on a few versions of pokey as well as things like ubuntu and fedora as well as a few others if you are not working in one of these distributions for your host machine you will probably get an error that does not mean it won't build since i'm working on linux mint i expect to see an error if you're doing this on your own i do recommend using one of these distributions when you go to build because they're known to work but i like to be different and we'll see if everything works although that's a bit of a lie because i definitely tested this earlier and it does work on linux mint the yakdo project specifically pokey distribution does have some support for a couple of things like beaglebone black but a lot of times if you're working with something that's not supported by the reference distribution you're going to have to download it from the vendor site or their github page the next thing that we're going to do is download our board support package from the vendor specifically we're going to download meta st stm32mp notice that st microelectronics also maintains this reference linux distribution for their boards the meta st openst linux this is another layer you can download in addition to that board support package if you want to build their version of openst linux however we are not going to build this because it contains a lot of things like qt for doing graphics and things that we're just not going to concern ourselves with at least right now we want to build the bare minimum linux and to do that we're going to use the pokey distribution in order to make that happen the open embedded project also maintains a list of known good layers that you can also import if you'd like if you head to this layer index on their site you can find these layers that are listed note that most of them are board support packages that have been created by various vendors to support their reference boards or development kits however you can find some other things that include maybe some networking or security type applications or packages for you to use i'd like to point out that st also has a workshop for the stm32 mp1 that dives into some more specific utilization and how the hardware works on the mp1 series we won't go into a lot of this so if you'd like to learn more about the mp1 i highly recommend checking out this youtube series in order to do that as it will help you get started say creating your own board support package or creating a custom board around the mp1 microprocessor but we're just going to be working with a development kit in this series just to get you familiar with working with yakdo project in general in order to create custom linux distributions from there let's go back to our host machine whenever i download new layers from third-party sources i like to put them in a folder on the same level as the pokey reference distribution as that contains its own suite of layers we're going to use git to check out that stm32 stm32mp board support package layer and now that layer exists on its own at the same directory level as pokey we want to go into that directory and we want to check out the dunfeld branch just like we did with pokey because it's default it should say we're already on dunfell and we can run git status to verify that yes we are on the branch dunfell dunfeld needs to line up with what we saw in pokey feel free to look through some of the recipes and layers that are in this board support package you can also read the readme which is always a good thing to do one of the big reasons to look at this readme is so that you can figure out which other layers this board support package depends on i have found that the open embedded core and bitbake come with pokey in fact this is exactly why the readme is saying you can download oe core or just use pokey which contains the oe core layer so when we downloaded pokey these dependencies have been met however if we scroll down some more you can see that the meta open embedded layer is also required i hit page down that's why it just jumped like that so we're going to scroll back up and you see that this is still part of the dependencies which means that we need to download this meta open embedded from this url and we can copy this and i'm going to quit out of less i'm going to go up a directory to make sure i'm on the same level as these various layers then i'm going to clone that other layer once again we go into that layer and we want to check out the dunfeld branch as you can see we are on dunfell and we want to view the readme to see if this has any dependencies this is a very short readme as you can see it's a collection of layers to supplement the open embedded core it's going to be needed by our st build but this does not have any dependencies on its own so hopefully we are done with downloading various dependency layers once again we're going to go up a layer and we're going to run this open embedded initial build environment that's found in the pokey directory this creates a build environment and does things like add bitbake to our path so that we can call it and any other tools that are needed in addition it will also create a build directory for us the default name is build unless we give it another argument in this case i'm going to call my build directory build mp1 since we're creating a linux distribution or build for this particular processor when it's done you can see that we're now inside the build mp1 directory and we can list the files found in it in which case there is not much it's just a configuration folder if you tried to run the bitbait command prior to running that source command you will probably get an error that bitbake is not in your path when we run source bitbake is added to our path so now we can call the bitpick tool another tool we can use is bitbake layers and we can ask it to show the layers that are included in this build as you can see we have meta metapokey and yakto bsp when we create a bare bones linux build like this you will find that it's being built for the camu emulator which is used to just verify that things are working and it's just an emulator that runs on your host machine but we want to build something for an actual separate single board computer so let's do that to start we need to add the layers that we just downloaded specifically the st board support package and the open embedded layers inside the conf folder you will find something called bb layers.conf we are going to edit that this bblayers.conf file contains some configuration about the layers that need to be included during the build process the big thing you'll want to look at here is the bb layers variable by default this contains the various pokey layers that are needed just to get a bare bones image built for that caimu emulator we need to add the required stm32mp board support package as well as its dependent layers in order to make this run i'm going to go to the last line in that bb layers variable and i'm going to push a because i'm in vi but you're welcome to use whatever text editor you like hit enter and let's write some lines to include that board support package it will not be pokey in fact we need to point it to the other layers and you should be using absolute paths just like the lines before it sometimes you can get away with pointing it to the top layer such as the meta dash open embedded layer however in this case i found when i tried this the build would fail and i had to point it to a specific layer in that meta open embedded in this case the stm32mp board support package once the metadash oe layer inside that top level layer the other layer that was required when i tried the build process it yelled at me because it was missing was this meta python layer that's also in the meta open embedded layer and finally we want to add that meta-st stm32mp board support package that we downloaded earlier with that i can hit escape colon wq for write and quit so save and exit and then we can run that bitpick layer show layers again it will spin up bitbake and show the newly included layers that we just added to that configuration file the next thing we have to do is choose a machine that bitbake will build the image for by default it's building for that camu emulator so we need to figure out which machine to tell it to build for you can kind of poke around in here to look for something like machine so we'll go into that machine directory and let's see what we have available so it's a few configuration files let's take a look at that basicmp1.conf file doesn't look like there's anything particularly useful in here since i'm working with the dk1 which is the discovery kit or discovery board let's take a look at that configuration file you can look at those two configuration files to get an idea of what's needed i'm going to go with this mp1 configuration file which i believe the machine name is the stm32 mp1 you can also see the exact layers that are needed here which is where we're getting that metadash oe and metadash python layers rather than just trying to include meta open embedded if you just try to include this top level layer your build process will probably fail so this is a good place to look to see which layers are required and specifically how to name them you might be able to use the stm32 mp1-disco as your machine name but let's see if we can get it to build without it you're welcome to try it on your own do that i'm going to head back to that top level yacto directory and i'm going to head to my build mp1 directory from there you'll want to modify local.conf this should be in the same directory as that bb layers that we just modified there are a few things we need to change in here specifically the big one is the machine selection so i'm going to page down and you'll see where machine is set i'm going to comment that machine line out and i'm going to set a new one here for stm32 mp1 like i mentioned you may want to try stm32 mp1-disco to see if that builds and gives you a little more support but let's start with bare bones for now something that i found i needed to do for my particular machine because i only have about two gigabytes of ram is to change how the xz compression tool works that's at the very end when it's starting to create the images and package all of the files together it will try to grab two gigabytes of ram when it's running and if it can't find it it just fails and we can pass arguments to specifically xz by setting this variable in this case we're telling it to limit its own memory to megabytes or mebibytes in this case such that it will start to use swap space without this parameter i found that xz will just fail and not even attempt to use swap and i have a lot of swap i've got eight gigabytes of swap space set up on this machine and only two gigabytes of actual physical ram so if you're working with a low end machine like this you will probably have to do this or you will find that the build process fails once you are done save and exit out of this file so for me that's escape colon wq and if you head to the yakto project reference manual you will find that there is a section on images when you call bitbake you will need to give it a specific image to build here's a list of supported images that you tell bitbake to build against and it runs that specific recipe to produce a variety of packages and configurations we're going to build core image minimal this is just a bare bones linux image that has pretty much nothing in it other than a command line and a mostly empty root file system there are other images where you can add things like software development kits a real-time kernel some graphical interface stuff a westin image an x11 image if you want some graphical interface and so on so feel free to look through these and you can also look at your vendor documentation to see if the vendor also provides recipes for different images but for now we are going to pick image core minimal prior to doing that if you'd like to make changes to your kernel you can run bitbake-c menu config virtual kernel and wait just a moment while it pulls up the menu config the first time you run bitbake and it starts to read in the files and configuration that you have set it will take a while to parse this one of the really slick things about yakdo is that it tries to remember what it's done previously so if it's already parsed some of the files and configurations that you have created it doesn't need to parse them again so even though this is saying it's going to take 10 minutes it will only take 10 minutes the first time i run it unless i redo the entire build process additionally you will also find that even the build process is done so in stages so if you make a few changes after you've completed the first build process the build process will be much faster the second and third time this is one of the big advantages of yakdo if you make minor changes to the kernel or drivers and you try to tweak some things the subsequent building does not take nearly as long and that's one of the big reasons to use yakdo over something like build root once bitbake finishes parsing all of the metadata you should be presented with this configuration menu feel free to take a look at some of the things that are available for you like some of the kernel features that you can turn on or turn off additionally you have things like power management and drivers you can enable and disable but we will actually leave all of this at the default for now we can come back to this later if we need to enable certain things in our specific distribution so just select exit for now and say no to save the configuration at this point we're ready to build the actual image so just say bitbake core image minimal and press enter all of the metadata parsing should be completed so that should be pretty quick however the compilation process will still take a few hours it took five to six hours for my first run so just be patient with this you can let it run overnight for example if you can periodically check the output and carefully read any error messages that you might see for example if it complains that you're missing a dot h file you'll probably need to install some package using something like aptitude the good news is that if you need to re-run this process it will pick up where it left off one of the big advantages of yakdo is that it builds in stages and layers so that if you make tweaks to one of those layers it doesn't rebuild all of the others and it just rebuilds the ones that are needed and packages everything up for you so subsequent runs will be faster after a very long time a number of hours at least five or six for me the compilation process finished you should see an output like this saying everything is done hopefully you don't have any errors there is a warning message here for me but this looks like it should be okay for what we're trying to do if you want to clean your build you can enter bit bake dash c clean all core image minimal this will only remove the output images that you created this is a good way to start over without having to recompile all the intermediate steps however if you want to remove all the intermediate steps and really start over from the beginning what you'll notice is that all of the output is put into this temp or tmp folder so all you would need to do is remove that temp folder and that would allow you to start over from the very very beginning however we're not going to do that and instead we're going to peek into that temp folder and find where the images were created so inside temp we want to go to deploy in deploy you should see a folder named images and then depending on the vendor you're using this folder might be different for me it's stm32 mp1 here is where you will find all of the output images you will find things like ext4 which is a file system that you can do a byte for byte copy to a partition you might find things like boot file systems user file systems root file systems and then in some of the folders that are produced you might find some information about how sd cards are laid out such as this flash layout core image minimal we will look at that in the next episode fip is part of the boot process especially for trusted boot same with the arm trusted firmware we will be using these to create a boot chain in the next episode a lot of these files can be confusing in some instances you might find a very simple sd card image file that you can just burn directly to an sd card like we did in the build root episode however it does not seem that st has provided us with such an easy option so in the next episode we're going to look at creating custom partitions on our sd card and finding out which of these files need to be copied over to those partitions in order to create a successful boot chain and then get a login prompt for linux i'm far from an expert in embedded linux as there are a lot of moving parts that i still don't fully understand however i hope that these videos can give you a good place to start in the next episode we will flash those image files onto an sd card and boot into our custom linux distribution happy hacking [Music] you

Channel: DigiKey

Views: 149,659

Keywords:

Id: 2-PwskQrZac

Length: 32min 25sec (1945 seconds)

Published: Mon Sep 20 2021