Patrick Williams | c124f4f | 2015-09-15 14:41:29 -0500 | [diff] [blame^] | 1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| 2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" |
| 3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > |
| 4 | |
| 5 | <chapter id='bsp'> |
| 6 | |
| 7 | <title>Board Support Packages (BSP) - Developer's Guide</title> |
| 8 | |
| 9 | <para> |
| 10 | A Board Support Package (BSP) is a collection of information that |
| 11 | defines how to support a particular hardware device, set of devices, or |
| 12 | hardware platform. |
| 13 | The BSP includes information about the hardware features |
| 14 | present on the device and kernel configuration information along with any |
| 15 | additional hardware drivers required. |
| 16 | The BSP also lists any additional software |
| 17 | components required in addition to a generic Linux software stack for both |
| 18 | essential and optional platform features. |
| 19 | </para> |
| 20 | |
| 21 | <para> |
| 22 | This guide presents information about BSP Layers, defines a structure for components |
| 23 | so that BSPs follow a commonly understood layout, discusses how to customize |
| 24 | a recipe for a BSP, addresses BSP licensing, and provides information that |
| 25 | shows you how to create and manage a |
| 26 | <link linkend='bsp-layers'>BSP Layer</link> using two Yocto Project |
| 27 | <link linkend='using-the-yocto-projects-bsp-tools'>BSP Tools</link>. |
| 28 | </para> |
| 29 | |
| 30 | <section id='bsp-layers'> |
| 31 | <title>BSP Layers</title> |
| 32 | |
| 33 | <para> |
| 34 | A BSP consists of a file structure inside a base directory. |
| 35 | Collectively, you can think of the base directory, its file structure, |
| 36 | and the contents as a BSP Layer. |
| 37 | Although not a strict requirement, layers in the Yocto Project use the |
| 38 | following well-established naming convention: |
| 39 | <literallayout class='monospaced'> |
| 40 | meta-<replaceable>bsp_name</replaceable> |
| 41 | </literallayout> |
| 42 | The string "meta-" is prepended to the machine or platform name, which is |
| 43 | <replaceable>bsp_name</replaceable> in the above form. |
| 44 | <note><title>Tip</title> |
| 45 | Because the BSP layer naming convention is well-established, |
| 46 | it is advisable to follow it when creating layers. |
| 47 | Technically speaking, a BSP layer name does not need to |
| 48 | start with <filename>meta-</filename>. |
| 49 | However, you might run into situations where obscure |
| 50 | scripts assume this convention. |
| 51 | </note> |
| 52 | </para> |
| 53 | |
| 54 | <para> |
| 55 | To help understand the BSP layer concept, consider the BSPs that the |
| 56 | Yocto Project supports and provides with each release. |
| 57 | You can see the layers in the |
| 58 | <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink> |
| 59 | through a web interface at |
| 60 | <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>. |
| 61 | If you go to that interface, you will find near the bottom of the list |
| 62 | under "Yocto Metadata Layers" several BSP layers all of which are |
| 63 | supported by the Yocto Project (e.g. <filename>meta-minnow</filename>, |
| 64 | <filename>meta-raspberrypi</filename>, and |
| 65 | <filename>meta-intel</filename>). |
| 66 | Each of these layers is a repository unto itself and clicking on a |
| 67 | layer reveals information that includes two links from which you can choose |
| 68 | to set up a clone of the layer's repository on your local host system. |
| 69 | Here is an example that clones the MinnowBoard BSP layer: |
| 70 | <literallayout class='monospaced'> |
| 71 | $ git clone git://git.yoctoproject.org/meta-minnow |
| 72 | </literallayout> |
| 73 | For information on the BSP development workflow, see the |
| 74 | "<ulink url='&YOCTO_DOCS_DEV_URL;#developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</ulink>" |
| 75 | section in the Yocto Project Development Manual. |
| 76 | For more information on how to set up a local copy of source files |
| 77 | from a Git repository, see the |
| 78 | "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>" |
| 79 | section also in the Yocto Project Development Manual. |
| 80 | </para> |
| 81 | |
| 82 | <para> |
| 83 | The layer's base directory (<filename>meta-<replaceable>bsp_name</replaceable></filename>) is the root |
| 84 | of the BSP Layer. |
| 85 | This root is what you add to the |
| 86 | <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> |
| 87 | variable in the <filename>conf/bblayers.conf</filename> file found in the |
| 88 | <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>, |
| 89 | which is established after you run one of the OpenEmbedded build environment |
| 90 | setup scripts (i.e. |
| 91 | <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink> |
| 92 | and |
| 93 | <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>). |
| 94 | Adding the root allows the OpenEmbedded build system to recognize the BSP |
| 95 | definition and from it build an image. |
| 96 | Here is an example: |
| 97 | <literallayout class='monospaced'> |
| 98 | BBLAYERS ?= " \ |
| 99 | /usr/local/src/yocto/meta \ |
| 100 | /usr/local/src/yocto/meta-yocto \ |
| 101 | /usr/local/src/yocto/meta-yocto-bsp \ |
| 102 | /usr/local/src/yocto/meta-mylayer \ |
| 103 | " |
| 104 | </literallayout> |
| 105 | </para> |
| 106 | |
| 107 | <para> |
| 108 | Some BSPs require additional layers on |
| 109 | top of the BSP's root layer in order to be functional. |
| 110 | For these cases, you also need to add those layers to the |
| 111 | <filename>BBLAYERS</filename> variable in order to build the BSP. |
| 112 | You must also specify in the "Dependencies" section of the BSP's |
| 113 | <filename>README</filename> file any requirements for additional |
| 114 | layers and, preferably, any |
| 115 | build instructions that might be contained elsewhere |
| 116 | in the <filename>README</filename> file. |
| 117 | </para> |
| 118 | |
| 119 | <para> |
| 120 | Some layers function as a layer to hold other BSP layers. |
| 121 | An example of this type of layer is the <filename>meta-intel</filename> layer, |
| 122 | which contains a number of individual BSP sub-layers, as well as a directory |
| 123 | named <filename>common/</filename> full of common content across those layers. |
| 124 | </para> |
| 125 | |
| 126 | <para> |
| 127 | For more detailed information on layers, see the |
| 128 | "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" |
| 129 | section of the Yocto Project Development Manual. |
| 130 | </para> |
| 131 | </section> |
| 132 | |
| 133 | |
| 134 | <section id="bsp-filelayout"> |
| 135 | <title>Example Filesystem Layout</title> |
| 136 | |
| 137 | <para> |
| 138 | Defining a common BSP directory structure allows end-users to understand and |
| 139 | become familiar with that structure. |
| 140 | A common format also encourages standardization of software support of hardware. |
| 141 | </para> |
| 142 | |
| 143 | <para> |
| 144 | The proposed form does have elements that are specific to the |
| 145 | OpenEmbedded build system. |
| 146 | It is intended that this information can be |
| 147 | used by other build systems besides the OpenEmbedded build system |
| 148 | and that it will be simple |
| 149 | to extract information and convert it to other formats if required. |
| 150 | The OpenEmbedded build system, through its standard layers mechanism, can directly |
| 151 | accept the format described as a layer. |
| 152 | The BSP captures all |
| 153 | the hardware-specific details in one place in a standard format, which is |
| 154 | useful for any person wishing to use the hardware platform regardless of |
| 155 | the build system they are using. |
| 156 | </para> |
| 157 | |
| 158 | <para> |
| 159 | The BSP specification does not include a build system or other tools - |
| 160 | it is concerned with the hardware-specific components only. |
| 161 | At the end-distribution point, you can ship the BSP combined with a build system |
| 162 | and other tools. |
| 163 | However, it is important to maintain the distinction that these |
| 164 | are separate components that happen to be combined in certain end products. |
| 165 | </para> |
| 166 | |
| 167 | <para> |
| 168 | Before looking at the common form for the file structure inside a BSP Layer, |
| 169 | you should be aware that some requirements do exist in order for a BSP to |
| 170 | be considered compliant with the Yocto Project. |
| 171 | For that list of requirements, see the |
| 172 | "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>" |
| 173 | section. |
| 174 | </para> |
| 175 | |
| 176 | <para> |
| 177 | Below is the common form for the file structure inside a BSP Layer. |
| 178 | While you can use this basic form for the standard, realize that the actual structures |
| 179 | for specific BSPs could differ. |
| 180 | |
| 181 | <literallayout class='monospaced'> |
| 182 | meta-<replaceable>bsp_name</replaceable>/ |
| 183 | meta-<replaceable>bsp_name</replaceable>/<replaceable>bsp_license_file</replaceable> |
| 184 | meta-<replaceable>bsp_name</replaceable>/README |
| 185 | meta-<replaceable>bsp_name</replaceable>/README.sources |
| 186 | meta-<replaceable>bsp_name</replaceable>/binary/<replaceable>bootable_images</replaceable> |
| 187 | meta-<replaceable>bsp_name</replaceable>/conf/layer.conf |
| 188 | meta-<replaceable>bsp_name</replaceable>/conf/machine/*.conf |
| 189 | meta-<replaceable>bsp_name</replaceable>/recipes-bsp/* |
| 190 | meta-<replaceable>bsp_name</replaceable>/recipes-core/* |
| 191 | meta-<replaceable>bsp_name</replaceable>/recipes-graphics/* |
| 192 | meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux/linux-yocto_<replaceable>kernel_rev</replaceable>.bbappend |
| 193 | </literallayout> |
| 194 | </para> |
| 195 | |
| 196 | <para> |
| 197 | Below is an example of the eMenlow BSP: |
| 198 | |
| 199 | <literallayout class='monospaced'> |
| 200 | meta-emenlow/COPYING.MIT |
| 201 | meta-emenlow/README |
| 202 | meta-emenlow/README.sources |
| 203 | meta-emenlow/binary/ |
| 204 | meta-emenlow/conf/ |
| 205 | meta-emenlow/conf/layer.conf |
| 206 | meta-emenlow/conf/machine/ |
| 207 | meta-emenlow/conf/machine/emenlow-noemgd.conf |
| 208 | meta-emenlow/recipes-bsp/ |
| 209 | meta-emenlow/recipes-bsp/formfactor/ |
| 210 | meta-emenlow/recipes-bsp/formfactor/formfactor/ |
| 211 | meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend |
| 212 | meta-emenlow/recipes-bsp/formfactor/formfactor/emenlow-noemgd/ |
| 213 | meta-emenlow/recipes-bsp/formfactor/formfactor/emenlow-noemgd/machconfig |
| 214 | meta-emenlow/recipes-graphics/ |
| 215 | meta-emenlow/recipes-graphics/xorg-xserver |
| 216 | meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config |
| 217 | meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend |
| 218 | meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd |
| 219 | meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd/xorg.config |
| 220 | meta-emenlow/recipes-kernel/ |
| 221 | meta-emenlow/recipes-kernel/linux/ |
| 222 | meta-emenlow/recipes-kernel/linux/linux-yocto-dev.bbappend |
| 223 | meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend |
| 224 | </literallayout> |
| 225 | </para> |
| 226 | |
| 227 | <para> |
| 228 | The following sections describe each part of the proposed BSP format. |
| 229 | </para> |
| 230 | |
| 231 | <section id="bsp-filelayout-license"> |
| 232 | <title>License Files</title> |
| 233 | |
| 234 | <para> |
| 235 | You can find these files in the BSP Layer at: |
| 236 | <literallayout class='monospaced'> |
| 237 | meta-<replaceable>bsp_name</replaceable>/<replaceable>bsp_license_file</replaceable> |
| 238 | </literallayout> |
| 239 | </para> |
| 240 | |
| 241 | <para> |
| 242 | These optional files satisfy licensing requirements for the BSP. |
| 243 | The type or types of files here can vary depending on the licensing requirements. |
| 244 | For example, in the eMenlow BSP all licensing requirements are handled with the |
| 245 | <filename>COPYING.MIT</filename> file. |
| 246 | </para> |
| 247 | |
| 248 | <para> |
| 249 | Licensing files can be MIT, BSD, GPLv*, and so forth. |
| 250 | These files are recommended for the BSP but are optional and totally up to the BSP developer. |
| 251 | </para> |
| 252 | </section> |
| 253 | |
| 254 | <section id="bsp-filelayout-readme"> |
| 255 | <title>README File</title> |
| 256 | <para> |
| 257 | You can find this file in the BSP Layer at: |
| 258 | <literallayout class='monospaced'> |
| 259 | meta-<replaceable>bsp_name</replaceable>/README |
| 260 | </literallayout> |
| 261 | </para> |
| 262 | |
| 263 | <para> |
| 264 | This file provides information on how to boot the live images that are optionally |
| 265 | included in the <filename>binary/</filename> directory. |
| 266 | The <filename>README</filename> file also provides special information needed for |
| 267 | building the image. |
| 268 | </para> |
| 269 | |
| 270 | <para> |
| 271 | At a minimum, the <filename>README</filename> file must |
| 272 | contain a list of dependencies, such as the names of |
| 273 | any other layers on which the BSP depends and the name of |
| 274 | the BSP maintainer with his or her contact information. |
| 275 | </para> |
| 276 | </section> |
| 277 | |
| 278 | <section id="bsp-filelayout-readme-sources"> |
| 279 | <title>README.sources File</title> |
| 280 | <para> |
| 281 | You can find this file in the BSP Layer at: |
| 282 | <literallayout class='monospaced'> |
| 283 | meta-<replaceable>bsp_name</replaceable>/README.sources |
| 284 | </literallayout> |
| 285 | </para> |
| 286 | |
| 287 | <para> |
| 288 | This file provides information on where to locate the BSP |
| 289 | source files used to build the images (if any) that reside in |
| 290 | <filename>meta-<replaceable>bsp_name</replaceable>/binary</filename>. |
| 291 | Images in the <filename>binary</filename> would be images |
| 292 | released with the BSP. |
| 293 | The information in the <filename>README.sources</filename> |
| 294 | file also helps you find the |
| 295 | <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> |
| 296 | used to generate the images that ship with the BSP. |
| 297 | <note> |
| 298 | If the BSP's <filename>binary</filename> directory is |
| 299 | missing or the directory has no images, an existing |
| 300 | <filename>README.sources</filename> file is |
| 301 | meaningless. |
| 302 | </note> |
| 303 | </para> |
| 304 | </section> |
| 305 | |
| 306 | <section id="bsp-filelayout-binary"> |
| 307 | <title>Pre-built User Binaries</title> |
| 308 | <para> |
| 309 | You can find these files in the BSP Layer at: |
| 310 | <literallayout class='monospaced'> |
| 311 | meta-<replaceable>bsp_name</replaceable>/binary/<replaceable>bootable_images</replaceable> |
| 312 | </literallayout> |
| 313 | </para> |
| 314 | |
| 315 | <para> |
| 316 | This optional area contains useful pre-built kernels and |
| 317 | user-space filesystem images released with the BSP that are |
| 318 | appropriate to the target system. |
| 319 | This directory typically contains graphical (e.g. Sato) and |
| 320 | minimal live images when the BSP tarball has been created and |
| 321 | made available in the |
| 322 | <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website. |
| 323 | You can use these kernels and images to get a system running |
| 324 | and quickly get started on development tasks. |
| 325 | </para> |
| 326 | |
| 327 | <para> |
| 328 | The exact types of binaries present are highly |
| 329 | hardware-dependent. |
| 330 | The <filename>README</filename> file should be present in the |
| 331 | BSP Layer and it will explain how to use the images with the |
| 332 | target hardware. |
| 333 | Additionally, the <filename>README.sources</filename> file |
| 334 | should be present to locate the sources used to build the |
| 335 | images and provide information on the Metadata. |
| 336 | </para> |
| 337 | </section> |
| 338 | |
| 339 | <section id='bsp-filelayout-layer'> |
| 340 | <title>Layer Configuration File</title> |
| 341 | <para> |
| 342 | You can find this file in the BSP Layer at: |
| 343 | <literallayout class='monospaced'> |
| 344 | meta-<replaceable>bsp_name</replaceable>/conf/layer.conf |
| 345 | </literallayout> |
| 346 | </para> |
| 347 | |
| 348 | <para> |
| 349 | The <filename>conf/layer.conf</filename> file identifies the file structure as a |
| 350 | layer, identifies the |
| 351 | contents of the layer, and contains information about how the build |
| 352 | system should use it. |
| 353 | Generally, a standard boilerplate file such as the following works. |
| 354 | In the following example, you would replace "<replaceable>bsp</replaceable>" and |
| 355 | "<replaceable>_bsp</replaceable>" with the actual name |
| 356 | of the BSP (i.e. <replaceable>bsp_name</replaceable> from the example template). |
| 357 | </para> |
| 358 | |
| 359 | <para> |
| 360 | <literallayout class='monospaced'> |
| 361 | # We have a conf and classes directory, add to BBPATH |
| 362 | BBPATH .= ":${LAYERDIR}" |
| 363 | |
| 364 | # We have a recipes directory, add to BBFILES |
| 365 | BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ |
| 366 | ${LAYERDIR}/recipes-*/*/*.bbappend" |
| 367 | |
| 368 | BBFILE_COLLECTIONS += "<replaceable>bsp</replaceable>" |
| 369 | BBFILE_PATTERN_<replaceable>bsp</replaceable> = "^${LAYERDIR}/" |
| 370 | BBFILE_PRIORITY_<replaceable>bsp</replaceable> = "6" |
| 371 | |
| 372 | LAYERDEPENDS_<replaceable>bsp</replaceable> = "intel" |
| 373 | </literallayout> |
| 374 | </para> |
| 375 | |
| 376 | <para> |
| 377 | To illustrate the string substitutions, here are the corresponding statements |
| 378 | from the eEmenlow <filename>conf/layer.conf</filename> file: |
| 379 | <literallayout class='monospaced'> |
| 380 | # We have a conf and classes directory, add to BBPATH |
| 381 | BBPATH .= ":${LAYERDIR}" |
| 382 | |
| 383 | # We have recipes-* directories, add to BBFILES |
| 384 | BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ |
| 385 | ${LAYERDIR}/recipes-*/*/*.bbappend" |
| 386 | |
| 387 | BBFILE_COLLECTIONS += "emenlow" |
| 388 | BBFILE_PATTERN_emenlow := "^${LAYERDIR}/" |
| 389 | BBFILE_PRIORITY_emenlow = "6" |
| 390 | |
| 391 | LAYERDEPENDS_emenlow = "intel" |
| 392 | </literallayout> |
| 393 | </para> |
| 394 | |
| 395 | <para> |
| 396 | This file simply makes |
| 397 | <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> |
| 398 | aware of the recipes and configuration directories. |
| 399 | The file must exist so that the OpenEmbedded build system can recognize the BSP. |
| 400 | </para> |
| 401 | </section> |
| 402 | |
| 403 | <section id="bsp-filelayout-machine"> |
| 404 | <title>Hardware Configuration Options</title> |
| 405 | <para> |
| 406 | You can find these files in the BSP Layer at: |
| 407 | <literallayout class='monospaced'> |
| 408 | meta-<replaceable>bsp_name</replaceable>/conf/machine/*.conf |
| 409 | </literallayout> |
| 410 | </para> |
| 411 | |
| 412 | <para> |
| 413 | The machine files bind together all the information contained elsewhere |
| 414 | in the BSP into a format that the build system can understand. |
| 415 | If the BSP supports multiple machines, multiple machine configuration files |
| 416 | can be present. |
| 417 | These filenames correspond to the values to which users have set the |
| 418 | <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable. |
| 419 | </para> |
| 420 | |
| 421 | <para> |
| 422 | These files define things such as the kernel package to use |
| 423 | (<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink> |
| 424 | of virtual/kernel), the hardware drivers to |
| 425 | include in different types of images, any special software components |
| 426 | that are needed, any bootloader information, and also any special image |
| 427 | format requirements. |
| 428 | </para> |
| 429 | |
| 430 | <para> |
| 431 | Each BSP Layer requires at least one machine file. |
| 432 | However, you can supply more than one file. |
| 433 | </para> |
| 434 | |
| 435 | <para> |
| 436 | This configuration file could also include a hardware "tuning" |
| 437 | file that is commonly used to define the package architecture |
| 438 | and specify optimization flags, which are carefully chosen |
| 439 | to give best performance on a given processor. |
| 440 | </para> |
| 441 | |
| 442 | <para> |
| 443 | Tuning files are found in the <filename>meta/conf/machine/include</filename> |
| 444 | directory within the |
| 445 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. |
| 446 | For example, the <filename>ia32-base.inc</filename> file resides in the |
| 447 | <filename>meta/conf/machine/include</filename> directory. |
| 448 | </para> |
| 449 | |
| 450 | <para> |
| 451 | To use an include file, you simply include them in the |
| 452 | machine configuration file. |
| 453 | For example, the eEmenlow BSP |
| 454 | <filename>emenlow-noemgd.conf</filename> contains the |
| 455 | following statements: |
| 456 | <literallayout class='monospaced'> |
| 457 | require conf/machine/include/intel-core2-32-common.inc |
| 458 | require conf/machine/include/intel-common-pkgarch.inc |
| 459 | require conf/machine/include/meta-intel.inc |
| 460 | </literallayout> |
| 461 | </para> |
| 462 | </section> |
| 463 | |
| 464 | <section id='bsp-filelayout-misc-recipes'> |
| 465 | <title>Miscellaneous BSP-Specific Recipe Files</title> |
| 466 | <para> |
| 467 | You can find these files in the BSP Layer at: |
| 468 | <literallayout class='monospaced'> |
| 469 | meta-<replaceable>bsp_name</replaceable>/recipes-bsp/* |
| 470 | </literallayout> |
| 471 | </para> |
| 472 | |
| 473 | <para> |
| 474 | This optional directory contains miscellaneous recipe files for |
| 475 | the BSP. |
| 476 | Most notably would be the formfactor files. |
| 477 | For example, in the eMenlow BSP there is the |
| 478 | <filename>formfactor_0.0.bbappend</filename> file, which is an |
| 479 | append file used to augment the recipe that starts the build. |
| 480 | Furthermore, there are machine-specific settings used during |
| 481 | the build that are defined by the |
| 482 | <filename>machconfig</filename> file further down in the |
| 483 | directory. |
| 484 | In the eMenlow example, the <filename>machconfig</filename> |
| 485 | file supports the Video Electronics Standards Association |
| 486 | (VESA) graphics driver: |
| 487 | <literallayout class='monospaced'> |
| 488 | # Assume a USB mouse and keyboard are connected |
| 489 | HAVE_TOUCHSCREEN=0 |
| 490 | HAVE_KEYBOARD=1 |
| 491 | </literallayout> |
| 492 | </para> |
| 493 | |
| 494 | <note><para> |
| 495 | If a BSP does not have a formfactor entry, defaults are established according to |
| 496 | the formfactor configuration file that is installed by the main |
| 497 | formfactor recipe |
| 498 | <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>, |
| 499 | which is found in the |
| 500 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. |
| 501 | </para></note> |
| 502 | </section> |
| 503 | |
| 504 | <section id='bsp-filelayout-recipes-graphics'> |
| 505 | <title>Display Support Files</title> |
| 506 | <para> |
| 507 | You can find these files in the BSP Layer at: |
| 508 | <literallayout class='monospaced'> |
| 509 | meta-<replaceable>bsp_name</replaceable>/recipes-graphics/* |
| 510 | </literallayout> |
| 511 | </para> |
| 512 | |
| 513 | <para> |
| 514 | This optional directory contains recipes for the BSP if it has |
| 515 | special requirements for graphics support. |
| 516 | All files that are needed for the BSP to support a display are |
| 517 | kept here. |
| 518 | For example, the <filename>meta-emenlow</filename> layer, |
| 519 | which supports the eMenlow platform consisting of the |
| 520 | <trademark class='registered'>Intel</trademark> |
| 521 | <trademark class='trade'>Atom</trademark> |
| 522 | Z5xx processor with the |
| 523 | <trademark class='registered'>Intel</trademark> |
| 524 | System Controller Hub US15W, uses these files for supporting |
| 525 | the Video Electronics Standards Association (VESA) graphics: |
| 526 | <literallayout class='monospaced'> |
| 527 | meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend |
| 528 | meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd/xorg.conf |
| 529 | </literallayout> |
| 530 | </para> |
| 531 | </section> |
| 532 | |
| 533 | <section id='bsp-filelayout-kernel'> |
| 534 | <title>Linux Kernel Configuration</title> |
| 535 | <para> |
| 536 | You can find these files in the BSP Layer at: |
| 537 | <literallayout class='monospaced'> |
| 538 | meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux/linux-yocto*.bbappend |
| 539 | </literallayout> |
| 540 | </para> |
| 541 | |
| 542 | <para> |
| 543 | These files append your specific changes to the main kernel recipe you are using. |
| 544 | </para> |
| 545 | <para> |
| 546 | For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the |
| 547 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> |
| 548 | at <filename>meta/recipes-kernel/linux</filename>. |
| 549 | You can append your specific changes to the kernel recipe by using a |
| 550 | similarly named append file, which is located in the BSP Layer (e.g. |
| 551 | the <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory). |
| 552 | </para> |
| 553 | <para> |
| 554 | Suppose you are using the <filename>linux-yocto_3.14.bb</filename> recipe to build |
| 555 | the kernel. |
| 556 | In other words, you have selected the kernel in your |
| 557 | <replaceable>bsp_name</replaceable><filename>.conf</filename> file by adding these types |
| 558 | of statements: |
| 559 | <literallayout class='monospaced'> |
| 560 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" |
| 561 | PREFERRED_VERSION_linux-yocto ?= "3.14%" |
| 562 | </literallayout> |
| 563 | <note> |
| 564 | When the preferred provider is assumed by default, the |
| 565 | <filename>PREFERRED_PROVIDER</filename> statement does not appear in the |
| 566 | <replaceable>bsp_name</replaceable><filename>.conf</filename> file. |
| 567 | </note> |
| 568 | You would use the <filename>linux-yocto_3.14.bbappend</filename> file to append |
| 569 | specific BSP settings to the kernel, thus configuring the kernel for your particular BSP. |
| 570 | </para> |
| 571 | <para> |
| 572 | As an example, look at the existing eMenlow BSP. |
| 573 | The append file used is: |
| 574 | <literallayout class='monospaced'> |
| 575 | meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend |
| 576 | </literallayout> |
| 577 | The following listing shows the file. |
| 578 | Be aware that the actual commit ID strings in this example listing might be different |
| 579 | than the actual strings in the file from the <filename>meta-intel</filename> |
| 580 | Git source repository. |
| 581 | <literallayout class='monospaced'> |
| 582 | FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" |
| 583 | |
| 584 | COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd" |
| 585 | KMACHINE_emenlow-noemgd = "emenlow" |
| 586 | KBRANCH_emenlow-noemgd = "standard/base" |
| 587 | KERNEL_FEATURES_append_emenlow-noemgd = " features/drm-gma500/drm-gma500.scc" |
| 588 | |
| 589 | LINUX_VERSION_emenlow-noemgd = "3.14.19" |
| 590 | SRCREV_machine_emenlow-noemgd = "902f34d36102a4b2008b776ecae686f80d307e12" |
| 591 | SRCREV_meta_emenlow-noemgd = "28e39741b8b3018334021d981369d3fd61f18f5b" |
| 592 | </literallayout> |
| 593 | This append file contains statements used to support the |
| 594 | eMenlow BSP. |
| 595 | The file defines machines using the |
| 596 | <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink> |
| 597 | variable and uses the |
| 598 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink> |
| 599 | variable to ensure the machine name used by the OpenEmbedded |
| 600 | build system maps to the machine name used by the Linux Yocto |
| 601 | kernel. |
| 602 | The file also uses the optional |
| 603 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> |
| 604 | variable to ensure the build process uses the |
| 605 | <filename>standard/emenlow</filename> kernel branch. |
| 606 | The |
| 607 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink> |
| 608 | variable enables features specific to the kernel |
| 609 | (e.g. Intel GMA-500 DRM Driver in this case). |
| 610 | The append file points to specific commits in the |
| 611 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> |
| 612 | Git repository and the <filename>meta</filename> Git repository |
| 613 | branches to identify the exact kernel needed to build the |
| 614 | eMenlow BSP. |
| 615 | </para> |
| 616 | |
| 617 | <para> |
| 618 | One thing missing in this particular BSP, which you will typically need when |
| 619 | developing a BSP, is the kernel configuration file (<filename>.config</filename>) for your BSP. |
| 620 | When developing a BSP, you probably have a kernel configuration file or a set of kernel |
| 621 | configuration files that, when taken together, define the kernel configuration for your BSP. |
| 622 | You can accomplish this definition by putting the configurations in a file or a set of files |
| 623 | inside a directory located at the same level as your kernel's append file and having the same |
| 624 | name as the kernel's main recipe file. |
| 625 | With all these conditions met, simply reference those files in the |
| 626 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> |
| 627 | statement in the append file. |
| 628 | </para> |
| 629 | |
| 630 | <para> |
| 631 | For example, suppose you had some configuration options in a file called |
| 632 | <filename>network_configs.cfg</filename>. |
| 633 | You can place that file inside a directory named <filename>linux-yocto</filename> and then add |
| 634 | a <filename>SRC_URI</filename> statement such as the following to the append file. |
| 635 | When the OpenEmbedded build system builds the kernel, the configuration options are |
| 636 | picked up and applied. |
| 637 | <literallayout class='monospaced'> |
| 638 | SRC_URI += "file://network_configs.cfg" |
| 639 | </literallayout> |
| 640 | </para> |
| 641 | |
| 642 | <para> |
| 643 | To group related configurations into multiple files, you perform a similar procedure. |
| 644 | Here is an example that groups separate configurations specifically for Ethernet and graphics |
| 645 | into their own files and adds the configurations |
| 646 | by using a <filename>SRC_URI</filename> statement like the following in your append file: |
| 647 | <literallayout class='monospaced'> |
| 648 | SRC_URI += "file://myconfig.cfg \ |
| 649 | file://eth.cfg \ |
| 650 | file://gfx.cfg" |
| 651 | </literallayout> |
| 652 | </para> |
| 653 | |
| 654 | <para> |
| 655 | The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> |
| 656 | variable is in boilerplate form in the |
| 657 | previous example in order to make it easy to do that. |
| 658 | This variable must be in your layer or BitBake will not find the patches or |
| 659 | configurations even if you have them in your <filename>SRC_URI</filename>. |
| 660 | The <filename>FILESEXTRAPATHS</filename> variable enables the build process to |
| 661 | find those configuration files. |
| 662 | </para> |
| 663 | |
| 664 | <note> |
| 665 | <para> |
| 666 | Other methods exist to accomplish grouping and defining configuration options. |
| 667 | For example, if you are working with a local clone of the kernel repository, |
| 668 | you could checkout the kernel's <filename>meta</filename> branch, make your changes, |
| 669 | and then push the changes to the local bare clone of the kernel. |
| 670 | The result is that you directly add configuration options to the |
| 671 | <filename>meta</filename> branch for your BSP. |
| 672 | The configuration options will likely end up in that location anyway if the BSP gets |
| 673 | added to the Yocto Project. |
| 674 | </para> |
| 675 | |
| 676 | <para> |
| 677 | In general, however, the Yocto Project maintainers take care of moving the |
| 678 | <filename>SRC_URI</filename>-specified |
| 679 | configuration options to the kernel's <filename>meta</filename> branch. |
| 680 | Not only is it easier for BSP developers to not have to worry about putting those |
| 681 | configurations in the branch, but having the maintainers do it allows them to apply |
| 682 | 'global' knowledge about the kinds of common configuration options multiple BSPs in |
| 683 | the tree are typically using. |
| 684 | This allows for promotion of common configurations into common features. |
| 685 | </para> |
| 686 | </note> |
| 687 | </section> |
| 688 | </section> |
| 689 | |
| 690 | <section id='requirements-and-recommendations-for-released-bsps'> |
| 691 | <title>Requirements and Recommendations for Released BSPs</title> |
| 692 | |
| 693 | <para> |
| 694 | Certain requirements exist for a released BSP to be considered |
| 695 | compliant with the Yocto Project. |
| 696 | Additionally, recommendations also exist. |
| 697 | This section describes the requirements and recommendations for |
| 698 | released BSPs. |
| 699 | </para> |
| 700 | |
| 701 | <section id='released-bsp-requirements'> |
| 702 | <title>Released BSP Requirements</title> |
| 703 | |
| 704 | <para> |
| 705 | Before looking at BSP requirements, you should consider the following: |
| 706 | <itemizedlist> |
| 707 | <listitem><para>The requirements here assume the BSP layer is a well-formed, "legal" |
| 708 | layer that can be added to the Yocto Project. |
| 709 | For guidelines on creating a layer that meets these base requirements, see the |
| 710 | "<link linkend='bsp-layers'>BSP Layers</link>" and the |
| 711 | "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding |
| 712 | and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem> |
| 713 | <listitem><para>The requirements in this section apply regardless of how you |
| 714 | ultimately package a BSP. |
| 715 | You should consult the packaging and distribution guidelines for your |
| 716 | specific release process. |
| 717 | For an example of packaging and distribution requirements, see the |
| 718 | "<ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third Party BSP Release Process</ulink>" |
| 719 | wiki page.</para></listitem> |
| 720 | <listitem><para>The requirements for the BSP as it is made available to a developer |
| 721 | are completely independent of the released form of the BSP. |
| 722 | For example, the BSP Metadata can be contained within a Git repository |
| 723 | and could have a directory structure completely different from what appears |
| 724 | in the officially released BSP layer.</para></listitem> |
| 725 | <listitem><para>It is not required that specific packages or package |
| 726 | modifications exist in the BSP layer, beyond the requirements for general |
| 727 | compliance with the Yocto Project. |
| 728 | For example, no requirement exists dictating that a specific kernel or |
| 729 | kernel version be used in a given BSP.</para></listitem> |
| 730 | </itemizedlist> |
| 731 | </para> |
| 732 | |
| 733 | <para> |
| 734 | Following are the requirements for a released BSP that conforms to the |
| 735 | Yocto Project: |
| 736 | <itemizedlist> |
| 737 | <listitem><para><emphasis>Layer Name:</emphasis> |
| 738 | The BSP must have a layer name that follows the Yocto |
| 739 | Project standards. |
| 740 | For information on BSP layer names, see the |
| 741 | "<link linkend='bsp-layers'>BSP Layers</link>" section. |
| 742 | </para></listitem> |
| 743 | <listitem><para><emphasis>File System Layout:</emphasis> |
| 744 | When possible, use the same directory names in your |
| 745 | BSP layer as listed in the <filename>recipes.txt</filename> file. |
| 746 | In particular, you should place recipes |
| 747 | (<filename>.bb</filename> files) and recipe |
| 748 | modifications (<filename>.bbappend</filename> files) into |
| 749 | <filename>recipes-*</filename> subdirectories by functional area |
| 750 | as outlined in <filename>recipes.txt</filename>. |
| 751 | If you cannot find a category in <filename>recipes.txt</filename> |
| 752 | to fit a particular recipe, you can make up your own |
| 753 | <filename>recipes-*</filename> subdirectory. |
| 754 | You can find <filename>recipes.txt</filename> in the |
| 755 | <filename>meta</filename> directory of the |
| 756 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, |
| 757 | or in the OpenEmbedded Core Layer |
| 758 | (<filename>openembedded-core</filename>) found at |
| 759 | <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>. |
| 760 | </para> |
| 761 | <para>Within any particular <filename>recipes-*</filename> category, the layout |
| 762 | should match what is found in the OpenEmbedded Core |
| 763 | Git repository (<filename>openembedded-core</filename>) |
| 764 | or the Source Directory (<filename>poky</filename>). |
| 765 | In other words, make sure you place related files in appropriately |
| 766 | related <filename>recipes-*</filename> subdirectories specific to the |
| 767 | recipe's function, or within a subdirectory containing a set of closely-related |
| 768 | recipes. |
| 769 | The recipes themselves should follow the general guidelines |
| 770 | for recipes used in the Yocto Project found in the |
| 771 | "<ulink url='http://openembedded.org/wiki/Styleguide'>OpenEmbedded Style Guide</ulink>". |
| 772 | </para></listitem> |
| 773 | <listitem><para><emphasis>License File:</emphasis> |
| 774 | You must include a license file in the |
| 775 | <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. |
| 776 | This license covers the BSP Metadata as a whole. |
| 777 | You must specify which license to use since there is no |
| 778 | default license if one is not specified. |
| 779 | See the |
| 780 | <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/COPYING.MIT'><filename>COPYING.MIT</filename></ulink> |
| 781 | file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer |
| 782 | as an example.</para></listitem> |
| 783 | <listitem><para><emphasis>README File:</emphasis> |
| 784 | You must include a <filename>README</filename> file in the |
| 785 | <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. |
| 786 | See the |
| 787 | <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README'><filename>README</filename></ulink> |
| 788 | file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer |
| 789 | as an example.</para> |
| 790 | <para>At a minimum, the <filename>README</filename> file should |
| 791 | contain the following: |
| 792 | <itemizedlist> |
| 793 | <listitem><para>A brief description about the hardware the BSP |
| 794 | targets.</para></listitem> |
| 795 | <listitem><para>A list of all the dependencies |
| 796 | on which a BSP layer depends. |
| 797 | These dependencies are typically a list of required layers needed |
| 798 | to build the BSP. |
| 799 | However, the dependencies should also contain information regarding |
| 800 | any other dependencies the BSP might have.</para></listitem> |
| 801 | <listitem><para>Any required special licensing information. |
| 802 | For example, this information includes information on |
| 803 | special variables needed to satisfy a EULA, |
| 804 | or instructions on information needed to build or distribute |
| 805 | binaries built from the BSP Metadata.</para></listitem> |
| 806 | <listitem><para>The name and contact information for the |
| 807 | BSP layer maintainer. |
| 808 | This is the person to whom patches and questions should |
| 809 | be sent. |
| 810 | For information on how to find the right person, see the |
| 811 | "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>" |
| 812 | section in the Yocto Project Development Manual. |
| 813 | </para></listitem> |
| 814 | <listitem><para>Instructions on how to build the BSP using the BSP |
| 815 | layer.</para></listitem> |
| 816 | <listitem><para>Instructions on how to boot the BSP build from |
| 817 | the BSP layer.</para></listitem> |
| 818 | <listitem><para>Instructions on how to boot the binary images |
| 819 | contained in the <filename>binary</filename> directory, |
| 820 | if present.</para></listitem> |
| 821 | <listitem><para>Information on any known bugs or issues that users |
| 822 | should know about when either building or booting the BSP |
| 823 | binaries.</para></listitem> |
| 824 | </itemizedlist></para></listitem> |
| 825 | <listitem><para><emphasis>README.sources File:</emphasis> |
| 826 | You must include a <filename>README.sources</filename> in the |
| 827 | <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. |
| 828 | This file specifies exactly where you can find the sources used to |
| 829 | generate the binary images contained in the |
| 830 | <filename>binary</filename> directory, if present. |
| 831 | See the |
| 832 | <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink> |
| 833 | file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer |
| 834 | as an example.</para></listitem> |
| 835 | <listitem><para><emphasis>Layer Configuration File:</emphasis> |
| 836 | You must include a <filename>conf/layer.conf</filename> in the |
| 837 | <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. |
| 838 | This file identifies the <filename>meta-<replaceable>bsp_name</replaceable></filename> |
| 839 | BSP layer as a layer to the build system.</para></listitem> |
| 840 | <listitem><para><emphasis>Machine Configuration File:</emphasis> |
| 841 | You must include one or more |
| 842 | <filename>conf/machine/<replaceable>bsp_name</replaceable>.conf</filename> |
| 843 | files in the <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. |
| 844 | These configuration files define machine targets that can be built |
| 845 | using the BSP layer. |
| 846 | Multiple machine configuration files define variations of machine |
| 847 | configurations that are supported by the BSP. |
| 848 | If a BSP supports multiple machine variations, you need to |
| 849 | adequately describe each variation in the BSP |
| 850 | <filename>README</filename> file. |
| 851 | Do not use multiple machine configuration files to describe disparate |
| 852 | hardware. |
| 853 | If you do have very different targets, you should create separate |
| 854 | BSP layers for each target. |
| 855 | <note>It is completely possible for a developer to structure the |
| 856 | working repository as a conglomeration of unrelated BSP |
| 857 | files, and to possibly generate BSPs targeted for release |
| 858 | from that directory using scripts or some other mechanism |
| 859 | (e.g. <filename>meta-yocto-bsp</filename> layer). |
| 860 | Such considerations are outside the scope of this document.</note> |
| 861 | </para></listitem> |
| 862 | </itemizedlist> |
| 863 | </para> |
| 864 | </section> |
| 865 | |
| 866 | <section id='released-bsp-recommendations'> |
| 867 | <title>Released BSP Recommendations</title> |
| 868 | |
| 869 | <para> |
| 870 | Following are recommendations for a released BSP that conforms to the |
| 871 | Yocto Project: |
| 872 | <itemizedlist> |
| 873 | <listitem><para><emphasis>Bootable Images:</emphasis> |
| 874 | BSP releases |
| 875 | can contain one or more bootable images. |
| 876 | Including bootable images allows users to easily try out the BSP |
| 877 | on their own hardware.</para> |
| 878 | <para>In some cases, it might not be convenient to include a |
| 879 | bootable image. |
| 880 | In this case, you might want to make two versions of the |
| 881 | BSP available: one that contains binary images, and one |
| 882 | that does not. |
| 883 | The version that does not contain bootable images avoids |
| 884 | unnecessary download times for users not interested in the images. |
| 885 | </para> |
| 886 | <para>If you need to distribute a BSP and include bootable images or build kernel and |
| 887 | filesystems meant to allow users to boot the BSP for evaluation |
| 888 | purposes, you should put the images and artifacts within a |
| 889 | <filename>binary/</filename> subdirectory located in the |
| 890 | <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. |
| 891 | <note>If you do include a bootable image as part of the BSP and the image |
| 892 | was built by software covered by the GPL or other open source licenses, |
| 893 | it is your responsibility to understand |
| 894 | and meet all licensing requirements, which could include distribution |
| 895 | of source files.</note></para></listitem> |
| 896 | <listitem><para><emphasis>Use a Yocto Linux Kernel:</emphasis> |
| 897 | Kernel recipes in the BSP should be based on a Yocto Linux kernel. |
| 898 | Basing your recipes on these kernels reduces the costs for maintaining |
| 899 | the BSP and increases its scalability. |
| 900 | See the <filename>Yocto Linux Kernel</filename> category in the |
| 901 | <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Source Repositories</ulink> |
| 902 | for these kernels.</para></listitem> |
| 903 | </itemizedlist> |
| 904 | </para> |
| 905 | </section> |
| 906 | </section> |
| 907 | |
| 908 | <section id='customizing-a-recipe-for-a-bsp'> |
| 909 | <title>Customizing a Recipe for a BSP</title> |
| 910 | |
| 911 | <para> |
| 912 | If you plan on customizing a recipe for a particular BSP, you need to do the |
| 913 | following: |
| 914 | <itemizedlist> |
| 915 | <listitem><para>Create a <filename>.bbappend</filename> |
| 916 | file for the modified recipe. |
| 917 | For information on using append files, see the |
| 918 | "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>" |
| 919 | section in the Yocto Project Development Manual. |
| 920 | </para></listitem> |
| 921 | <listitem><para> |
| 922 | Ensure your directory structure in the BSP layer |
| 923 | that supports your machine is such that it can be found |
| 924 | by the build system. |
| 925 | See the example later in this section for more information. |
| 926 | </para></listitem> |
| 927 | <listitem><para> |
| 928 | Put the append file in a directory whose name matches |
| 929 | the machine's name and is located in an appropriate |
| 930 | sub-directory inside the BSP layer (i.e. |
| 931 | <filename>recipes-bsp</filename>, <filename>recipes-graphics</filename>, |
| 932 | <filename>recipes-core</filename>, and so forth). |
| 933 | </para></listitem> |
| 934 | <listitem><para>Place the BSP-specific files in the proper directory |
| 935 | inside the BSP layer. |
| 936 | How expansive the layer is affects where you must place these files. |
| 937 | For example, if your layer supports several different machine types, |
| 938 | you need to be sure your layer's directory structure includes hierarchy |
| 939 | that separates the files out according to machine. |
| 940 | If your layer does not support multiple machines, the layer would not |
| 941 | have that additional hierarchy and the files would obviously not be |
| 942 | able to reside in a machine-specific directory. |
| 943 | </para></listitem> |
| 944 | </itemizedlist> |
| 945 | </para> |
| 946 | |
| 947 | <para> |
| 948 | Following is a specific example to help you better understand the process. |
| 949 | Consider an example that customizes a recipe by adding |
| 950 | a BSP-specific configuration file named <filename>interfaces</filename> to the |
| 951 | <filename>init-ifupdown_1.0.bb</filename> recipe for machine "xyz" where the |
| 952 | BSP layer also supports several other machines. |
| 953 | Do the following: |
| 954 | <orderedlist> |
| 955 | <listitem><para>Edit the <filename>init-ifupdown_1.0.bbappend</filename> file so that it |
| 956 | contains the following: |
| 957 | <literallayout class='monospaced'> |
| 958 | FILESEXTRAPATHS_prepend := "${THISDIR}/files:" |
| 959 | </literallayout> |
| 960 | The append file needs to be in the |
| 961 | <filename>meta-xyz/recipes-core/init-ifupdown</filename> directory. |
| 962 | </para></listitem> |
| 963 | <listitem><para>Create and place the new <filename>interfaces</filename> |
| 964 | configuration file in the BSP's layer here: |
| 965 | <literallayout class='monospaced'> |
| 966 | meta-xyz/recipes-core/init-ifupdown/files/xyz-machine-one/interfaces |
| 967 | </literallayout> |
| 968 | <note> |
| 969 | If the <filename>meta-xyz</filename> layer did not support |
| 970 | multiple machines, you would place the |
| 971 | <filename>interfaces</filename> configuration file in the |
| 972 | layer here: |
| 973 | <literallayout class='monospaced'> |
| 974 | meta-xyz/recipes-core/init-ifupdown/files/interfaces |
| 975 | </literallayout> |
| 976 | </note> |
| 977 | The |
| 978 | <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> |
| 979 | variable in the append files extends the search path |
| 980 | the build system uses to find files during the build. |
| 981 | Consequently, for this example you need to have the |
| 982 | <filename>files</filename> directory in the same location |
| 983 | as your append file.</para></listitem> |
| 984 | </orderedlist> |
| 985 | </para> |
| 986 | </section> |
| 987 | |
| 988 | <section id='bsp-licensing-considerations'> |
| 989 | <title>BSP Licensing Considerations</title> |
| 990 | |
| 991 | <para> |
| 992 | In some cases, a BSP contains separately licensed Intellectual Property (IP) |
| 993 | for a component or components. |
| 994 | For these cases, you are required to accept the terms of a commercial or other |
| 995 | type of license that requires some kind of explicit End User License Agreement (EULA). |
| 996 | Once the license is accepted, the OpenEmbedded build system can then build and |
| 997 | include the corresponding component in the final BSP image. |
| 998 | If the BSP is available as a pre-built image, you can download the image after |
| 999 | agreeing to the license or EULA. |
| 1000 | </para> |
| 1001 | |
| 1002 | <para> |
| 1003 | You could find that some separately licensed components that are essential |
| 1004 | for normal operation of the system might not have an unencumbered (or free) |
| 1005 | substitute. |
| 1006 | Without these essential components, the system would be non-functional. |
| 1007 | Then again, you might find that other licensed components that are simply |
| 1008 | 'good-to-have' or purely elective do have an unencumbered, free replacement |
| 1009 | component that you can use rather than agreeing to the separately licensed component. |
| 1010 | Even for components essential to the system, you might find an unencumbered component |
| 1011 | that is not identical but will work as a less-capable version of the |
| 1012 | licensed version in the BSP recipe. |
| 1013 | </para> |
| 1014 | |
| 1015 | <para> |
| 1016 | For cases where you can substitute a free component and still |
| 1017 | maintain the system's functionality, the "Downloads" page from the |
| 1018 | <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink> |
| 1019 | makes available de-featured BSPs |
| 1020 | that are completely free of any IP encumbrances. |
| 1021 | For these cases, you can use the substitution directly and |
| 1022 | without any further licensing requirements. |
| 1023 | If present, these fully de-featured BSPs are named appropriately |
| 1024 | different as compared to the names of the respective |
| 1025 | encumbered BSPs. |
| 1026 | If available, these substitutions are your |
| 1027 | simplest and most preferred options. |
| 1028 | Use of these substitutions of course assumes the resulting functionality meets |
| 1029 | system requirements. |
| 1030 | </para> |
| 1031 | |
| 1032 | <para> |
| 1033 | If however, a non-encumbered version is unavailable or |
| 1034 | it provides unsuitable functionality or quality, you can use an encumbered |
| 1035 | version. |
| 1036 | </para> |
| 1037 | |
| 1038 | <para> |
| 1039 | A couple different methods exist within the OpenEmbedded build system to |
| 1040 | satisfy the licensing requirements for an encumbered BSP. |
| 1041 | The following list describes them in order of preference: |
| 1042 | <orderedlist> |
| 1043 | <listitem><para><emphasis>Use the |
| 1044 | <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></ulink> |
| 1045 | variable to define the recipes that have commercial or other |
| 1046 | types of specially-licensed packages:</emphasis> |
| 1047 | For each of those recipes, you can |
| 1048 | specify a matching license string in a |
| 1049 | <filename>local.conf</filename> variable named |
| 1050 | <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></ulink>. |
| 1051 | Specifying the matching license string signifies that you agree to the license. |
| 1052 | Thus, the build system can build the corresponding recipe and include |
| 1053 | the component in the image. |
| 1054 | See the |
| 1055 | "<ulink url='&YOCTO_DOCS_REF_URL;#enabling-commercially-licensed-recipes'>Enabling |
| 1056 | Commercially Licensed Recipes</ulink>" section in the Yocto Project Reference |
| 1057 | Manual for details on how to use these variables.</para> |
| 1058 | <para>If you build as you normally would, without |
| 1059 | specifying any recipes in the |
| 1060 | <filename>LICENSE_FLAGS_WHITELIST</filename>, the build stops and |
| 1061 | provides you with the list of recipes that you have |
| 1062 | tried to include in the image that need entries in |
| 1063 | the <filename>LICENSE_FLAGS_WHITELIST</filename>. |
| 1064 | Once you enter the appropriate license flags into the whitelist, |
| 1065 | restart the build to continue where it left off. |
| 1066 | During the build, the prompt will not appear again |
| 1067 | since you have satisfied the requirement.</para> |
| 1068 | <para>Once the appropriate license flags are on the white list |
| 1069 | in the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, you |
| 1070 | can build the encumbered image with no change at all |
| 1071 | to the normal build process.</para></listitem> |
| 1072 | <listitem><para><emphasis>Get a pre-built version of the BSP:</emphasis> |
| 1073 | You can get this type of BSP by visiting the |
| 1074 | "Downloads" page of the |
| 1075 | <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>. |
| 1076 | You can download BSP tarballs that contain proprietary components |
| 1077 | after agreeing to the licensing |
| 1078 | requirements of each of the individually encumbered |
| 1079 | packages as part of the download process. |
| 1080 | Obtaining the BSP this way allows you to access an encumbered |
| 1081 | image immediately after agreeing to the |
| 1082 | click-through license agreements presented by the |
| 1083 | website. |
| 1084 | Note that if you want to build the image |
| 1085 | yourself using the recipes contained within the BSP |
| 1086 | tarball, you will still need to create an |
| 1087 | appropriate <filename>LICENSE_FLAGS_WHITELIST</filename> to match the |
| 1088 | encumbered recipes in the BSP.</para></listitem> |
| 1089 | </orderedlist> |
| 1090 | </para> |
| 1091 | |
| 1092 | <note> |
| 1093 | Pre-compiled images are bundled with |
| 1094 | a time-limited kernel that runs for a |
| 1095 | predetermined amount of time (10 days) before it forces |
| 1096 | the system to reboot. |
| 1097 | This limitation is meant to discourage direct redistribution |
| 1098 | of the image. |
| 1099 | You must eventually rebuild the image if you want to remove this restriction. |
| 1100 | </note> |
| 1101 | </section> |
| 1102 | |
| 1103 | <section id='using-the-yocto-projects-bsp-tools'> |
| 1104 | <title>Using the Yocto Project's BSP Tools</title> |
| 1105 | |
| 1106 | <para> |
| 1107 | The Yocto Project includes a couple of tools that enable |
| 1108 | you to create a <link linkend='bsp-layers'>BSP layer</link> |
| 1109 | from scratch and do basic configuration and maintenance |
| 1110 | of the kernel without ever looking at a Metadata file. |
| 1111 | These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>, |
| 1112 | respectively. |
| 1113 | </para> |
| 1114 | |
| 1115 | <para> |
| 1116 | The following sections describe the common location and help features as well |
| 1117 | as provide details for the |
| 1118 | <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> tools. |
| 1119 | </para> |
| 1120 | |
| 1121 | <section id='common-features'> |
| 1122 | <title>Common Features</title> |
| 1123 | |
| 1124 | <para> |
| 1125 | Designed to have a command interface somewhat like |
| 1126 | <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>, each |
| 1127 | tool is structured as a set of sub-commands under a |
| 1128 | top-level command. |
| 1129 | The top-level command (<filename>yocto-bsp</filename> |
| 1130 | or <filename>yocto-kernel</filename>) itself does |
| 1131 | nothing but invoke or provide help on the sub-commands |
| 1132 | it supports. |
| 1133 | </para> |
| 1134 | |
| 1135 | <para> |
| 1136 | Both tools reside in the <filename>scripts/</filename> subdirectory |
| 1137 | of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. |
| 1138 | Consequently, to use the scripts, you must <filename>source</filename> the |
| 1139 | environment just as you would when invoking a build: |
| 1140 | <literallayout class='monospaced'> |
| 1141 | $ source oe-init-build-env <replaceable>build_dir</replaceable> |
| 1142 | </literallayout> |
| 1143 | </para> |
| 1144 | |
| 1145 | <para> |
| 1146 | The most immediately useful function is to get help on both tools. |
| 1147 | The built-in help system makes it easy to drill down at |
| 1148 | any time and view the syntax required for any specific command. |
| 1149 | Simply enter the name of the command with the <filename>help</filename> |
| 1150 | switch: |
| 1151 | <literallayout class='monospaced'> |
| 1152 | $ yocto-bsp help |
| 1153 | Usage: |
| 1154 | |
| 1155 | Create a customized Yocto BSP layer. |
| 1156 | |
| 1157 | usage: yocto-bsp [--version] [--help] COMMAND [ARGS] |
| 1158 | |
| 1159 | Current 'yocto-bsp' commands are: |
| 1160 | create Create a new Yocto BSP |
| 1161 | list List available values for options and BSP properties |
| 1162 | |
| 1163 | See 'yocto-bsp help COMMAND' for more information on a specific command. |
| 1164 | |
| 1165 | |
| 1166 | Options: |
| 1167 | --version show program's version number and exit |
| 1168 | -h, --help show this help message and exit |
| 1169 | -D, --debug output debug information |
| 1170 | </literallayout> |
| 1171 | </para> |
| 1172 | |
| 1173 | <para> |
| 1174 | Similarly, entering just the name of a sub-command shows the detailed usage |
| 1175 | for that sub-command: |
| 1176 | <literallayout class='monospaced'> |
| 1177 | $ yocto-bsp create |
| 1178 | |
| 1179 | Usage: |
| 1180 | |
| 1181 | Create a new Yocto BSP |
| 1182 | |
| 1183 | usage: yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] |
| 1184 | [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] |
| 1185 | |
| 1186 | This command creates a Yocto BSP based on the specified parameters. |
| 1187 | The new BSP will be a new Yocto BSP layer contained by default within |
| 1188 | the top-level directory specified as 'meta-bsp-name'. The -o option |
| 1189 | can be used to place the BSP layer in a directory with a different |
| 1190 | name and location. |
| 1191 | |
| 1192 | ... |
| 1193 | </literallayout> |
| 1194 | </para> |
| 1195 | |
| 1196 | <para> |
| 1197 | For any sub-command, you can use the word "help" option just before the |
| 1198 | sub-command to get more extensive documentation: |
| 1199 | <literallayout class='monospaced'> |
| 1200 | $ yocto-bsp help create |
| 1201 | |
| 1202 | NAME |
| 1203 | yocto-bsp create - Create a new Yocto BSP |
| 1204 | |
| 1205 | SYNOPSIS |
| 1206 | yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] |
| 1207 | [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] |
| 1208 | |
| 1209 | DESCRIPTION |
| 1210 | This command creates a Yocto BSP based on the specified |
| 1211 | parameters. The new BSP will be a new Yocto BSP layer contained |
| 1212 | by default within the top-level directory specified as |
| 1213 | 'meta-bsp-name'. The -o option can be used to place the BSP layer |
| 1214 | in a directory with a different name and location. |
| 1215 | |
| 1216 | The value of the 'karch' parameter determines the set of files |
| 1217 | that will be generated for the BSP, along with the specific set of |
| 1218 | 'properties' that will be used to fill out the BSP-specific |
| 1219 | portions of the BSP. The possible values for the 'karch' parameter |
| 1220 | can be listed via 'yocto-bsp list karch'. |
| 1221 | |
| 1222 | ... |
| 1223 | </literallayout> |
| 1224 | </para> |
| 1225 | |
| 1226 | <para> |
| 1227 | Now that you know where these two commands reside and how to access information |
| 1228 | on them, you should find it relatively straightforward to discover the commands |
| 1229 | necessary to create a BSP and perform basic kernel maintenance on that BSP using |
| 1230 | the tools. |
| 1231 | <note> |
| 1232 | You can also use the <filename>yocto-layer</filename> tool to create |
| 1233 | a "generic" layer. |
| 1234 | For information on this tool, see the |
| 1235 | "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</ulink>" |
| 1236 | section in the Yocto Project Development Guide. |
| 1237 | </note> |
| 1238 | </para> |
| 1239 | |
| 1240 | <para> |
| 1241 | The next sections provide a concrete starting point to expand on a few points that |
| 1242 | might not be immediately obvious or that could use further explanation. |
| 1243 | </para> |
| 1244 | </section> |
| 1245 | |
| 1246 | |
| 1247 | <section id='creating-a-new-bsp-layer-using-the-yocto-bsp-script'> |
| 1248 | <title>Creating a new BSP Layer Using the yocto-bsp Script</title> |
| 1249 | |
| 1250 | <para> |
| 1251 | The <filename>yocto-bsp</filename> script creates a new |
| 1252 | <link linkend='bsp-layers'>BSP layer</link> for any architecture supported |
| 1253 | by the Yocto Project, as well as QEMU versions of the same. |
| 1254 | The default mode of the script's operation is to prompt you for information needed |
| 1255 | to generate the BSP layer. |
| 1256 | </para> |
| 1257 | |
| 1258 | <para> |
| 1259 | For the current set of BSPs, the script prompts you for various important |
| 1260 | parameters such as: |
| 1261 | <itemizedlist> |
| 1262 | <listitem><para>The kernel to use</para></listitem> |
| 1263 | <listitem><para>The branch of that kernel to use (or re-use)</para></listitem> |
| 1264 | <listitem><para>Whether or not to use X, and if so, which drivers to use</para></listitem> |
| 1265 | <listitem><para>Whether to turn on SMP</para></listitem> |
| 1266 | <listitem><para>Whether the BSP has a keyboard</para></listitem> |
| 1267 | <listitem><para>Whether the BSP has a touchscreen</para></listitem> |
| 1268 | <listitem><para>Remaining configurable items associated with the BSP</para></listitem> |
| 1269 | </itemizedlist> |
| 1270 | </para> |
| 1271 | |
| 1272 | <para> |
| 1273 | You use the <filename>yocto-bsp create</filename> sub-command to create |
| 1274 | a new BSP layer. |
| 1275 | This command requires you to specify a particular kernel architecture |
| 1276 | (<filename>karch</filename>) on which to base the BSP. |
| 1277 | Assuming you have sourced the environment, you can use the |
| 1278 | <filename>yocto-bsp list karch</filename> sub-command to list the |
| 1279 | architectures available for BSP creation as follows: |
| 1280 | <literallayout class='monospaced'> |
| 1281 | $ yocto-bsp list karch |
| 1282 | Architectures available: |
| 1283 | qemu |
| 1284 | mips64 |
| 1285 | powerpc |
| 1286 | x86_64 |
| 1287 | arm |
| 1288 | mips |
| 1289 | i386 |
| 1290 | </literallayout> |
| 1291 | </para> |
| 1292 | |
| 1293 | <para> |
| 1294 | The remainder of this section presents an example that uses |
| 1295 | <filename>myarm</filename> as the machine name and <filename>qemu</filename> |
| 1296 | as the machine architecture. |
| 1297 | Of the available architectures, <filename>qemu</filename> is the only architecture |
| 1298 | that causes the script to prompt you further for an actual architecture. |
| 1299 | In every other way, this architecture is representative of how creating a BSP for |
| 1300 | an actual machine would work. |
| 1301 | The reason the example uses this architecture is because it is an emulated architecture |
| 1302 | and can easily be followed without requiring actual hardware. |
| 1303 | </para> |
| 1304 | |
| 1305 | <para> |
| 1306 | As the <filename>yocto-bsp create</filename> command runs, default values for |
| 1307 | the prompts appear in brackets. |
| 1308 | Pressing enter without supplying anything on the command line or pressing enter |
| 1309 | with an invalid response causes the script to accept the default value. |
| 1310 | Once the script completes, the new <filename>meta-myarm</filename> BSP layer |
| 1311 | is created in the current working directory. |
| 1312 | This example assumes you have sourced the |
| 1313 | <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink> |
| 1314 | setup script. |
| 1315 | </para> |
| 1316 | |
| 1317 | <para> |
| 1318 | Following is the complete example: |
| 1319 | <literallayout class='monospaced'> |
| 1320 | $ yocto-bsp create myarm qemu |
| 1321 | Checking basic git connectivity... |
| 1322 | Done. |
| 1323 | Which qemu architecture would you like to use? [default: i386] |
| 1324 | 1) i386 (32-bit) |
| 1325 | 2) x86_64 (64-bit) |
| 1326 | 3) ARM (32-bit) |
| 1327 | 4) PowerPC (32-bit) |
| 1328 | 5) MIPS (32-bit) |
| 1329 | 6) MIPS64 (64-bit) |
| 1330 | 3 |
| 1331 | Would you like to use the default (3.19) kernel? (y/n) [default: y] y |
| 1332 | Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] |
| 1333 | Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.19.git... |
| 1334 | Please choose a machine branch to base your new BSP branch on: [default: standard/base] |
| 1335 | 1) standard/arm-versatile-926ejs |
| 1336 | 2) standard/base |
| 1337 | 3) standard/beagleboard |
| 1338 | 4) standard/beaglebone |
| 1339 | 5) standard/ck |
| 1340 | 6) standard/common-pc |
| 1341 | 7) standard/crownbay |
| 1342 | 8) standard/edgerouter |
| 1343 | 9) standard/fsl-mpc8315e-rdb |
| 1344 | 10) standard/mti-malta32 |
| 1345 | 11) standard/mti-malta64 |
| 1346 | 12) standard/qemuarm64 |
| 1347 | 13) standard/qemuppc |
| 1348 | 1 |
| 1349 | Would you like SMP support? (y/n) [default: y] |
| 1350 | Does your BSP have a touchscreen? (y/n) [default: n] |
| 1351 | Does your BSP have a keyboard? (y/n) [default: y] |
| 1352 | New qemu BSP created in meta-myarm |
| 1353 | </literallayout> |
| 1354 | Take a closer look at the example now: |
| 1355 | <orderedlist> |
| 1356 | <listitem><para>For the QEMU architecture, |
| 1357 | the script first prompts you for which emulated architecture to use. |
| 1358 | In the example, we use the ARM architecture. |
| 1359 | </para></listitem> |
| 1360 | <listitem><para>The script then prompts you for the kernel. |
| 1361 | The default 3.19 kernel is acceptable. |
| 1362 | So, the example accepts the default. |
| 1363 | If you enter 'n', the script prompts you to further enter the kernel |
| 1364 | you do want to use.</para></listitem> |
| 1365 | <listitem><para>Next, the script asks whether you would like to have a new |
| 1366 | branch created especially for your BSP in the local |
| 1367 | <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink> |
| 1368 | Git repository . |
| 1369 | If not, then the script re-uses an existing branch.</para> |
| 1370 | <para>In this example, the default (or "yes") is accepted. |
| 1371 | Thus, a new branch is created for the BSP rather than using a common, shared |
| 1372 | branch. |
| 1373 | The new branch is the branch committed to for any patches you might later add. |
| 1374 | The reason a new branch is the default is that typically |
| 1375 | new BSPs do require BSP-specific patches. |
| 1376 | The tool thus assumes that most of time a new branch is required. |
| 1377 | </para></listitem> |
| 1378 | <listitem><para>Regardless of which choice you make in the previous step, |
| 1379 | you are now given the opportunity to select a particular machine branch on |
| 1380 | which to base your new BSP-specific machine branch |
| 1381 | (or to re-use if you had elected to not create a new branch). |
| 1382 | Because this example is generating an ARM-based BSP, the example |
| 1383 | uses <filename>#1</filename> at the prompt, which selects the ARM-versatile branch. |
| 1384 | </para></listitem> |
| 1385 | <listitem><para>The remainder of the prompts are routine. |
| 1386 | Defaults are accepted for each.</para></listitem> |
| 1387 | <listitem><para>By default, the script creates the new BSP Layer in the |
| 1388 | current working directory of the |
| 1389 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, |
| 1390 | (i.e. <filename>poky/build</filename>). |
| 1391 | </para></listitem> |
| 1392 | </orderedlist> |
| 1393 | </para> |
| 1394 | |
| 1395 | <para> |
| 1396 | Once the BSP Layer is created, you must add it to your |
| 1397 | <filename>bblayers.conf</filename> file. |
| 1398 | Here is an example: |
| 1399 | <literallayout class='monospaced'> |
| 1400 | BBLAYERS = ? " \ |
| 1401 | /usr/local/src/yocto/meta \ |
| 1402 | /usr/local/src/yocto/meta-yocto \ |
| 1403 | /usr/local/src/yocto/meta-yocto-bsp \ |
| 1404 | /usr/local/src/yocto/meta-myarm \ |
| 1405 | " |
| 1406 | |
| 1407 | BBLAYERS_NON_REMOVABLE ?= " \ |
| 1408 | /usr/local/src/yocto/meta \ |
| 1409 | /usr/local/src/yocto/meta-yocto \ |
| 1410 | " |
| 1411 | </literallayout> |
| 1412 | Adding the layer to this file allows the build system to build the BSP and |
| 1413 | the <filename>yocto-kernel</filename> tool to be able to find the layer and |
| 1414 | other Metadata it needs on which to operate. |
| 1415 | </para> |
| 1416 | </section> |
| 1417 | |
| 1418 | <section id='managing-kernel-patches-and-config-items-with-yocto-kernel'> |
| 1419 | <title>Managing Kernel Patches and Config Items with yocto-kernel</title> |
| 1420 | |
| 1421 | <para> |
| 1422 | Assuming you have created a <link linkend='bsp-layers'>BSP Layer</link> using |
| 1423 | <link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'> |
| 1424 | <filename>yocto-bsp</filename></link> and you added it to your |
| 1425 | <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> |
| 1426 | variable in the <filename>bblayers.conf</filename> file, you can now use |
| 1427 | the <filename>yocto-kernel</filename> script to add patches and configuration |
| 1428 | items to the BSP's kernel. |
| 1429 | </para> |
| 1430 | |
| 1431 | <para> |
| 1432 | The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches |
| 1433 | and kernel config settings to a BSP's kernel |
| 1434 | <filename>.bbappend</filename> file. |
| 1435 | All you need to do is use the appropriate sub-command. |
| 1436 | Recall that the easiest way to see exactly what sub-commands are available |
| 1437 | is to use the <filename>yocto-kernel</filename> built-in help as follows: |
| 1438 | <literallayout class='monospaced'> |
| 1439 | $ yocto-kernel --help |
| 1440 | Usage: |
| 1441 | Modify and list Yocto BSP kernel config items and patches. |
| 1442 | usage: yocto-kernel [--version] [--help] COMMAND [ARGS] |
| 1443 | Current 'yocto-kernel' commands are: |
| 1444 | config list List the modifiable set of bare kernel config options for a BSP |
| 1445 | config add Add or modify bare kernel config options for a BSP |
| 1446 | config rm Remove bare kernel config options from a BSP |
| 1447 | patch list List the patches associated with a BSP |
| 1448 | patch add Patch the Yocto kernel for a BSP |
| 1449 | patch rm Remove patches from a BSP |
| 1450 | feature list List the features used by a BSP |
| 1451 | feature add Have a BSP use a feature |
| 1452 | feature rm Have a BSP stop using a feature |
| 1453 | features list List the features available to BSPs |
| 1454 | feature describe Describe a particular feature |
| 1455 | feature create Create a new BSP-local feature |
| 1456 | feature destroy Remove a BSP-local feature |
| 1457 | See 'yocto-kernel help COMMAND' for more information on a specific command. |
| 1458 | Options: |
| 1459 | --version show program's version number and exit |
| 1460 | -h, --help show this help message and exit |
| 1461 | -D, --debug output debug information |
| 1462 | </literallayout> |
| 1463 | </para> |
| 1464 | |
| 1465 | <para> |
| 1466 | The <filename>yocto-kernel patch add</filename> sub-command allows you to add a |
| 1467 | patch to a BSP. |
| 1468 | The following example adds two patches to the <filename>myarm</filename> BSP: |
| 1469 | <literallayout class='monospaced'> |
| 1470 | $ yocto-kernel patch add myarm ~/test.patch |
| 1471 | Added patches: |
| 1472 | test.patch |
| 1473 | |
| 1474 | $ yocto-kernel patch add myarm ~/yocto-testmod.patch |
| 1475 | Added patches: |
| 1476 | yocto-testmod.patch |
| 1477 | </literallayout> |
| 1478 | <note>Although the previous example adds patches one at a time, it is possible |
| 1479 | to add multiple patches at the same time.</note> |
| 1480 | </para> |
| 1481 | |
| 1482 | <para> |
| 1483 | You can verify patches have been added by using the |
| 1484 | <filename>yocto-kernel patch list</filename> sub-command. |
| 1485 | Here is an example: |
| 1486 | <literallayout class='monospaced'> |
| 1487 | $ yocto-kernel patch list myarm |
| 1488 | The current set of machine-specific patches for myarm is: |
| 1489 | 1) test.patch |
| 1490 | 2) yocto-testmod.patch |
| 1491 | </literallayout> |
| 1492 | </para> |
| 1493 | |
| 1494 | <para> |
| 1495 | You can also use the <filename>yocto-kernel</filename> script to |
| 1496 | remove a patch using the <filename>yocto-kernel patch rm</filename> sub-command. |
| 1497 | Here is an example: |
| 1498 | <literallayout class='monospaced'> |
| 1499 | $ yocto-kernel patch rm myarm |
| 1500 | Specify the patches to remove: |
| 1501 | 1) test.patch |
| 1502 | 2) yocto-testmod.patch |
| 1503 | 1 |
| 1504 | Removed patches: |
| 1505 | test.patch |
| 1506 | </literallayout> |
| 1507 | </para> |
| 1508 | |
| 1509 | <para> |
| 1510 | Again, using the <filename>yocto-kernel patch list</filename> sub-command, |
| 1511 | you can verify that the patch was in fact removed: |
| 1512 | <literallayout class='monospaced'> |
| 1513 | $ yocto-kernel patch list myarm |
| 1514 | The current set of machine-specific patches for myarm is: |
| 1515 | 1) yocto-testmod.patch |
| 1516 | </literallayout> |
| 1517 | </para> |
| 1518 | |
| 1519 | <para> |
| 1520 | In a completely similar way, you can use the <filename>yocto-kernel config add</filename> |
| 1521 | sub-command to add one or more kernel config item settings to a BSP. |
| 1522 | The following commands add a couple of config items to the |
| 1523 | <filename>myarm</filename> BSP: |
| 1524 | <literallayout class='monospaced'> |
| 1525 | $ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y |
| 1526 | Added item: |
| 1527 | CONFIG_MISC_DEVICES=y |
| 1528 | |
| 1529 | $ yocto-kernel config add myarm CONFIG_YOCTO_TESTMOD=y |
| 1530 | Added item: |
| 1531 | CONFIG_YOCTO_TESTMOD=y |
| 1532 | </literallayout> |
| 1533 | <note> |
| 1534 | Although the previous example adds config items one at a time, it is possible |
| 1535 | to add multiple config items at the same time. |
| 1536 | </note> |
| 1537 | </para> |
| 1538 | |
| 1539 | <para> |
| 1540 | You can list the config items now associated with the BSP. |
| 1541 | Doing so shows you the config items you added as well as others associated |
| 1542 | with the BSP: |
| 1543 | <literallayout class='monospaced'> |
| 1544 | $ yocto-kernel config list myarm |
| 1545 | The current set of machine-specific kernel config items for myarm is: |
| 1546 | 1) CONFIG_MISC_DEVICES=y |
| 1547 | 2) CONFIG_YOCTO_TESTMOD=y |
| 1548 | </literallayout> |
| 1549 | </para> |
| 1550 | |
| 1551 | <para> |
| 1552 | Finally, you can remove one or more config items using the |
| 1553 | <filename>yocto-kernel config rm</filename> sub-command in a manner |
| 1554 | completely analogous to <filename>yocto-kernel patch rm</filename>. |
| 1555 | </para> |
| 1556 | </section> |
| 1557 | </section> |
| 1558 | </chapter> |