Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
software:linux:yocto:setup [2021-10-25 13:29] Moritz Lammerichsoftware:linux:yocto:setup [2024-04-23 13:06] (aktuell) Moritz Lammerich
Zeile 1: Zeile 1:
-====== Setting up the Build Environment ======+====== Setup and Building ======
  
 ===== Supported Operating Systems ===== ===== Supported Operating Systems =====
  
-[[ https://www.yoctoproject.org/docs/3.0/brief-yoctoprojectqs/brief-yoctoprojectqs.html | The Yocto Project website]] outlines the following requirements:+[[ https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html | The Yocto Project website]] outlines the following requirements:
  
-  * 50 Gbytes of free disk space 
  
-  * Runs a supported Linux distribution (i.e. recent releases of Fedora, openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux distributions that support the Yocto Project, see the "Supported Linux Distributionssection in the Yocto Project Reference Manual. For detailed information on preparing your build host, see the "Preparing the Build Hostsection in the Yocto Project Development Tasks Manual.+ 
 +  * At least 90 Gbytes of free disk space, though much more will help to run multiple builds and increase performance by reusing build artifacts. 
 + 
 +  * At least 8 Gbytes of RAM, though a modern modern build host with as much RAM and as many CPU cores as possible is strongly recommended to maximize build performance. 
 + 
 +  * Runs a supported Linux distribution (i.e. recent releases of Fedora, openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux distributions that support the Yocto Project, see the Supported Linux Distributions section in the Yocto Project Reference Manual. For detailed information on preparing your build host, see the Preparing the Build Host section in the Yocto Project Development Tasks Manual.
  
   * Git 1.8.3.1 or greater   * Git 1.8.3.1 or greater
  
-  * tar 1.27 or greater+  * tar 1.28 or greater 
 + 
 +  * Python 3.8.0 or greater. 
 + 
 +  * gcc 8.0 or greater. 
 + 
 +  * GNU make 4.0 or greater
  
-  * Python 3.4.0 or greater. 
  
 **Note that Yocto is not compatible with the Windows Subsystem for Linux (WSL)** **Note that Yocto is not compatible with the Windows Subsystem for Linux (WSL)**
Zeile 19: Zeile 28:
 ===== Download ===== ===== Download =====
  
-Everything needed to build a basic image can be downloaded from the yocto project git server. Yocto projects are self contained and can therefore live anywhere on the filesystem.+Everything necessary to build a basic image can be downloaded from the yocto project git server. Yocto projects are self contained and can therefore live anywhere on the filesystem.
 This guide will assume that everything related to the build will live in a directory called ''yocto'' in the ''ubuntu'' user's home directory, i.e. ''/home/ubuntu/yocto/''. This guide will assume that everything related to the build will live in a directory called ''yocto'' in the ''ubuntu'' user's home directory, i.e. ''/home/ubuntu/yocto/''.
  
Zeile 28: Zeile 37:
 </code> </code>
  
-Where <release> corresponds to the branch or tag needed. At the time of writing the latest LTS release is ''dunfell''.+Where <release> corresponds to the desired branch or tag. At the time of writing the latest LTS release is ''kirkstone''.
 Note that while checking out a branch also works, checking out a particular tag is recommended to produce reproducible builds. Note that while checking out a branch also works, checking out a particular tag is recommended to produce reproducible builds.
 Check [[ http://git.yoctoproject.org/cgit/cgit.cgi/poky/ | the poky repository for all available releases ]]. Check [[ http://git.yoctoproject.org/cgit/cgit.cgi/poky/ | the poky repository for all available releases ]].
  
-===== Set up ======+===== Setup ======
  
 Bitbake, yocto's build system, let's the user pick their own directory to store all output in. This includes (among others) downloads, packages configuration files, and the final image(s). Bitbake, yocto's build system, let's the user pick their own directory to store all output in. This includes (among others) downloads, packages configuration files, and the final image(s).
Zeile 76: Zeile 85:
  
 Often it is necessary to add further layers to the build to customize the resulting image, or build for specific hardware (a specific ''MACHINE''). Often it is necessary to add further layers to the build to customize the resulting image, or build for specific hardware (a specific ''MACHINE'').
-For example, to use the NTB/OST images, the [[ meta-ost ]] layers need to be added to the build.+For example, to use the OST images, the [[ meta-ost ]] layers need to be added to the build.
  
 While layers can be included from any directory, it makes sense to keep all the layers in one place. In this case they will be kept in the parent directory, next to the ''poky'' folder. While layers can be included from any directory, it makes sense to keep all the layers in one place. In this case they will be kept in the parent directory, next to the ''poky'' folder.
Zeile 86: Zeile 95:
 # clone layers # clone layers
 git clone git://git.openembedded.org/meta-openembedded -b <yocto-release> git clone git://git.openembedded.org/meta-openembedded -b <yocto-release>
-git clone https://gitlab.ost.ch/tech/inf/public/meta-ost+git clone https://gitlab.ost.ch/tech/inf/public/meta-ost -b <yocto-release>
 </code> </code>
  
-Note that many layer repositories will have different branches for different yocto releases. For example, meta-openembedded has a ''dunfell'' branch to be used with the ''dunfell'' yocto releases.+Note that many layer repositories will have different branches for different yocto releases. For example, meta-openembedded has a ''kirstone'' branch to be used with the ''kirstone'' yocto releases. Note: use the kirkstone branch and not a tag.
  
 ===== Build Configuration ===== ===== Build Configuration =====
  
-When running ''oe-init-env'' a ''conf'' folder is created inside the build directory: ''build/conf'' in this case.+When running ''oe-init-env'' a ''conf'' folder was created inside the build directory: ''build/conf'' in this case.
 This folder contains two files: ''local.conf'' and ''bblayers.conf''. This folder contains two files: ''local.conf'' and ''bblayers.conf''.
  
Zeile 101: Zeile 110:
 If additional layers are needed, they need to be added to the list for bitbake to find them and their recipes. If additional layers are needed, they need to be added to the list for bitbake to find them and their recipes.
  
-This is the place to add the path to the custom layers that were ''clone''previosly (if any). +This is the place to add the path to the custom layers that were ''clone''previously (if any). 
-Some repositories such as [[ meta-ntb ]] contain multiple layers. +Some repositories such as [[ meta-ost ]] contain multiple layers. 
-In these cases each layers must be added seperately+In these cases each layers must be added separately
-For example, ''meta-ost/meta-ost'' and ''meta-ntb/meta-ntb-ros'' rather than just ''meta-ost'' as shown below.+For example, ''meta-ost/meta-ost'' and ''meta-ost/meta-ost-ros'' rather than just ''meta-ost'' as shown below.
  
 <code> <code>
Zeile 114: Zeile 123:
    /home/ubuntu/yocto/meta-openembedded/meta-oe \    /home/ubuntu/yocto/meta-openembedded/meta-oe \
    /home/ubuntu/yocto/meta-ost/meta-ost \    /home/ubuntu/yocto/meta-ost/meta-ost \
-   /home/ubuntu/yocto/meta-ost/meta-ost-ros \ 
    "    "
 </code> </code>
 +The paths of the entries above must match your actual paths.
  
 ==== local.conf ==== ==== local.conf ====
Zeile 126: Zeile 135:
  
 Another thing that may come in handy is manually setting the kernel used. Another thing that may come in handy is manually setting the kernel used.
-This can be achieved by setting ''PREFERRED_PRVIDER_virtual/kernel'' to the desired kernel.+This can be achieved by setting ''PREFERRED_PROVIDER_virtual/kernel'' to the desired kernel.
 By default, yocto provides a kernel as ''linux-yocto''. By default, yocto provides a kernel as ''linux-yocto''.
  
-For a typical build using [[ meta-ntb ]] the following should be appended to ''local.conf''+For a typical build using [[ meta-ost ]] the following should be appended to ''local.conf''
 <code> <code>
 MACHINE = "<machine>" MACHINE = "<machine>"
-DISTRO = "ost-distro"+DISTRO = "ost-devel"
 </code> </code>
  
-Additionally, [[ meta-ost ]] uses the ''OST_DEVBUILD'' Variable to build a development image rather than a production image+This will build a development image. If you would rather build a production image, change ''DISTRO'' to ''ost-distro''
-A development image can be built by adding ''OST_DEVBUILD = "1"'' to ''local.conf''+The difference between the 2 distro's are documented in the "ost-distro vs. ost-devel" section in [[meta-ost]].
-Otherwise (including ''OST_DEVBUILD'' not being set at all), a production image will be built.+
  
-===== Runnning a Build =====+=== Internal Mirrors ==
 + 
 + 
 +Bitbake has the ability to use external mirrors both for downloading package sources and the shared state cache (sstate-cache) to speed up builds. 
 + 
 +The downloads and sstate-cache generated by the CI builds for [[meta-ost]] are provided internally. 
 + 
 +OST INTERNAL ONLY: To configure bitbake to use the internal mirror, check {{ https://wiki.bu.ost.ch/inf/yocto/start | the internal docs }}. 
 + 
 +===== Running a Build =====
  
 Packages and images can be built by running ''bitbake <recipe-name>''. Packages and images can be built by running ''bitbake <recipe-name>''.
Zeile 146: Zeile 163:
  
 <code> <code>
-bitbake core-image-minimal+bitbake ost-image
 </code> </code>
  
Zeile 157: Zeile 174:
 ''-c'' tells bitbake to only run a particular command rather than building the package(s) in the recipe. ''-c'' tells bitbake to only run a particular command rather than building the package(s) in the recipe.
 In this case that command is ''clean'', another example is ''fetch'' to fetch the necessary sources required by the recipe. In this case that command is ''clean'', another example is ''fetch'' to fetch the necessary sources required by the recipe.
 +
 +Results will be placed in ''build/tmp/deploy/'', e.g. images will be in ''build/tmp/deploy/images''.