diff options
Diffstat (limited to 'documentation/bsp-guide')
| -rw-r--r-- | documentation/bsp-guide/bsp.rst | 1510 | ||||
| -rw-r--r-- | documentation/bsp-guide/figures/bsp-dev-flow.png | bin | 52657 -> 0 bytes | |||
| -rw-r--r-- | documentation/bsp-guide/figures/bsp-title.png | bin | 17388 -> 0 bytes | |||
| -rw-r--r-- | documentation/bsp-guide/history.rst | 73 | ||||
| -rw-r--r-- | documentation/bsp-guide/index.rst | 16 |
5 files changed, 0 insertions, 1599 deletions
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst deleted file mode 100644 index 93e9182490..0000000000 --- a/documentation/bsp-guide/bsp.rst +++ /dev/null | |||
| @@ -1,1510 +0,0 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | ************************************************ | ||
| 4 | Board Support Packages (BSP) - Developer's Guide | ||
| 5 | ************************************************ | ||
| 6 | |||
| 7 | A Board Support Package (BSP) is a collection of information that | ||
| 8 | defines how to support a particular hardware device, set of devices, or | ||
| 9 | hardware platform. The BSP includes information about the hardware | ||
| 10 | features present on the device and kernel configuration information | ||
| 11 | along with any additional hardware drivers required. The BSP also lists | ||
| 12 | any additional software components required in addition to a generic | ||
| 13 | Linux software stack for both essential and optional platform features. | ||
| 14 | |||
| 15 | This guide presents information about BSP layers, defines a structure | ||
| 16 | for components so that BSPs follow a commonly understood layout, | ||
| 17 | discusses how to customize a recipe for a BSP, addresses BSP licensing, | ||
| 18 | and provides information that shows you how to create a BSP | ||
| 19 | Layer using the :ref:`bitbake-layers <bsp-guide/bsp:Creating a new BSP Layer Using the \`\`bitbake-layers\`\` Script>` | ||
| 20 | tool. | ||
| 21 | |||
| 22 | BSP Layers | ||
| 23 | ========== | ||
| 24 | |||
| 25 | A BSP consists of a file structure inside a base directory. | ||
| 26 | Collectively, you can think of the base directory, its file structure, | ||
| 27 | and the contents as a BSP layer. Although not a strict requirement, BSP | ||
| 28 | layers in the Yocto Project use the following well-established naming | ||
| 29 | convention: :: | ||
| 30 | |||
| 31 | meta-bsp_root_name | ||
| 32 | |||
| 33 | The string "meta-" is prepended to the | ||
| 34 | machine or platform name, which is "bsp_root_name" in the above form. | ||
| 35 | |||
| 36 | .. note:: | ||
| 37 | |||
| 38 | Because the BSP layer naming convention is well-established, it is | ||
| 39 | advisable to follow it when creating layers. Technically speaking, a | ||
| 40 | BSP layer name does not need to start with ``meta-``. | ||
| 41 | However, various scripts and tools in the Yocto Project development | ||
| 42 | environment assume this convention. | ||
| 43 | |||
| 44 | To help understand the BSP layer concept, consider the BSPs that the | ||
| 45 | Yocto Project supports and provides with each release. You can see the | ||
| 46 | layers in the | ||
| 47 | :ref:`overview-manual/development-environment:yocto project source repositories` | ||
| 48 | through | ||
| 49 | a web interface at :yocto_git:`/`. If you go to that interface, | ||
| 50 | you will find a list of repositories under "Yocto Metadata Layers". | ||
| 51 | |||
| 52 | .. note:: | ||
| 53 | |||
| 54 | Layers that are no longer actively supported as part of the Yocto | ||
| 55 | Project appear under the heading "Yocto Metadata Layer Archive." | ||
| 56 | |||
| 57 | Each repository is a BSP layer supported by the Yocto Project (e.g. | ||
| 58 | ``meta-raspberrypi`` and ``meta-intel``). Each of these layers is a | ||
| 59 | repository unto itself and clicking on the layer name displays two URLs | ||
| 60 | from which you can clone the layer's repository to your local system. | ||
| 61 | Here is an example that clones the Raspberry Pi BSP layer: :: | ||
| 62 | |||
| 63 | $ git clone git://git.yoctoproject.org/meta-raspberrypi | ||
| 64 | |||
| 65 | In addition to BSP layers, the ``meta-yocto-bsp`` layer is part of the | ||
| 66 | shipped ``poky`` repository. The ``meta-yocto-bsp`` layer maintains | ||
| 67 | several "reference" BSPs including the ARM-based Beaglebone, MIPS-based | ||
| 68 | EdgeRouter, and generic versions of both 32-bit and 64-bit IA machines. | ||
| 69 | |||
| 70 | For information on typical BSP development workflow, see the | ||
| 71 | :ref:`bsp-guide/bsp:developing a board support package (bsp)` | ||
| 72 | section. For more | ||
| 73 | information on how to set up a local copy of source files from a Git | ||
| 74 | repository, see the | ||
| 75 | :ref:`dev-manual/start:locating yocto project source files` | ||
| 76 | section in the Yocto Project Development Tasks Manual. | ||
| 77 | |||
| 78 | The BSP layer's base directory (``meta-bsp_root_name``) is the root | ||
| 79 | directory of that Layer. This directory is what you add to the | ||
| 80 | :term:`BBLAYERS` variable in the | ||
| 81 | ``conf/bblayers.conf`` file found in your | ||
| 82 | :term:`Build Directory`, which is | ||
| 83 | established after you run the OpenEmbedded build environment setup | ||
| 84 | script (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). | ||
| 85 | Adding the root directory allows the :term:`OpenEmbedded Build System` | ||
| 86 | to recognize the BSP | ||
| 87 | layer and from it build an image. Here is an example: :: | ||
| 88 | |||
| 89 | BBLAYERS ?= " \ | ||
| 90 | /usr/local/src/yocto/meta \ | ||
| 91 | /usr/local/src/yocto/meta-poky \ | ||
| 92 | /usr/local/src/yocto/meta-yocto-bsp \ | ||
| 93 | /usr/local/src/yocto/meta-mylayer \ | ||
| 94 | " | ||
| 95 | |||
| 96 | .. note:: | ||
| 97 | |||
| 98 | Ordering and :term:`BBFILE_PRIORITY` for the layers listed in ``BBLAYERS`` | ||
| 99 | matter. For example, if multiple layers define a machine configuration, the | ||
| 100 | OpenEmbedded build system uses the last layer searched given similar layer | ||
| 101 | priorities. The build system works from the top-down through the layers | ||
| 102 | listed in ``BBLAYERS``. | ||
| 103 | |||
| 104 | Some BSPs require or depend on additional layers beyond the BSP's root | ||
| 105 | layer in order to be functional. In this case, you need to specify these | ||
| 106 | layers in the ``README`` "Dependencies" section of the BSP's root layer. | ||
| 107 | Additionally, if any build instructions exist for the BSP, you must add | ||
| 108 | them to the "Dependencies" section. | ||
| 109 | |||
| 110 | Some layers function as a layer to hold other BSP layers. These layers | ||
| 111 | are known as ":term:`container layers <Container Layer>`". An example of | ||
| 112 | this type of layer is OpenEmbedded's | ||
| 113 | `meta-openembedded <https://github.com/openembedded/meta-openembedded>`__ | ||
| 114 | layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers. | ||
| 115 | In cases like this, you need to include the names of the actual layers | ||
| 116 | you want to work with, such as: :: | ||
| 117 | |||
| 118 | BBLAYERS ?= " \ | ||
| 119 | /usr/local/src/yocto/meta \ | ||
| 120 | /usr/local/src/yocto/meta-poky \ | ||
| 121 | /usr/local/src/yocto/meta-yocto-bsp \ | ||
| 122 | /usr/local/src/yocto/meta-mylayer \ | ||
| 123 | .../meta-openembedded/meta-oe \ | ||
| 124 | .../meta-openembedded/meta-perl \ | ||
| 125 | .../meta-openembedded/meta-networking \ | ||
| 126 | " | ||
| 127 | |||
| 128 | and so on. | ||
| 129 | |||
| 130 | For more information on layers, see the | ||
| 131 | ":ref:`dev-manual/common-tasks:understanding and creating layers`" | ||
| 132 | section of the Yocto Project Development Tasks Manual. | ||
| 133 | |||
| 134 | Preparing Your Build Host to Work With BSP Layers | ||
| 135 | ================================================= | ||
| 136 | |||
| 137 | This section describes how to get your build host ready to work with BSP | ||
| 138 | layers. Once you have the host set up, you can create the layer as | ||
| 139 | described in the | ||
| 140 | ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`" | ||
| 141 | section. | ||
| 142 | |||
| 143 | .. note:: | ||
| 144 | |||
| 145 | For structural information on BSPs, see the | ||
| 146 | :ref:`bsp-guide/bsp:example filesystem layout` section. | ||
| 147 | |||
| 148 | #. *Set Up the Build Environment:* Be sure you are set up to use BitBake | ||
| 149 | in a shell. See the ":ref:`dev-manual/start:preparing the build host`" | ||
| 150 | section in the Yocto Project Development Tasks Manual for information on how | ||
| 151 | to get a build host ready that is either a native Linux machine or a machine | ||
| 152 | that uses CROPS. | ||
| 153 | |||
| 154 | #. *Clone the poky Repository:* You need to have a local copy of the | ||
| 155 | Yocto Project :term:`Source Directory` (i.e. a local | ||
| 156 | ``poky`` repository). See the | ||
| 157 | ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and | ||
| 158 | possibly the | ||
| 159 | ":ref:`dev-manual/start:checking out by branch in poky`" or | ||
| 160 | ":ref:`dev-manual/start:checking out by tag in poky`" | ||
| 161 | sections | ||
| 162 | all in the Yocto Project Development Tasks Manual for information on | ||
| 163 | how to clone the ``poky`` repository and check out the appropriate | ||
| 164 | branch for your work. | ||
| 165 | |||
| 166 | #. *Determine the BSP Layer You Want:* The Yocto Project supports many | ||
| 167 | BSPs, which are maintained in their own layers or in layers designed | ||
| 168 | to contain several BSPs. To get an idea of machine support through | ||
| 169 | BSP layers, you can look at the `index of | ||
| 170 | machines <&YOCTO_RELEASE_DL_URL;/machines>`__ for the release. | ||
| 171 | |||
| 172 | #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is | ||
| 173 | based on current Intel CPUs and devices, you can leverage this BSP | ||
| 174 | layer. For details on the ``meta-intel`` BSP layer, see the layer's | ||
| 175 | :yocto_git:`README </meta-intel/tree/README>` file. | ||
| 176 | |||
| 177 | #. *Navigate to Your Source Directory:* Typically, you set up the | ||
| 178 | ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g. | ||
| 179 | ``poky``). :: | ||
| 180 | |||
| 181 | $ cd /home/you/poky | ||
| 182 | |||
| 183 | #. *Clone the Layer:* :: | ||
| 184 | |||
| 185 | $ git clone git://git.yoctoproject.org/meta-intel.git | ||
| 186 | Cloning into 'meta-intel'... | ||
| 187 | remote: Counting objects: 15585, done. | ||
| 188 | remote: Compressing objects: 100% (5056/5056), done. | ||
| 189 | remote: Total 15585 (delta 9123), reused 15329 (delta 8867) | ||
| 190 | Receiving objects: 100% (15585/15585), 4.51 MiB | 3.19 MiB/s, done. | ||
| 191 | Resolving deltas: 100% (9123/9123), done. | ||
| 192 | Checking connectivity... done. | ||
| 193 | |||
| 194 | #. *Check Out the Proper Branch:* The branch you check out for | ||
| 195 | ``meta-intel`` must match the same branch you are using for the | ||
| 196 | Yocto Project release (e.g. ``&DISTRO_NAME_NO_CAP;``): :: | ||
| 197 | |||
| 198 | $ cd meta-intel | ||
| 199 | $ git checkout -b &DISTRO_NAME_NO_CAP; remotes/origin/&DISTRO_NAME_NO_CAP; | ||
| 200 | Branch &DISTRO_NAME_NO_CAP; set up to track remote branch | ||
| 201 | &DISTRO_NAME_NO_CAP; from origin. | ||
| 202 | Switched to a new branch '&DISTRO_NAME_NO_CAP;' | ||
| 203 | |||
| 204 | .. note:: | ||
| 205 | |||
| 206 | To see the available branch names in a cloned repository, use the ``git | ||
| 207 | branch -al`` command. See the | ||
| 208 | ":ref:`dev-manual/start:checking out by branch in poky`" | ||
| 209 | section in the Yocto Project Development Tasks Manual for more | ||
| 210 | information. | ||
| 211 | |||
| 212 | #. *Optionally Set Up an Alternative BSP Layer:* If your hardware can be | ||
| 213 | more closely leveraged to an existing BSP not within the | ||
| 214 | ``meta-intel`` BSP layer, you can clone that BSP layer. | ||
| 215 | |||
| 216 | The process is identical to the process used for the ``meta-intel`` | ||
| 217 | layer except for the layer's name. For example, if you determine that | ||
| 218 | your hardware most closely matches the ``meta-raspberrypi``, clone | ||
| 219 | that layer: :: | ||
| 220 | |||
| 221 | $ git clone git://git.yoctoproject.org/meta-raspberrypi | ||
| 222 | Cloning into 'meta-raspberrypi'... | ||
| 223 | remote: Counting objects: 4743, done. | ||
| 224 | remote: Compressing objects: 100% (2185/2185), done. | ||
| 225 | remote: Total 4743 (delta 2447), reused 4496 (delta 2258) | ||
| 226 | Receiving objects: 100% (4743/4743), 1.18 MiB | 0 bytes/s, done. | ||
| 227 | Resolving deltas: 100% (2447/2447), done. | ||
| 228 | Checking connectivity... done. | ||
| 229 | |||
| 230 | #. *Initialize the Build Environment:* While in the root directory of | ||
| 231 | the Source Directory (i.e. ``poky``), run the | ||
| 232 | :ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment | ||
| 233 | setup script to define the OpenEmbedded build environment on your | ||
| 234 | build host. :: | ||
| 235 | |||
| 236 | $ source oe-init-build-env | ||
| 237 | |||
| 238 | Among other things, the script creates the :term:`Build Directory`, which is | ||
| 239 | ``build`` in this case and is located in the :term:`Source Directory`. After | ||
| 240 | the script runs, your current working directory is set to the ``build`` | ||
| 241 | directory. | ||
| 242 | |||
| 243 | Example Filesystem Layout | ||
| 244 | ========================= | ||
| 245 | |||
| 246 | Defining a common BSP directory structure allows end-users to understand | ||
| 247 | and become familiar with that standard. A common format also encourages | ||
| 248 | standardization of software support for hardware. | ||
| 249 | |||
| 250 | The proposed form described in this section does have elements that are | ||
| 251 | specific to the OpenEmbedded build system. It is intended that | ||
| 252 | developers can use this structure with other build systems besides the | ||
| 253 | OpenEmbedded build system. It is also intended that it will be be simple | ||
| 254 | to extract information and convert it to other formats if required. The | ||
| 255 | OpenEmbedded build system, through its standard :ref:`layers mechanism | ||
| 256 | <overview-manual/yp-intro:the yocto project layer model>`, can | ||
| 257 | directly accept the format described as a layer. The BSP layer captures | ||
| 258 | all the hardware-specific details in one place using a standard format, | ||
| 259 | which is useful for any person wishing to use the hardware platform | ||
| 260 | regardless of the build system they are using. | ||
| 261 | |||
| 262 | The BSP specification does not include a build system or other tools - | ||
| 263 | the specification is concerned with the hardware-specific components | ||
| 264 | only. At the end-distribution point, you can ship the BSP layer combined | ||
| 265 | with a build system and other tools. Realize that it is important to | ||
| 266 | maintain the distinction that the BSP layer, a build system, and tools | ||
| 267 | are separate components that could be combined in certain end products. | ||
| 268 | |||
| 269 | Before looking at the recommended form for the directory structure | ||
| 270 | inside a BSP layer, you should be aware that some requirements do exist | ||
| 271 | in order for a BSP layer to be considered compliant with the Yocto | ||
| 272 | Project. For that list of requirements, see the | ||
| 273 | ":ref:`bsp-guide/bsp:released bsp requirements`" section. | ||
| 274 | |||
| 275 | Below is the typical directory structure for a BSP layer. While this | ||
| 276 | basic form represents the standard, realize that the actual layout for | ||
| 277 | individual BSPs could differ. :: | ||
| 278 | |||
| 279 | meta-bsp_root_name/ | ||
| 280 | meta-bsp_root_name/bsp_license_file | ||
| 281 | meta-bsp_root_name/README | ||
| 282 | meta-bsp_root_name/README.sources | ||
| 283 | meta-bsp_root_name/binary/bootable_images | ||
| 284 | meta-bsp_root_name/conf/layer.conf | ||
| 285 | meta-bsp_root_name/conf/machine/*.conf | ||
| 286 | meta-bsp_root_name/recipes-bsp/* | ||
| 287 | meta-bsp_root_name/recipes-core/* | ||
| 288 | meta-bsp_root_name/recipes-graphics/* | ||
| 289 | meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend | ||
| 290 | |||
| 291 | Below is an example of the Raspberry Pi BSP layer that is available from | ||
| 292 | the :yocto_git:`Source Respositories <>`: | ||
| 293 | |||
| 294 | .. code-block:: none | ||
| 295 | |||
| 296 | meta-raspberrypi/COPYING.MIT | ||
| 297 | meta-raspberrypi/README.md | ||
| 298 | meta-raspberrypi/classes | ||
| 299 | meta-raspberrypi/classes/sdcard_image-rpi.bbclass | ||
| 300 | meta-raspberrypi/conf/ | ||
| 301 | meta-raspberrypi/conf/layer.conf | ||
| 302 | meta-raspberrypi/conf/machine/ | ||
| 303 | meta-raspberrypi/conf/machine/raspberrypi-cm.conf | ||
| 304 | meta-raspberrypi/conf/machine/raspberrypi-cm3.conf | ||
| 305 | meta-raspberrypi/conf/machine/raspberrypi.conf | ||
| 306 | meta-raspberrypi/conf/machine/raspberrypi0-wifi.conf | ||
| 307 | meta-raspberrypi/conf/machine/raspberrypi0.conf | ||
| 308 | meta-raspberrypi/conf/machine/raspberrypi2.conf | ||
| 309 | meta-raspberrypi/conf/machine/raspberrypi3-64.conf | ||
| 310 | meta-raspberrypi/conf/machine/raspberrypi3.conf | ||
| 311 | meta-raspberrypi/conf/machine/include | ||
| 312 | meta-raspberrypi/conf/machine/include/rpi-base.inc | ||
| 313 | meta-raspberrypi/conf/machine/include/rpi-default-providers.inc | ||
| 314 | meta-raspberrypi/conf/machine/include/rpi-default-settings.inc | ||
| 315 | meta-raspberrypi/conf/machine/include/rpi-default-versions.inc | ||
| 316 | meta-raspberrypi/conf/machine/include/tune-arm1176jzf-s.inc | ||
| 317 | meta-raspberrypi/docs | ||
| 318 | meta-raspberrypi/docs/Makefile | ||
| 319 | meta-raspberrypi/docs/conf.py | ||
| 320 | meta-raspberrypi/docs/contributing.md | ||
| 321 | meta-raspberrypi/docs/extra-apps.md | ||
| 322 | meta-raspberrypi/docs/extra-build-config.md | ||
| 323 | meta-raspberrypi/docs/index.rst | ||
| 324 | meta-raspberrypi/docs/layer-contents.md | ||
| 325 | meta-raspberrypi/docs/readme.md | ||
| 326 | meta-raspberrypi/files | ||
| 327 | meta-raspberrypi/files/custom-licenses | ||
| 328 | meta-raspberrypi/files/custom-licenses/Broadcom | ||
| 329 | meta-raspberrypi/recipes-bsp | ||
| 330 | meta-raspberrypi/recipes-bsp/bootfiles | ||
| 331 | meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb | ||
| 332 | meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb | ||
| 333 | meta-raspberrypi/recipes-bsp/common | ||
| 334 | meta-raspberrypi/recipes-bsp/common/firmware.inc | ||
| 335 | meta-raspberrypi/recipes-bsp/formfactor | ||
| 336 | meta-raspberrypi/recipes-bsp/formfactor/formfactor | ||
| 337 | meta-raspberrypi/recipes-bsp/formfactor/formfactor/raspberrypi | ||
| 338 | meta-raspberrypi/recipes-bsp/formfactor/formfactor/raspberrypi/machconfig | ||
| 339 | meta-raspberrypi/recipes-bsp/formfactor/formfactor_0.0.bbappend | ||
| 340 | meta-raspberrypi/recipes-bsp/rpi-u-boot-src | ||
| 341 | meta-raspberrypi/recipes-bsp/rpi-u-boot-src/files | ||
| 342 | meta-raspberrypi/recipes-bsp/rpi-u-boot-src/files/boot.cmd.in | ||
| 343 | meta-raspberrypi/recipes-bsp/rpi-u-boot-src/rpi-u-boot-scr.bb | ||
| 344 | meta-raspberrypi/recipes-bsp/u-boot | ||
| 345 | meta-raspberrypi/recipes-bsp/u-boot/u-boot | ||
| 346 | meta-raspberrypi/recipes-bsp/u-boot/u-boot/*.patch | ||
| 347 | meta-raspberrypi/recipes-bsp/u-boot/u-boot_%.bbappend | ||
| 348 | meta-raspberrypi/recipes-connectivity | ||
| 349 | meta-raspberrypi/recipes-connectivity/bluez5 | ||
| 350 | meta-raspberrypi/recipes-connectivity/bluez5/bluez5 | ||
| 351 | meta-raspberrypi/recipes-connectivity/bluez5/bluez5/*.patch | ||
| 352 | meta-raspberrypi/recipes-connectivity/bluez5/bluez5/BCM43430A1.hcd | ||
| 353 | meta-raspberrypi/recipes-connectivity/bluez5/bluez5brcm43438.service | ||
| 354 | meta-raspberrypi/recipes-connectivity/bluez5/bluez5_%.bbappend | ||
| 355 | meta-raspberrypi/recipes-core | ||
| 356 | meta-raspberrypi/recipes-core/images | ||
| 357 | meta-raspberrypi/recipes-core/images/rpi-basic-image.bb | ||
| 358 | meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb | ||
| 359 | meta-raspberrypi/recipes-core/images/rpi-test-image.bb | ||
| 360 | meta-raspberrypi/recipes-core/packagegroups | ||
| 361 | meta-raspberrypi/recipes-core/packagegroups/packagegroup-rpi-test.bb | ||
| 362 | meta-raspberrypi/recipes-core/psplash | ||
| 363 | meta-raspberrypi/recipes-core/psplash/files | ||
| 364 | meta-raspberrypi/recipes-core/psplash/files/psplash-raspberrypi-img.h | ||
| 365 | meta-raspberrypi/recipes-core/psplash/psplash_git.bbappend | ||
| 366 | meta-raspberrypi/recipes-core/udev | ||
| 367 | meta-raspberrypi/recipes-core/udev/udev-rules-rpi | ||
| 368 | meta-raspberrypi/recipes-core/udev/udev-rules-rpi/99-com.rules | ||
| 369 | meta-raspberrypi/recipes-core/udev/udev-rules-rpi.bb | ||
| 370 | meta-raspberrypi/recipes-devtools | ||
| 371 | meta-raspberrypi/recipes-devtools/bcm2835 | ||
| 372 | meta-raspberrypi/recipes-devtools/bcm2835/bcm2835_1.52.bb | ||
| 373 | meta-raspberrypi/recipes-devtools/pi-blaster | ||
| 374 | meta-raspberrypi/recipes-devtools/pi-blaster/files | ||
| 375 | meta-raspberrypi/recipes-devtools/pi-blaster/files/*.patch | ||
| 376 | meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster_git.bb | ||
| 377 | meta-raspberrypi/recipes-devtools/python | ||
| 378 | meta-raspberrypi/recipes-devtools/python/python-rtimu | ||
| 379 | meta-raspberrypi/recipes-devtools/python/python-rtimu/*.patch | ||
| 380 | meta-raspberrypi/recipes-devtools/python/python-rtimu_git.bb | ||
| 381 | meta-raspberrypi/recipes-devtools/python/python-sense-hat_2.2.0.bb | ||
| 382 | meta-raspberrypi/recipes-devtools/python/rpi-gpio | ||
| 383 | meta-raspberrypi/recipes-devtools/python/rpi-gpio/*.patch | ||
| 384 | meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb | ||
| 385 | meta-raspberrypi/recipes-devtools/python/rpio | ||
| 386 | meta-raspberrypi/recipes-devtools/python/rpio/*.patch | ||
| 387 | meta-raspberrypi/recipes-devtools/python/rpio_0.10.0.bb | ||
| 388 | meta-raspberrypi/recipes-devtools/wiringPi | ||
| 389 | meta-raspberrypi/recipes-devtools/wiringPi/files | ||
| 390 | meta-raspberrypi/recipes-devtools/wiringPi/files/*.patch | ||
| 391 | meta-raspberrypi/recipes-devtools/wiringPi/wiringpi_git.bb | ||
| 392 | meta-raspberrypi/recipes-graphics | ||
| 393 | meta-raspberrypi/recipes-graphics/eglinfo | ||
| 394 | meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-fb_%.bbappend | ||
| 395 | meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-x11_%.bbappend | ||
| 396 | meta-raspberrypi/recipes-graphics/mesa | ||
| 397 | meta-raspberrypi/recipes-graphics/mesa/mesa-gl_%.bbappend | ||
| 398 | meta-raspberrypi/recipes-graphics/mesa/mesa_%.bbappend | ||
| 399 | meta-raspberrypi/recipes-graphics/userland | ||
| 400 | meta-raspberrypi/recipes-graphics/userland/userland | ||
| 401 | meta-raspberrypi/recipes-graphics/userland/userland/*.patch | ||
| 402 | meta-raspberrypi/recipes-graphics/userland/userland_git.bb | ||
| 403 | meta-raspberrypi/recipes-graphics/vc-graphics | ||
| 404 | meta-raspberrypi/recipes-graphics/vc-graphics/files | ||
| 405 | meta-raspberrypi/recipes-graphics/vc-graphics/files/egl.pc | ||
| 406 | meta-raspberrypi/recipes-graphics/vc-graphics/files/vchiq.sh | ||
| 407 | meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics-hardfp.bb | ||
| 408 | meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.bb | ||
| 409 | meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.inc | ||
| 410 | meta-raspberrypi/recipes-graphics/wayland | ||
| 411 | meta-raspberrypi/recipes-graphics/wayland/weston_%.bbappend | ||
| 412 | meta-raspberrypi/recipes-graphics/xorg-xserver | ||
| 413 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config | ||
| 414 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi | ||
| 415 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf | ||
| 416 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d | ||
| 417 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf | ||
| 418 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/98-pitft.conf | ||
| 419 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/99-calibration.conf | ||
| 420 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend | ||
| 421 | meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend | ||
| 422 | meta-raspberrypi/recipes-kernel | ||
| 423 | meta-raspberrypi/recipes-kernel/linux-firmware | ||
| 424 | meta-raspberrypi/recipes-kernel/linux-firmware/files | ||
| 425 | meta-raspberrypi/recipes-kernel/linux-firmware/files/brcmfmac43430-sdio.bin | ||
| 426 | meta-raspberrypi/recipes-kernel/linux-firmware/files/brcfmac43430-sdio.txt | ||
| 427 | meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend | ||
| 428 | meta-raspberrypi/recipes-kernel/linux | ||
| 429 | meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-dev.bb | ||
| 430 | meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc | ||
| 431 | meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.14.bb | ||
| 432 | meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb | ||
| 433 | meta-raspberrypi/recipes-multimedia | ||
| 434 | meta-raspberrypi/recipes-multimedia/gstreamer | ||
| 435 | meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx | ||
| 436 | meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx/*.patch | ||
| 437 | meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_%.bbappend | ||
| 438 | meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend | ||
| 439 | meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.12 | ||
| 440 | meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx-1.12/*.patch | ||
| 441 | meta-raspberrypi/recipes-multimedia/omxplayer | ||
| 442 | meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer | ||
| 443 | meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer/*.patch | ||
| 444 | meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb | ||
| 445 | meta-raspberrypi/recipes-multimedia/x264 | ||
| 446 | meta-raspberrypi/recipes-multimedia/x264/x264_git.bbappend | ||
| 447 | meta-raspberrypi/wic meta-raspberrypi/wic/sdimage-raspberrypi.wks | ||
| 448 | |||
| 449 | The following sections describe each part of the proposed BSP format. | ||
| 450 | |||
| 451 | License Files | ||
| 452 | ------------- | ||
| 453 | |||
| 454 | You can find these files in the BSP Layer at: :: | ||
| 455 | |||
| 456 | meta-bsp_root_name/bsp_license_file | ||
| 457 | |||
| 458 | These optional files satisfy licensing requirements for the BSP. The | ||
| 459 | type or types of files here can vary depending on the licensing | ||
| 460 | requirements. For example, in the Raspberry Pi BSP, all licensing | ||
| 461 | requirements are handled with the ``COPYING.MIT`` file. | ||
| 462 | |||
| 463 | Licensing files can be MIT, BSD, GPLv*, and so forth. These files are | ||
| 464 | recommended for the BSP but are optional and totally up to the BSP | ||
| 465 | developer. For information on how to maintain license compliance, see | ||
| 466 | the ":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`" | ||
| 467 | section in the Yocto Project Development Tasks Manual. | ||
| 468 | |||
| 469 | README File | ||
| 470 | ----------- | ||
| 471 | |||
| 472 | You can find this file in the BSP Layer at: :: | ||
| 473 | |||
| 474 | meta-bsp_root_name/README | ||
| 475 | |||
| 476 | This file provides information on how to boot the live images that are | ||
| 477 | optionally included in the ``binary/`` directory. The ``README`` file | ||
| 478 | also provides information needed for building the image. | ||
| 479 | |||
| 480 | At a minimum, the ``README`` file must contain a list of dependencies, | ||
| 481 | such as the names of any other layers on which the BSP depends and the | ||
| 482 | name of the BSP maintainer with his or her contact information. | ||
| 483 | |||
| 484 | README.sources File | ||
| 485 | ------------------- | ||
| 486 | |||
| 487 | You can find this file in the BSP Layer at: :: | ||
| 488 | |||
| 489 | meta-bsp_root_name/README.sources | ||
| 490 | |||
| 491 | This file provides information on where to locate the BSP source files | ||
| 492 | used to build the images (if any) that reside in | ||
| 493 | ``meta-bsp_root_name/binary``. Images in the ``binary`` would be images | ||
| 494 | released with the BSP. The information in the ``README.sources`` file | ||
| 495 | also helps you find the :term:`Metadata` | ||
| 496 | used to generate the images that ship with the BSP. | ||
| 497 | |||
| 498 | .. note:: | ||
| 499 | |||
| 500 | If the BSP's ``binary`` directory is missing or the directory has no images, an | ||
| 501 | existing ``README.sources`` file is meaningless and usually does not exist. | ||
| 502 | |||
| 503 | Pre-built User Binaries | ||
| 504 | ----------------------- | ||
| 505 | |||
| 506 | You can find these files in the BSP Layer at: :: | ||
| 507 | |||
| 508 | meta-bsp_root_name/binary/bootable_images | ||
| 509 | |||
| 510 | This optional area contains useful pre-built kernels and user-space | ||
| 511 | filesystem images released with the BSP that are appropriate to the | ||
| 512 | target system. This directory typically contains graphical (e.g. Sato) | ||
| 513 | and minimal live images when the BSP tarball has been created and made | ||
| 514 | available in the :yocto_home:`Yocto Project <>` website. You can | ||
| 515 | use these kernels and images to get a system running and quickly get | ||
| 516 | started on development tasks. | ||
| 517 | |||
| 518 | The exact types of binaries present are highly hardware-dependent. The | ||
| 519 | :ref:`README <bsp-guide/bsp:readme file>` file should be present in the | ||
| 520 | BSP Layer and it explains how to use the images with the target | ||
| 521 | hardware. Additionally, the | ||
| 522 | :ref:`README.sources <bsp-guide/bsp:readme.sources file>` file should be | ||
| 523 | present to locate the sources used to build the images and provide | ||
| 524 | information on the Metadata. | ||
| 525 | |||
| 526 | Layer Configuration File | ||
| 527 | ------------------------ | ||
| 528 | |||
| 529 | You can find this file in the BSP Layer at: :: | ||
| 530 | |||
| 531 | meta-bsp_root_name/conf/layer.conf | ||
| 532 | |||
| 533 | The ``conf/layer.conf`` file identifies the file structure as a layer, | ||
| 534 | identifies the contents of the layer, and contains information about how | ||
| 535 | the build system should use it. Generally, a standard boilerplate file | ||
| 536 | such as the following works. In the following example, you would replace | ||
| 537 | "bsp" with the actual name of the BSP (i.e. "bsp_root_name" from the example | ||
| 538 | template). :: | ||
| 539 | |||
| 540 | # We have a conf and classes directory, add to BBPATH | ||
| 541 | BBPATH .= ":${LAYERDIR}" | ||
| 542 | |||
| 543 | # We have a recipes directory containing .bb and .bbappend files, add to BBFILES | ||
| 544 | BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ | ||
| 545 | ${LAYERDIR}/recipes-*/*/*.bbappend" | ||
| 546 | |||
| 547 | BBFILE_COLLECTIONS += "bsp" | ||
| 548 | BBFILE_PATTERN_bsp = "^${LAYERDIR}/" | ||
| 549 | BBFILE_PRIORITY_bsp = "6" | ||
| 550 | LAYERDEPENDS_bsp = "intel" | ||
| 551 | |||
| 552 | To illustrate the string substitutions, here are the corresponding | ||
| 553 | statements from the Raspberry Pi ``conf/layer.conf`` file: :: | ||
| 554 | |||
| 555 | # We have a conf and classes directory, append to BBPATH | ||
| 556 | BBPATH .= ":${LAYERDIR}" | ||
| 557 | |||
| 558 | # We have a recipes directory containing .bb and .bbappend files, add to BBFILES | ||
| 559 | BBFILES += "${LAYERDIR}/recipes*/*/*.bb \ | ||
| 560 | ${LAYERDIR}/recipes*/*/*.bbappend" | ||
| 561 | |||
| 562 | BBFILE_COLLECTIONS += "raspberrypi" | ||
| 563 | BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/" | ||
| 564 | BBFILE_PRIORITY_raspberrypi = "9" | ||
| 565 | |||
| 566 | # Additional license directories. | ||
| 567 | LICENSE_PATH += "${LAYERDIR}/files/custom-licenses" | ||
| 568 | . | ||
| 569 | . | ||
| 570 | . | ||
| 571 | |||
| 572 | This file simply makes :term:`BitBake` aware of the recipes and configuration | ||
| 573 | directories. The file must exist so that the OpenEmbedded build system can | ||
| 574 | recognize the BSP. | ||
| 575 | |||
| 576 | Hardware Configuration Options | ||
| 577 | ------------------------------ | ||
| 578 | |||
| 579 | You can find these files in the BSP Layer at: :: | ||
| 580 | |||
| 581 | meta-bsp_root_name/conf/machine/*.conf | ||
| 582 | |||
| 583 | The machine files bind together all the information contained elsewhere | ||
| 584 | in the BSP into a format that the build system can understand. Each BSP | ||
| 585 | Layer requires at least one machine file. If the BSP supports multiple | ||
| 586 | machines, multiple machine configuration files can exist. These | ||
| 587 | filenames correspond to the values to which users have set the | ||
| 588 | :term:`MACHINE` variable. | ||
| 589 | |||
| 590 | These files define things such as the kernel package to use | ||
| 591 | (:term:`PREFERRED_PROVIDER` of | ||
| 592 | :ref:`virtual/kernel <dev-manual/common-tasks:using virtual providers>`), | ||
| 593 | the hardware drivers to include in different types of images, any | ||
| 594 | special software components that are needed, any bootloader information, | ||
| 595 | and also any special image format requirements. | ||
| 596 | |||
| 597 | This configuration file could also include a hardware "tuning" file that | ||
| 598 | is commonly used to define the package architecture and specify | ||
| 599 | optimization flags, which are carefully chosen to give best performance | ||
| 600 | on a given processor. | ||
| 601 | |||
| 602 | Tuning files are found in the ``meta/conf/machine/include`` directory | ||
| 603 | within the :term:`Source Directory`. | ||
| 604 | For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``, | ||
| 605 | ``tune-1586-nlp.inc``, and so forth) reside in the | ||
| 606 | ``poky/meta/conf/machine/include`` directory. | ||
| 607 | |||
| 608 | To use an include file, you simply include them in the machine | ||
| 609 | configuration file. For example, the Raspberry Pi BSP | ||
| 610 | ``raspberrypi3.conf`` contains the following statement: :: | ||
| 611 | |||
| 612 | include conf/machine/include/rpi-base.inc | ||
| 613 | |||
| 614 | Miscellaneous BSP-Specific Recipe Files | ||
| 615 | --------------------------------------- | ||
| 616 | |||
| 617 | You can find these files in the BSP Layer at: :: | ||
| 618 | |||
| 619 | meta-bsp_root_name/recipes-bsp/* | ||
| 620 | |||
| 621 | This optional directory contains miscellaneous recipe files for the BSP. | ||
| 622 | Most notably would be the formfactor files. For example, in the | ||
| 623 | Raspberry Pi BSP, there is the ``formfactor_0.0.bbappend`` file, which | ||
| 624 | is an append file used to augment the recipe that starts the build. | ||
| 625 | Furthermore, there are machine-specific settings used during the build | ||
| 626 | that are defined by the ``machconfig`` file further down in the | ||
| 627 | directory. Here is the ``machconfig`` file for the Raspberry Pi BSP: :: | ||
| 628 | |||
| 629 | HAVE_TOUCHSCREEN=0 | ||
| 630 | HAVE_KEYBOARD=1 | ||
| 631 | |||
| 632 | DISPLAY_CAN_ROTATE=0 | ||
| 633 | DISPLAY_ORIENTATION=0 | ||
| 634 | DISPLAY_DPI=133 | ||
| 635 | |||
| 636 | .. note:: | ||
| 637 | |||
| 638 | If a BSP does not have a formfactor entry, defaults are established | ||
| 639 | according to the formfactor configuration file that is installed by | ||
| 640 | the main formfactor recipe | ||
| 641 | ``meta/recipes-bsp/formfactor/formfactor_0.0.bb``, which is found in | ||
| 642 | the :term:`Source Directory`. | ||
| 643 | |||
| 644 | Display Support Files | ||
| 645 | --------------------- | ||
| 646 | |||
| 647 | You can find these files in the BSP Layer at: :: | ||
| 648 | |||
| 649 | meta-bsp_root_name/recipes-graphics/* | ||
| 650 | |||
| 651 | This optional directory contains recipes for the BSP if it has special | ||
| 652 | requirements for graphics support. All files that are needed for the BSP | ||
| 653 | to support a display are kept here. | ||
| 654 | |||
| 655 | Linux Kernel Configuration | ||
| 656 | -------------------------- | ||
| 657 | |||
| 658 | You can find these files in the BSP Layer at: :: | ||
| 659 | |||
| 660 | meta-bsp_root_name/recipes-kernel/linux/linux*.bbappend | ||
| 661 | meta-bsp_root_name/recipes-kernel/linux/*.bb | ||
| 662 | |||
| 663 | Append files (``*.bbappend``) modify the main kernel recipe being used | ||
| 664 | to build the image. The ``*.bb`` files would be a developer-supplied | ||
| 665 | kernel recipe. This area of the BSP hierarchy can contain both these | ||
| 666 | types of files although, in practice, it is likely that you would have | ||
| 667 | one or the other. | ||
| 668 | |||
| 669 | For your BSP, you typically want to use an existing Yocto Project kernel | ||
| 670 | recipe found in the :term:`Source Directory` | ||
| 671 | at | ||
| 672 | ``meta/recipes-kernel/linux``. You can append machine-specific changes | ||
| 673 | to the kernel recipe by using a similarly named append file, which is | ||
| 674 | located in the BSP Layer for your target device (e.g. the | ||
| 675 | ``meta-bsp_root_name/recipes-kernel/linux`` directory). | ||
| 676 | |||
| 677 | Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the | ||
| 678 | kernel. In other words, you have selected the kernel in your | ||
| 679 | ``"bsp_root_name".conf`` file by adding | ||
| 680 | :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION` | ||
| 681 | statements as follows: :: | ||
| 682 | |||
| 683 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" | ||
| 684 | PREFERRED_VERSION_linux-yocto ?= "4.4%" | ||
| 685 | |||
| 686 | .. note:: | ||
| 687 | |||
| 688 | When the preferred provider is assumed by default, the ``PREFERRED_PROVIDER`` | ||
| 689 | statement does not appear in the ``"bsp_root_name".conf`` file. | ||
| 690 | |||
| 691 | You would use the ``linux-yocto_4.4.bbappend`` file to append specific | ||
| 692 | BSP settings to the kernel, thus configuring the kernel for your | ||
| 693 | particular BSP. | ||
| 694 | |||
| 695 | You can find more information on what your append file should contain in | ||
| 696 | the ":ref:`kernel-dev/common:creating the append file`" section | ||
| 697 | in the Yocto Project Linux Kernel Development Manual. | ||
| 698 | |||
| 699 | An alternate scenario is when you create your own kernel recipe for the | ||
| 700 | BSP. A good example of this is the Raspberry Pi BSP. If you examine the | ||
| 701 | ``recipes-kernel/linux`` directory you see the following: :: | ||
| 702 | |||
| 703 | linux-raspberrypi-dev.bb | ||
| 704 | linux-raspberrypi.inc | ||
| 705 | linux-raspberrypi_4.14.bb | ||
| 706 | linux-raspberrypi_4.9.bb | ||
| 707 | |||
| 708 | The directory contains three kernel recipes and a common include file. | ||
| 709 | |||
| 710 | Developing a Board Support Package (BSP) | ||
| 711 | ======================================== | ||
| 712 | |||
| 713 | This section describes the high-level procedure you can follow to create | ||
| 714 | a BSP. Although not required for BSP creation, the ``meta-intel`` | ||
| 715 | repository, which contains many BSPs supported by the Yocto Project, is | ||
| 716 | part of the example. | ||
| 717 | |||
| 718 | For an example that shows how to create a new layer using the tools, see | ||
| 719 | the ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`" | ||
| 720 | section. | ||
| 721 | |||
| 722 | The following illustration and list summarize the BSP creation general | ||
| 723 | workflow. | ||
| 724 | |||
| 725 | .. image:: figures/bsp-dev-flow.png | ||
| 726 | :align: center | ||
| 727 | |||
| 728 | #. *Set up Your Host Development System to Support Development Using the | ||
| 729 | Yocto Project*: See the ":ref:`dev-manual/start:preparing the build host`" | ||
| 730 | section in the Yocto Project Development Tasks Manual for options on how to | ||
| 731 | get a system ready to use the Yocto Project. | ||
| 732 | |||
| 733 | #. *Establish the meta-intel Repository on Your System:* Having | ||
| 734 | local copies of these supported BSP layers on your system gives you | ||
| 735 | access to layers you might be able to leverage when creating your | ||
| 736 | BSP. For information on how to get these files, see the | ||
| 737 | ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`" | ||
| 738 | section. | ||
| 739 | |||
| 740 | #. *Create Your Own BSP Layer Using the bitbake-layers Script:* | ||
| 741 | Layers are ideal for isolating and storing work for a given piece of | ||
| 742 | hardware. A layer is really just a location or area in which you | ||
| 743 | place the recipes and configurations for your BSP. In fact, a BSP is, | ||
| 744 | in itself, a special type of layer. The simplest way to create a new | ||
| 745 | BSP layer that is compliant with the Yocto Project is to use the | ||
| 746 | ``bitbake-layers`` script. For information about that script, see the | ||
| 747 | ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`" | ||
| 748 | section. | ||
| 749 | |||
| 750 | Another example that illustrates a layer is an application. Suppose | ||
| 751 | you are creating an application that has library or other | ||
| 752 | dependencies in order for it to compile and run. The layer, in this | ||
| 753 | case, would be where all the recipes that define those dependencies | ||
| 754 | are kept. The key point for a layer is that it is an isolated area | ||
| 755 | that contains all the relevant information for the project that the | ||
| 756 | OpenEmbedded build system knows about. For more information on | ||
| 757 | layers, see the ":ref:`overview-manual/yp-intro:the yocto project layer model`" | ||
| 758 | section in the Yocto Project Overview and Concepts Manual. You can also | ||
| 759 | reference the ":ref:`dev-manual/common-tasks:understanding and creating layers`" | ||
| 760 | section in the Yocto Project Development Tasks Manual. For more | ||
| 761 | information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`" | ||
| 762 | section. | ||
| 763 | |||
| 764 | .. note:: | ||
| 765 | |||
| 766 | - Four hardware reference BSPs exist that are part of the Yocto | ||
| 767 | Project release and are located in the ``poky/meta-yocto-bsp`` | ||
| 768 | BSP layer: | ||
| 769 | |||
| 770 | - Texas Instruments Beaglebone (``beaglebone-yocto``) | ||
| 771 | |||
| 772 | - Ubiquiti Networks EdgeRouter Lite (``edgerouter``) | ||
| 773 | |||
| 774 | - Two general IA platforms (``genericx86`` and ``genericx86-64``) | ||
| 775 | |||
| 776 | - Three core Intel BSPs exist as part of the Yocto Project | ||
| 777 | release in the ``meta-intel`` layer: | ||
| 778 | |||
| 779 | - ``intel-core2-32``, which is a BSP optimized for the Core2 | ||
| 780 | family of CPUs as well as all CPUs prior to the Silvermont | ||
| 781 | core. | ||
| 782 | |||
| 783 | - ``intel-corei7-64``, which is a BSP optimized for Nehalem | ||
| 784 | and later Core and Xeon CPUs as well as Silvermont and later | ||
| 785 | Atom CPUs, such as the Baytrail SoCs. | ||
| 786 | |||
| 787 | - ``intel-quark``, which is a BSP optimized for the Intel | ||
| 788 | Galileo gen1 & gen2 development boards. | ||
| 789 | |||
| 790 | When you set up a layer for a new BSP, you should follow a standard | ||
| 791 | layout. This layout is described in the ":ref:`bsp-guide/bsp:example filesystem layout`" | ||
| 792 | section. In the standard layout, notice | ||
| 793 | the suggested structure for recipes and configuration information. | ||
| 794 | You can see the standard layout for a BSP by examining any supported | ||
| 795 | BSP found in the ``meta-intel`` layer inside the Source Directory. | ||
| 796 | |||
| 797 | #. *Make Configuration Changes to Your New BSP Layer:* The standard BSP | ||
| 798 | layer structure organizes the files you need to edit in ``conf`` and | ||
| 799 | several ``recipes-*`` directories within the BSP layer. Configuration | ||
| 800 | changes identify where your new layer is on the local system and | ||
| 801 | identifies the kernel you are going to use. When you run the | ||
| 802 | ``bitbake-layers`` script, you are able to interactively configure | ||
| 803 | many things for the BSP (e.g. keyboard, touchscreen, and so forth). | ||
| 804 | |||
| 805 | #. *Make Recipe Changes to Your New BSP Layer:* Recipe changes include | ||
| 806 | altering recipes (``*.bb`` files), removing recipes you do not use, | ||
| 807 | and adding new recipes or append files (``.bbappend``) that support | ||
| 808 | your hardware. | ||
| 809 | |||
| 810 | #. *Prepare for the Build:* Once you have made all the changes to your | ||
| 811 | BSP layer, there remains a few things you need to do for the | ||
| 812 | OpenEmbedded build system in order for it to create your image. You | ||
| 813 | need to get the build environment ready by sourcing an environment | ||
| 814 | setup script (i.e. ``oe-init-build-env``) and you need to be sure two | ||
| 815 | key configuration files are configured appropriately: the | ||
| 816 | ``conf/local.conf`` and the ``conf/bblayers.conf`` file. You must | ||
| 817 | make the OpenEmbedded build system aware of your new layer. See the | ||
| 818 | ":ref:`dev-manual/common-tasks:enabling your layer`" | ||
| 819 | section in the Yocto Project Development Tasks Manual for information | ||
| 820 | on how to let the build system know about your new layer. | ||
| 821 | |||
| 822 | #. *Build the Image:* The OpenEmbedded build system uses the BitBake | ||
| 823 | tool to build images based on the type of image you want to create. | ||
| 824 | You can find more information about BitBake in the | ||
| 825 | :doc:`BitBake User Manual <bitbake:index>`. | ||
| 826 | |||
| 827 | The build process supports several types of images to satisfy | ||
| 828 | different needs. See the | ||
| 829 | ":ref:`ref-manual/images:Images`" chapter in the Yocto | ||
| 830 | Project Reference Manual for information on supported images. | ||
| 831 | |||
| 832 | Requirements and Recommendations for Released BSPs | ||
| 833 | ================================================== | ||
| 834 | |||
| 835 | Certain requirements exist for a released BSP to be considered compliant | ||
| 836 | with the Yocto Project. Additionally, recommendations also exist. This | ||
| 837 | section describes the requirements and recommendations for released | ||
| 838 | BSPs. | ||
| 839 | |||
| 840 | Released BSP Requirements | ||
| 841 | ------------------------- | ||
| 842 | |||
| 843 | Before looking at BSP requirements, you should consider the following: | ||
| 844 | |||
| 845 | - The requirements here assume the BSP layer is a well-formed, "legal" | ||
| 846 | layer that can be added to the Yocto Project. For guidelines on | ||
| 847 | creating a layer that meets these base requirements, see the | ||
| 848 | ":ref:`bsp-guide/bsp:bsp layers`" section in this manual and the | ||
| 849 | ":ref:`dev-manual/common-tasks:understanding and creating layers`" | ||
| 850 | section in the Yocto Project Development Tasks Manual. | ||
| 851 | |||
| 852 | - The requirements in this section apply regardless of how you package | ||
| 853 | a BSP. You should consult the packaging and distribution guidelines | ||
| 854 | for your specific release process. For an example of packaging and | ||
| 855 | distribution requirements, see the ":yocto_wiki:`Third Party BSP Release | ||
| 856 | Process </Third_Party_BSP_Release_Process>`" | ||
| 857 | wiki page. | ||
| 858 | |||
| 859 | - The requirements for the BSP as it is made available to a developer | ||
| 860 | are completely independent of the released form of the BSP. For | ||
| 861 | example, the BSP Metadata can be contained within a Git repository | ||
| 862 | and could have a directory structure completely different from what | ||
| 863 | appears in the officially released BSP layer. | ||
| 864 | |||
| 865 | - It is not required that specific packages or package modifications | ||
| 866 | exist in the BSP layer, beyond the requirements for general | ||
| 867 | compliance with the Yocto Project. For example, no requirement exists | ||
| 868 | dictating that a specific kernel or kernel version be used in a given | ||
| 869 | BSP. | ||
| 870 | |||
| 871 | Following are the requirements for a released BSP that conform to the | ||
| 872 | Yocto Project: | ||
| 873 | |||
| 874 | - *Layer Name:* The BSP must have a layer name that follows the Yocto | ||
| 875 | Project standards. For information on BSP layer names, see the | ||
| 876 | ":ref:`bsp-guide/bsp:bsp layers`" section. | ||
| 877 | |||
| 878 | - *File System Layout:* When possible, use the same directory names in | ||
| 879 | your BSP layer as listed in the ``recipes.txt`` file, which is found | ||
| 880 | in ``poky/meta`` directory of the :term:`Source Directory` | ||
| 881 | or in the OpenEmbedded-Core Layer (``openembedded-core``) at | ||
| 882 | https://git.openembedded.org/openembedded-core/tree/meta. | ||
| 883 | |||
| 884 | You should place recipes (``*.bb`` files) and recipe modifications | ||
| 885 | (``*.bbappend`` files) into ``recipes-*`` subdirectories by | ||
| 886 | functional area as outlined in ``recipes.txt``. If you cannot find a | ||
| 887 | category in ``recipes.txt`` to fit a particular recipe, you can make | ||
| 888 | up your own ``recipes-*`` subdirectory. | ||
| 889 | |||
| 890 | Within any particular ``recipes-*`` category, the layout should match | ||
| 891 | what is found in the OpenEmbedded-Core Git repository | ||
| 892 | (``openembedded-core``) or the Source Directory (``poky``). In other | ||
| 893 | words, make sure you place related files in appropriately-related | ||
| 894 | ``recipes-*`` subdirectories specific to the recipe's function, or | ||
| 895 | within a subdirectory containing a set of closely-related recipes. | ||
| 896 | The recipes themselves should follow the general guidelines for | ||
| 897 | recipes used in the Yocto Project found in the ":oe_wiki:`OpenEmbedded | ||
| 898 | Style Guide </Styleguide>`". | ||
| 899 | |||
| 900 | - *License File:* You must include a license file in the | ||
| 901 | ``meta-bsp_root_name`` directory. This license covers the BSP | ||
| 902 | Metadata as a whole. You must specify which license to use since no | ||
| 903 | default license exists when one is not specified. See the | ||
| 904 | :yocto_git:`COPYING.MIT </meta-raspberrypi/tree/COPYING.MIT>` | ||
| 905 | file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer | ||
| 906 | as an example. | ||
| 907 | |||
| 908 | - *README File:* You must include a ``README`` file in the | ||
| 909 | ``meta-bsp_root_name`` directory. See the | ||
| 910 | :yocto_git:`README.md </meta-raspberrypi/tree/README.md>` | ||
| 911 | file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer | ||
| 912 | as an example. | ||
| 913 | |||
| 914 | At a minimum, the ``README`` file should contain the following: | ||
| 915 | |||
| 916 | - A brief description of the target hardware. | ||
| 917 | |||
| 918 | - A list of all the dependencies of the BSP. These dependencies are | ||
| 919 | typically a list of required layers needed to build the BSP. | ||
| 920 | However, the dependencies should also contain information | ||
| 921 | regarding any other dependencies the BSP might have. | ||
| 922 | |||
| 923 | - Any required special licensing information. For example, this | ||
| 924 | information includes information on special variables needed to | ||
| 925 | satisfy a EULA, or instructions on information needed to build or | ||
| 926 | distribute binaries built from the BSP Metadata. | ||
| 927 | |||
| 928 | - The name and contact information for the BSP layer maintainer. | ||
| 929 | This is the person to whom patches and questions should be sent. | ||
| 930 | For information on how to find the right person, see the | ||
| 931 | ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" | ||
| 932 | section in the Yocto Project Development Tasks Manual. | ||
| 933 | |||
| 934 | - Instructions on how to build the BSP using the BSP layer. | ||
| 935 | |||
| 936 | - Instructions on how to boot the BSP build from the BSP layer. | ||
| 937 | |||
| 938 | - Instructions on how to boot the binary images contained in the | ||
| 939 | ``binary`` directory, if present. | ||
| 940 | |||
| 941 | - Information on any known bugs or issues that users should know | ||
| 942 | about when either building or booting the BSP binaries. | ||
| 943 | |||
| 944 | - *README.sources File:* If your BSP contains binary images in the | ||
| 945 | ``binary`` directory, you must include a ``README.sources`` file in | ||
| 946 | the ``meta-bsp_root_name`` directory. This file specifies exactly | ||
| 947 | where you can find the sources used to generate the binary images. | ||
| 948 | |||
| 949 | - *Layer Configuration File:* You must include a ``conf/layer.conf`` | ||
| 950 | file in the ``meta-bsp_root_name`` directory. This file identifies | ||
| 951 | the ``meta-bsp_root_name`` BSP layer as a layer to the build | ||
| 952 | system. | ||
| 953 | |||
| 954 | - *Machine Configuration File:* You must include one or more | ||
| 955 | ``conf/machine/bsp_root_name.conf`` files in the | ||
| 956 | ``meta-bsp_root_name`` directory. These configuration files define | ||
| 957 | machine targets that can be built using the BSP layer. Multiple | ||
| 958 | machine configuration files define variations of machine | ||
| 959 | configurations that the BSP supports. If a BSP supports multiple | ||
| 960 | machine variations, you need to adequately describe each variation in | ||
| 961 | the BSP ``README`` file. Do not use multiple machine configuration | ||
| 962 | files to describe disparate hardware. If you do have very different | ||
| 963 | targets, you should create separate BSP layers for each target. | ||
| 964 | |||
| 965 | .. note:: | ||
| 966 | |||
| 967 | It is completely possible for a developer to structure the working | ||
| 968 | repository as a conglomeration of unrelated BSP files, and to possibly | ||
| 969 | generate BSPs targeted for release from that directory using scripts or | ||
| 970 | some other mechanism (e.g. ``meta-yocto-bsp`` layer). Such considerations | ||
| 971 | are outside the scope of this document. | ||
| 972 | |||
| 973 | Released BSP Recommendations | ||
| 974 | ---------------------------- | ||
| 975 | |||
| 976 | Following are recommendations for released BSPs that conform to the | ||
| 977 | Yocto Project: | ||
| 978 | |||
| 979 | - *Bootable Images:* Released BSPs can contain one or more bootable | ||
| 980 | images. Including bootable images allows users to easily try out the | ||
| 981 | BSP using their own hardware. | ||
| 982 | |||
| 983 | In some cases, it might not be convenient to include a bootable | ||
| 984 | image. If so, you might want to make two versions of the BSP | ||
| 985 | available: one that contains binary images, and one that does not. | ||
| 986 | The version that does not contain bootable images avoids unnecessary | ||
| 987 | download times for users not interested in the images. | ||
| 988 | |||
| 989 | If you need to distribute a BSP and include bootable images or build | ||
| 990 | kernel and filesystems meant to allow users to boot the BSP for | ||
| 991 | evaluation purposes, you should put the images and artifacts within a | ||
| 992 | ``binary/`` subdirectory located in the ``meta-bsp_root_name`` | ||
| 993 | directory. | ||
| 994 | |||
| 995 | .. note:: | ||
| 996 | |||
| 997 | If you do include a bootable image as part of the BSP and the | ||
| 998 | image was built by software covered by the GPL or other open | ||
| 999 | source licenses, it is your responsibility to understand and meet | ||
| 1000 | all licensing requirements, which could include distribution of | ||
| 1001 | source files. | ||
| 1002 | |||
| 1003 | - *Use a Yocto Linux Kernel:* Kernel recipes in the BSP should be based | ||
| 1004 | on a Yocto Linux kernel. Basing your recipes on these kernels reduces | ||
| 1005 | the costs for maintaining the BSP and increases its scalability. See | ||
| 1006 | the ``Yocto Linux Kernel`` category in the | ||
| 1007 | :yocto_git:`Source Repositories <>` for these kernels. | ||
| 1008 | |||
| 1009 | Customizing a Recipe for a BSP | ||
| 1010 | ============================== | ||
| 1011 | |||
| 1012 | If you plan on customizing a recipe for a particular BSP, you need to do | ||
| 1013 | the following: | ||
| 1014 | |||
| 1015 | - Create a ``*.bbappend`` file for the modified recipe. For information on using | ||
| 1016 | append files, see the ":ref:`dev-manual/common-tasks:using | ||
| 1017 | .bbappend files in your layer`" section in the Yocto Project Development | ||
| 1018 | Tasks Manual. | ||
| 1019 | |||
| 1020 | - Ensure your directory structure in the BSP layer that supports your | ||
| 1021 | machine is such that the OpenEmbedded build system can find it. See | ||
| 1022 | the example later in this section for more information. | ||
| 1023 | |||
| 1024 | - Put the append file in a directory whose name matches the machine's | ||
| 1025 | name and is located in an appropriate sub-directory inside the BSP | ||
| 1026 | layer (i.e. ``recipes-bsp``, ``recipes-graphics``, ``recipes-core``, | ||
| 1027 | and so forth). | ||
| 1028 | |||
| 1029 | - Place the BSP-specific files in the proper directory inside the BSP | ||
| 1030 | layer. How expansive the layer is affects where you must place these | ||
| 1031 | files. For example, if your layer supports several different machine | ||
| 1032 | types, you need to be sure your layer's directory structure includes | ||
| 1033 | hierarchy that separates the files according to machine. If your | ||
| 1034 | layer does not support multiple machines, the layer would not have | ||
| 1035 | that additional hierarchy and the files would obviously not be able | ||
| 1036 | to reside in a machine-specific directory. | ||
| 1037 | |||
| 1038 | Following is a specific example to help you better understand the | ||
| 1039 | process. This example customizes customizes a recipe by adding a | ||
| 1040 | BSP-specific configuration file named ``interfaces`` to the | ||
| 1041 | ``init-ifupdown_1.0.bb`` recipe for machine "xyz" where the BSP layer | ||
| 1042 | also supports several other machines: | ||
| 1043 | |||
| 1044 | #. Edit the ``init-ifupdown_1.0.bbappend`` file so that it contains the | ||
| 1045 | following: :: | ||
| 1046 | |||
| 1047 | FILESEXTRAPATHS_prepend := "${THISDIR}/files:" | ||
| 1048 | |||
| 1049 | The append file needs to be in the ``meta-xyz/recipes-core/init-ifupdown`` | ||
| 1050 | directory. | ||
| 1051 | |||
| 1052 | #. Create and place the new ``interfaces`` configuration file in the | ||
| 1053 | BSP's layer here: :: | ||
| 1054 | |||
| 1055 | meta-xyz/recipes-core/init-ifupdown/files/xyz-machine-one/interfaces | ||
| 1056 | |||
| 1057 | .. note:: | ||
| 1058 | |||
| 1059 | If the ``meta-xyz`` layer did not support multiple machines, you would place | ||
| 1060 | the interfaces configuration file in the layer here: :: | ||
| 1061 | |||
| 1062 | meta-xyz/recipes-core/init-ifupdown/files/interfaces | ||
| 1063 | |||
| 1064 | The :term:`FILESEXTRAPATHS` variable in the append files extends the search | ||
| 1065 | path the build system uses to find files during the build. Consequently, for | ||
| 1066 | this example you need to have the ``files`` directory in the same location as | ||
| 1067 | your append file. | ||
| 1068 | |||
| 1069 | BSP Licensing Considerations | ||
| 1070 | ============================ | ||
| 1071 | |||
| 1072 | In some cases, a BSP contains separately-licensed Intellectual Property | ||
| 1073 | (IP) for a component or components. For these cases, you are required to | ||
| 1074 | accept the terms of a commercial or other type of license that requires | ||
| 1075 | some kind of explicit End User License Agreement (EULA). Once you accept | ||
| 1076 | the license, the OpenEmbedded build system can then build and include | ||
| 1077 | the corresponding component in the final BSP image. If the BSP is | ||
| 1078 | available as a pre-built image, you can download the image after | ||
| 1079 | agreeing to the license or EULA. | ||
| 1080 | |||
| 1081 | You could find that some separately-licensed components that are | ||
| 1082 | essential for normal operation of the system might not have an | ||
| 1083 | unencumbered (or free) substitute. Without these essential components, | ||
| 1084 | the system would be non-functional. Then again, you might find that | ||
| 1085 | other licensed components that are simply 'good-to-have' or purely | ||
| 1086 | elective do have an unencumbered, free replacement component that you | ||
| 1087 | can use rather than agreeing to the separately-licensed component. Even | ||
| 1088 | for components essential to the system, you might find an unencumbered | ||
| 1089 | component that is not identical but will work as a less-capable version | ||
| 1090 | of the licensed version in the BSP recipe. | ||
| 1091 | |||
| 1092 | For cases where you can substitute a free component and still maintain | ||
| 1093 | the system's functionality, the "DOWNLOADS" selection from the | ||
| 1094 | "SOFTWARE" tab on the :yocto_home:`Yocto Project Website <>` makes | ||
| 1095 | available de-featured BSPs that are completely free of any IP | ||
| 1096 | encumbrances. For these cases, you can use the substitution directly and | ||
| 1097 | without any further licensing requirements. If present, these fully | ||
| 1098 | de-featured BSPs are named appropriately different as compared to the | ||
| 1099 | names of their respective encumbered BSPs. If available, these | ||
| 1100 | substitutions are your simplest and most preferred options. Obviously, | ||
| 1101 | use of these substitutions assumes the resulting functionality meets | ||
| 1102 | system requirements. | ||
| 1103 | |||
| 1104 | .. note:: | ||
| 1105 | |||
| 1106 | If however, a non-encumbered version is unavailable or it provides | ||
| 1107 | unsuitable functionality or quality, you can use an encumbered | ||
| 1108 | version. | ||
| 1109 | |||
| 1110 | A couple different methods exist within the OpenEmbedded build system to | ||
| 1111 | satisfy the licensing requirements for an encumbered BSP. The following | ||
| 1112 | list describes them in order of preference: | ||
| 1113 | |||
| 1114 | #. *Use the LICENSE_FLAGS Variable to Define the Recipes that Have Commercial or | ||
| 1115 | Other Types of Specially-Licensed Packages:* For each of those recipes, you can | ||
| 1116 | specify a matching license string in a ``local.conf`` variable named | ||
| 1117 | :term:`LICENSE_FLAGS_WHITELIST`. | ||
| 1118 | Specifying the matching license string signifies that you agree to | ||
| 1119 | the license. Thus, the build system can build the corresponding | ||
| 1120 | recipe and include the component in the image. See the | ||
| 1121 | ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`" | ||
| 1122 | section in the Yocto Project Development Tasks Manual for details on | ||
| 1123 | how to use these variables. | ||
| 1124 | |||
| 1125 | If you build as you normally would, without specifying any recipes in | ||
| 1126 | the ``LICENSE_FLAGS_WHITELIST``, the build stops and provides you | ||
| 1127 | with the list of recipes that you have tried to include in the image | ||
| 1128 | that need entries in the ``LICENSE_FLAGS_WHITELIST``. Once you enter | ||
| 1129 | the appropriate license flags into the whitelist, restart the build | ||
| 1130 | to continue where it left off. During the build, the prompt will not | ||
| 1131 | appear again since you have satisfied the requirement. | ||
| 1132 | |||
| 1133 | Once the appropriate license flags are on the white list in the | ||
| 1134 | ``LICENSE_FLAGS_WHITELIST`` variable, you can build the encumbered | ||
| 1135 | image with no change at all to the normal build process. | ||
| 1136 | |||
| 1137 | #. *Get a Pre-Built Version of the BSP:* You can get this type of BSP by | ||
| 1138 | selecting the "DOWNLOADS" item from the "SOFTWARE" tab on the | ||
| 1139 | :yocto_home:`Yocto Project website <>`. You can download BSP tarballs | ||
| 1140 | that contain proprietary components after agreeing to the licensing | ||
| 1141 | requirements of each of the individually encumbered packages as part | ||
| 1142 | of the download process. Obtaining the BSP this way allows you to | ||
| 1143 | access an encumbered image immediately after agreeing to the | ||
| 1144 | click-through license agreements presented by the website. If you | ||
| 1145 | want to build the image yourself using the recipes contained within | ||
| 1146 | the BSP tarball, you will still need to create an appropriate | ||
| 1147 | ``LICENSE_FLAGS_WHITELIST`` to match the encumbered recipes in the | ||
| 1148 | BSP. | ||
| 1149 | |||
| 1150 | .. note:: | ||
| 1151 | |||
| 1152 | Pre-compiled images are bundled with a time-limited kernel that runs | ||
| 1153 | for a predetermined amount of time (10 days) before it forces the | ||
| 1154 | system to reboot. This limitation is meant to discourage direct | ||
| 1155 | redistribution of the image. You must eventually rebuild the image if | ||
| 1156 | you want to remove this restriction. | ||
| 1157 | |||
| 1158 | Creating a new BSP Layer Using the ``bitbake-layers`` Script | ||
| 1159 | ============================================================ | ||
| 1160 | |||
| 1161 | The ``bitbake-layers create-layer`` script automates creating a BSP | ||
| 1162 | layer. What makes a layer a "BSP layer" is the presence of at least one | ||
| 1163 | machine configuration file. Additionally, a BSP layer usually has a | ||
| 1164 | kernel recipe or an append file that leverages off an existing kernel | ||
| 1165 | recipe. The primary requirement, however, is the machine configuration. | ||
| 1166 | |||
| 1167 | Use these steps to create a BSP layer: | ||
| 1168 | |||
| 1169 | - *Create a General Layer:* Use the ``bitbake-layers`` script with the | ||
| 1170 | ``create-layer`` subcommand to create a new general layer. For | ||
| 1171 | instructions on how to create a general layer using the | ||
| 1172 | ``bitbake-layers`` script, see the | ||
| 1173 | ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`" | ||
| 1174 | section in the Yocto Project Development Tasks Manual. | ||
| 1175 | |||
| 1176 | - *Create a Layer Configuration File:* Every layer needs a layer | ||
| 1177 | configuration file. This configuration file establishes locations for | ||
| 1178 | the layer's recipes, priorities for the layer, and so forth. You can | ||
| 1179 | find examples of ``layer.conf`` files in the Yocto Project | ||
| 1180 | :yocto_git:`Source Repositories <>`. To get examples of what you need | ||
| 1181 | in your configuration file, locate a layer (e.g. "meta-ti") and | ||
| 1182 | examine the | ||
| 1183 | :yocto_git:`local.conf </meta-ti/tree/conf/layer.conf>` | ||
| 1184 | file. | ||
| 1185 | |||
| 1186 | - *Create a Machine Configuration File:* Create a | ||
| 1187 | ``conf/machine/bsp_root_name.conf`` file. See | ||
| 1188 | :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>` | ||
| 1189 | for sample ``bsp_root_name.conf`` files. Other samples such as | ||
| 1190 | :yocto_git:`meta-ti </meta-ti/tree/conf/machine>` | ||
| 1191 | and | ||
| 1192 | :yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>` | ||
| 1193 | exist from other vendors that have more specific machine and tuning | ||
| 1194 | examples. | ||
| 1195 | |||
| 1196 | - *Create a Kernel Recipe:* Create a kernel recipe in | ||
| 1197 | ``recipes-kernel/linux`` by either using a kernel append file or a | ||
| 1198 | new custom kernel recipe file (e.g. ``yocto-linux_4.12.bb``). The BSP | ||
| 1199 | layers mentioned in the previous step also contain different kernel | ||
| 1200 | examples. See the ":ref:`kernel-dev/common:modifying an existing recipe`" | ||
| 1201 | section in the Yocto Project Linux Kernel Development Manual for | ||
| 1202 | information on how to create a custom kernel. | ||
| 1203 | |||
| 1204 | The remainder of this section provides a description of the Yocto | ||
| 1205 | Project reference BSP for Beaglebone, which resides in the | ||
| 1206 | :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>` | ||
| 1207 | layer. | ||
| 1208 | |||
| 1209 | BSP Layer Configuration Example | ||
| 1210 | ------------------------------- | ||
| 1211 | |||
| 1212 | The layer's ``conf`` directory contains the ``layer.conf`` configuration | ||
| 1213 | file. In this example, the ``conf/layer.conf`` is the following: :: | ||
| 1214 | |||
| 1215 | # We have a conf and classes directory, add to BBPATH | ||
| 1216 | BBPATH .= ":${LAYERDIR}" | ||
| 1217 | |||
| 1218 | # We have a recipes directory containing .bb and .bbappend files, add to BBFILES | ||
| 1219 | BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ | ||
| 1220 | ${LAYERDIR}/recipes-*/*/*.bbappend" | ||
| 1221 | |||
| 1222 | BBFILE_COLLECTIONS += "yoctobsp" | ||
| 1223 | BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/" | ||
| 1224 | BBFILE_PRIORITY_yoctobsp = "5" | ||
| 1225 | LAYERVERSION_yoctobsp = "4" | ||
| 1226 | LAYERSERIES_COMPAT_yoctobsp = "&DISTRO_NAME_NO_CAP;" | ||
| 1227 | |||
| 1228 | The variables used in this file configure the layer. A good way to learn about layer | ||
| 1229 | configuration files is to examine various files for BSP from the | ||
| 1230 | :yocto_git:`Source Repositories <>`. | ||
| 1231 | |||
| 1232 | For a detailed description of this particular layer configuration file, | ||
| 1233 | see ":ref:`step 3 <dev-manual/common-tasks:creating your own layer>`" | ||
| 1234 | in the discussion that describes how to create layers in the Yocto | ||
| 1235 | Project Development Tasks Manual. | ||
| 1236 | |||
| 1237 | BSP Machine Configuration Example | ||
| 1238 | --------------------------------- | ||
| 1239 | |||
| 1240 | As mentioned earlier in this section, the existence of a machine | ||
| 1241 | configuration file is what makes a layer a BSP layer as compared to a | ||
| 1242 | general or kernel layer. | ||
| 1243 | |||
| 1244 | One or more machine configuration files exist in the | ||
| 1245 | ``bsp_layer/conf/machine/`` directory of the layer: :: | ||
| 1246 | |||
| 1247 | bsp_layer/conf/machine/machine1\.conf | ||
| 1248 | bsp_layer/conf/machine/machine2\.conf | ||
| 1249 | bsp_layer/conf/machine/machine3\.conf | ||
| 1250 | ... more ... | ||
| 1251 | |||
| 1252 | For example, the machine configuration file for the `BeagleBone and | ||
| 1253 | BeagleBone Black development boards <https://beagleboard.org/bone>`__ is | ||
| 1254 | located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named | ||
| 1255 | ``beaglebone-yocto.conf``: :: | ||
| 1256 | |||
| 1257 | #@TYPE: Machine | ||
| 1258 | #@NAME: Beaglebone-yocto machine | ||
| 1259 | #@DESCRIPTION: Reference machine configuration for http://beagleboard.org/bone and http://beagleboard.org/black boards | ||
| 1260 | |||
| 1261 | PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg" | ||
| 1262 | XSERVER ?= "xserver-xorg \ | ||
| 1263 | xf86-video-modesetting \ | ||
| 1264 | " | ||
| 1265 | |||
| 1266 | MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree" | ||
| 1267 | |||
| 1268 | EXTRA_IMAGEDEPENDS += "u-boot" | ||
| 1269 | |||
| 1270 | DEFAULTTUNE ?= "cortexa8hf-neon" | ||
| 1271 | include conf/machine/include/tune-cortexa8.inc | ||
| 1272 | |||
| 1273 | IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap" | ||
| 1274 | EXTRA_IMAGECMD_jffs2 = "-lnp " | ||
| 1275 | WKS_FILE ?= "beaglebone-yocto.wks" | ||
| 1276 | IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage" | ||
| 1277 | do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot" | ||
| 1278 | |||
| 1279 | SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0" | ||
| 1280 | SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}" | ||
| 1281 | |||
| 1282 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" | ||
| 1283 | PREFERRED_VERSION_linux-yocto ?= "5.0%" | ||
| 1284 | |||
| 1285 | KERNEL_IMAGETYPE = "zImage" | ||
| 1286 | KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb" | ||
| 1287 | KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}" | ||
| 1288 | |||
| 1289 | SPL_BINARY = "MLO" | ||
| 1290 | UBOOT_SUFFIX = "img" | ||
| 1291 | UBOOT_MACHINE = "am335x_evm_defconfig" | ||
| 1292 | UBOOT_ENTRYPOINT = "0x80008000" | ||
| 1293 | UBOOT_LOADADDRESS = "0x80008000" | ||
| 1294 | |||
| 1295 | MACHINE_FEATURES = "usbgadget usbhost vfat alsa" | ||
| 1296 | |||
| 1297 | IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb" | ||
| 1298 | |||
| 1299 | The variables used to configure the machine define machine-specific properties; for | ||
| 1300 | example, machine-dependent packages, machine tunings, the type of kernel | ||
| 1301 | to build, and U-Boot configurations. | ||
| 1302 | |||
| 1303 | The following list provides some explanation for the statements found in | ||
| 1304 | the example reference machine configuration file for the BeagleBone | ||
| 1305 | development boards. Realize that much more can be defined as part of a | ||
| 1306 | machine's configuration file. In general, you can learn about related | ||
| 1307 | variables that this example does not have by locating the variables in | ||
| 1308 | the ":ref:`ref-manual/variables:variables glossary`" in the Yocto | ||
| 1309 | Project Reference Manual. | ||
| 1310 | |||
| 1311 | - :term:`PREFERRED_PROVIDER_virtual/xserver <PREFERRED_PROVIDER>`: | ||
| 1312 | The recipe that provides "virtual/xserver" when more than one | ||
| 1313 | provider is found. In this case, the recipe that provides | ||
| 1314 | "virtual/xserver" is "xserver-xorg", which exists in | ||
| 1315 | ``poky/meta/recipes-graphics/xorg-xserver``. | ||
| 1316 | |||
| 1317 | - :term:`XSERVER`: The packages that | ||
| 1318 | should be installed to provide an X server and drivers for the | ||
| 1319 | machine. In this example, the "xserver-xorg" and | ||
| 1320 | "xf86-video-modesetting" are installed. | ||
| 1321 | |||
| 1322 | - :term:`MACHINE_EXTRA_RRECOMMENDS`: | ||
| 1323 | A list of machine-dependent packages not essential for booting the | ||
| 1324 | image. Thus, the build does not fail if the packages do not exist. | ||
| 1325 | However, the packages are required for a fully-featured image. | ||
| 1326 | |||
| 1327 | .. tip:: | ||
| 1328 | |||
| 1329 | Many ``MACHINE*`` variables exist that help you configure a particular piece | ||
| 1330 | of hardware. | ||
| 1331 | |||
| 1332 | - :term:`EXTRA_IMAGEDEPENDS`: | ||
| 1333 | Recipes to build that do not provide packages for installing into the | ||
| 1334 | root filesystem but building the image depends on the recipes. | ||
| 1335 | Sometimes a recipe is required to build the final image but is not | ||
| 1336 | needed in the root filesystem. In this case, the U-Boot recipe must | ||
| 1337 | be built for the image. | ||
| 1338 | |||
| 1339 | - :term:`DEFAULTTUNE`: Machines | ||
| 1340 | use tunings to optimize machine, CPU, and application performance. | ||
| 1341 | These features, which are collectively known as "tuning features", | ||
| 1342 | exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g. | ||
| 1343 | ``poky/meta/conf/machine/include``). In this example, the default | ||
| 1344 | tuning file is "cortexa8hf-neon". | ||
| 1345 | |||
| 1346 | .. note:: | ||
| 1347 | |||
| 1348 | The include statement that pulls in the | ||
| 1349 | ``conf/machine/include/tune-cortexa8.inc`` file provides many tuning | ||
| 1350 | possibilities. | ||
| 1351 | |||
| 1352 | - :term:`IMAGE_FSTYPES`: The | ||
| 1353 | formats the OpenEmbedded build system uses during the build when | ||
| 1354 | creating the root filesystem. In this example, four types of images | ||
| 1355 | are supported. | ||
| 1356 | |||
| 1357 | - :term:`EXTRA_IMAGECMD`: | ||
| 1358 | Specifies additional options for image creation commands. In this | ||
| 1359 | example, the "-lnp " option is used when creating the | ||
| 1360 | `JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image. | ||
| 1361 | |||
| 1362 | - :term:`WKS_FILE`: The location of | ||
| 1363 | the :ref:`Wic kickstart <ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used | ||
| 1364 | by the OpenEmbedded build system to create a partitioned image | ||
| 1365 | (image.wic). | ||
| 1366 | |||
| 1367 | - :term:`IMAGE_INSTALL`: | ||
| 1368 | Specifies packages to install into an image through the | ||
| 1369 | :ref:`image <ref-classes-image>` class. Recipes | ||
| 1370 | use the ``IMAGE_INSTALL`` variable. | ||
| 1371 | |||
| 1372 | - ``do_image_wic[depends]``: A task that is constructed during the | ||
| 1373 | build. In this example, the task depends on specific tools in order | ||
| 1374 | to create the sysroot when building a Wic image. | ||
| 1375 | |||
| 1376 | - :term:`SERIAL_CONSOLES`: | ||
| 1377 | Defines a serial console (TTY) to enable using getty. In this case, | ||
| 1378 | the baud rate is "115200" and the device name is "ttyO0". | ||
| 1379 | |||
| 1380 | - :term:`PREFERRED_PROVIDER_virtual/kernel <PREFERRED_PROVIDER>`: | ||
| 1381 | Specifies the recipe that provides "virtual/kernel" when more than | ||
| 1382 | one provider is found. In this case, the recipe that provides | ||
| 1383 | "virtual/kernel" is "linux-yocto", which exists in the layer's | ||
| 1384 | ``recipes-kernel/linux`` directory. | ||
| 1385 | |||
| 1386 | - :term:`PREFERRED_VERSION_linux-yocto <PREFERRED_VERSION>`: | ||
| 1387 | Defines the version of the recipe used to build the kernel, which is | ||
| 1388 | "5.0" in this case. | ||
| 1389 | |||
| 1390 | - :term:`KERNEL_IMAGETYPE`: | ||
| 1391 | The type of kernel to build for the device. In this case, the | ||
| 1392 | OpenEmbedded build system creates a "zImage" image type. | ||
| 1393 | |||
| 1394 | - :term:`KERNEL_DEVICETREE`: | ||
| 1395 | The names of the generated Linux kernel device trees (i.e. the | ||
| 1396 | ``*.dtb``) files. All the device trees for the various BeagleBone | ||
| 1397 | devices are included. | ||
| 1398 | |||
| 1399 | - :term:`KERNEL_EXTRA_ARGS`: | ||
| 1400 | Additional ``make`` command-line arguments the OpenEmbedded build | ||
| 1401 | system passes on when compiling the kernel. In this example, | ||
| 1402 | ``LOADADDR=${UBOOT_ENTRYPOINT}`` is passed as a command-line argument. | ||
| 1403 | |||
| 1404 | - :term:`SPL_BINARY`: Defines the | ||
| 1405 | Secondary Program Loader (SPL) binary type. In this case, the SPL | ||
| 1406 | binary is set to "MLO", which stands for Multimedia card LOader. | ||
| 1407 | |||
| 1408 | The BeagleBone development board requires an SPL to boot and that SPL | ||
| 1409 | file type must be MLO. Consequently, the machine configuration needs | ||
| 1410 | to define ``SPL_BINARY`` as ``MLO``. | ||
| 1411 | |||
| 1412 | .. note:: | ||
| 1413 | |||
| 1414 | For more information on how the SPL variables are used, see the | ||
| 1415 | :yocto_git:`u-boot.inc </poky/tree/meta/recipes-bsp/u-boot/u-boot.inc>` | ||
| 1416 | include file. | ||
| 1417 | |||
| 1418 | - :term:`UBOOT_* <UBOOT_ENTRYPOINT>`: Defines | ||
| 1419 | various U-Boot configurations needed to build a U-Boot image. In this | ||
| 1420 | example, a U-Boot image is required to boot the BeagleBone device. | ||
| 1421 | See the following variables for more information: | ||
| 1422 | |||
| 1423 | - :term:`UBOOT_SUFFIX`: | ||
| 1424 | Points to the generated U-Boot extension. | ||
| 1425 | |||
| 1426 | - :term:`UBOOT_MACHINE`: | ||
| 1427 | Specifies the value passed on the make command line when building | ||
| 1428 | a U-Boot image. | ||
| 1429 | |||
| 1430 | - :term:`UBOOT_ENTRYPOINT`: | ||
| 1431 | Specifies the entry point for the U-Boot image. | ||
| 1432 | |||
| 1433 | - :term:`UBOOT_LOADADDRESS`: | ||
| 1434 | Specifies the load address for the U-Boot image. | ||
| 1435 | |||
| 1436 | - :term:`MACHINE_FEATURES`: | ||
| 1437 | Specifies the list of hardware features the BeagleBone device is | ||
| 1438 | capable of supporting. In this case, the device supports "usbgadget | ||
| 1439 | usbhost vfat alsa". | ||
| 1440 | |||
| 1441 | - :term:`IMAGE_BOOT_FILES`: | ||
| 1442 | Files installed into the device's boot partition when preparing the | ||
| 1443 | image using the Wic tool with the ``bootimg-partition`` or | ||
| 1444 | ``bootimg-efi`` source plugin. | ||
| 1445 | |||
| 1446 | BSP Kernel Recipe Example | ||
| 1447 | ------------------------- | ||
| 1448 | |||
| 1449 | The kernel recipe used to build the kernel image for the BeagleBone | ||
| 1450 | device was established in the machine configuration: :: | ||
| 1451 | |||
| 1452 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" | ||
| 1453 | PREFERRED_VERSION_linux-yocto ?= "5.0%" | ||
| 1454 | |||
| 1455 | The ``meta-yocto-bsp/recipes-kernel/linux`` directory in the layer contains | ||
| 1456 | metadata used to build the kernel. In this case, a kernel append file | ||
| 1457 | (i.e. ``linux-yocto_5.0.bbappend``) is used to override an established | ||
| 1458 | kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in | ||
| 1459 | :yocto_git:`/poky/tree/meta/recipes-kernel/linux`. | ||
| 1460 | |||
| 1461 | Following is the contents of the append file: :: | ||
| 1462 | |||
| 1463 | KBRANCH_genericx86 = "v5.0/standard/base" | ||
| 1464 | KBRANCH_genericx86-64 = "v5.0/standard/base" | ||
| 1465 | KBRANCH_edgerouter = "v5.0/standard/edgerouter" | ||
| 1466 | KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone" | ||
| 1467 | |||
| 1468 | KMACHINE_genericx86 ?= "common-pc" | ||
| 1469 | KMACHINE_genericx86-64 ?= "common-pc-64" | ||
| 1470 | KMACHINE_beaglebone-yocto ?= "beaglebone" | ||
| 1471 | |||
| 1472 | SRCREV_machine_genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" | ||
| 1473 | SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" | ||
| 1474 | SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" | ||
| 1475 | SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" | ||
| 1476 | |||
| 1477 | COMPATIBLE_MACHINE_genericx86 = "genericx86" | ||
| 1478 | COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" | ||
| 1479 | COMPATIBLE_MACHINE_edgerouter = "edgerouter" | ||
| 1480 | COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto" | ||
| 1481 | |||
| 1482 | LINUX_VERSION_genericx86 = "5.0.3" | ||
| 1483 | LINUX_VERSION_genericx86-64 = "5.0.3" | ||
| 1484 | LINUX_VERSION_edgerouter = "5.0.3" | ||
| 1485 | LINUX_VERSION_beaglebone-yocto = "5.0.3" | ||
| 1486 | |||
| 1487 | This particular append file works for all the machines that are | ||
| 1488 | part of the ``meta-yocto-bsp`` layer. The relevant statements are | ||
| 1489 | appended with the "beaglebone-yocto" string. The OpenEmbedded build | ||
| 1490 | system uses these statements to override similar statements in the | ||
| 1491 | kernel recipe: | ||
| 1492 | |||
| 1493 | - :term:`KBRANCH`: Identifies the | ||
| 1494 | kernel branch that is validated, patched, and configured during the | ||
| 1495 | build. | ||
| 1496 | |||
| 1497 | - :term:`KMACHINE`: Identifies the | ||
| 1498 | machine name as known by the kernel, which is sometimes a different | ||
| 1499 | name than what is known by the OpenEmbedded build system. | ||
| 1500 | |||
| 1501 | - :term:`SRCREV`: Identifies the | ||
| 1502 | revision of the source code used to build the image. | ||
| 1503 | |||
| 1504 | - :term:`COMPATIBLE_MACHINE`: | ||
| 1505 | A regular expression that resolves to one or more target machines | ||
| 1506 | with which the recipe is compatible. | ||
| 1507 | |||
| 1508 | - :term:`LINUX_VERSION`: The | ||
| 1509 | Linux version from kernel.org used by the OpenEmbedded build system | ||
| 1510 | to build the kernel image. | ||
diff --git a/documentation/bsp-guide/figures/bsp-dev-flow.png b/documentation/bsp-guide/figures/bsp-dev-flow.png deleted file mode 100644 index 2ca1fecada..0000000000 --- a/documentation/bsp-guide/figures/bsp-dev-flow.png +++ /dev/null | |||
| Binary files differ | |||
diff --git a/documentation/bsp-guide/figures/bsp-title.png b/documentation/bsp-guide/figures/bsp-title.png deleted file mode 100644 index f624dd4f94..0000000000 --- a/documentation/bsp-guide/figures/bsp-title.png +++ /dev/null | |||
| Binary files differ | |||
diff --git a/documentation/bsp-guide/history.rst b/documentation/bsp-guide/history.rst deleted file mode 100644 index d7cd8ef7f0..0000000000 --- a/documentation/bsp-guide/history.rst +++ /dev/null | |||
| @@ -1,73 +0,0 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | *********************** | ||
| 4 | Manual Revision History | ||
| 5 | *********************** | ||
| 6 | |||
| 7 | .. list-table:: | ||
| 8 | :widths: 10 15 40 | ||
| 9 | :header-rows: 1 | ||
| 10 | |||
| 11 | * - Revision | ||
| 12 | - Date | ||
| 13 | - Note | ||
| 14 | * - 0.9 | ||
| 15 | - November 2010 | ||
| 16 | - The initial document released with the Yocto Project 0.9 Release | ||
| 17 | * - 1.0 | ||
| 18 | - April 2011 | ||
| 19 | - Released with the Yocto Project 1.0 Release. | ||
| 20 | * - 1.1 | ||
| 21 | - October 2011 | ||
| 22 | - Released with the Yocto Project 1.1 Release. | ||
| 23 | * - 1.2 | ||
| 24 | - April 2012 | ||
| 25 | - Released with the Yocto Project 1.2 Release. | ||
| 26 | * - 1.3 | ||
| 27 | - October 2012 | ||
| 28 | - Released with the Yocto Project 1.3 Release. | ||
| 29 | * - 1.4 | ||
| 30 | - April 2013 | ||
| 31 | - Released with the Yocto Project 1.4 Release. | ||
| 32 | * - 1.5 | ||
| 33 | - October 2013 | ||
| 34 | - Released with the Yocto Project 1.5 Release. | ||
| 35 | * - 1.6 | ||
| 36 | - April 2014 | ||
| 37 | - Released with the Yocto Project 1.6 Release. | ||
| 38 | * - 1.7 | ||
| 39 | - October 2014 | ||
| 40 | - Released with the Yocto Project 1.7 Release. | ||
| 41 | * - 1.8 | ||
| 42 | - April 2015 | ||
| 43 | - Released with the Yocto Project 1.8 Release. | ||
| 44 | * - 2.0 | ||
| 45 | - October 2015 | ||
| 46 | - Released with the Yocto Project 2.0 Release. | ||
| 47 | * - 2.1 | ||
| 48 | - April 2016 | ||
| 49 | - Released with the Yocto Project 2.1 Release. | ||
| 50 | * - 2.2 | ||
| 51 | - October 2016 | ||
| 52 | - Released with the Yocto Project 2.2 Release. | ||
| 53 | * - 2.3 | ||
| 54 | - May 2017 | ||
| 55 | - Released with the Yocto Project 2.3 Release. | ||
| 56 | * - 2.4 | ||
| 57 | - October 2017 | ||
| 58 | - Released with the Yocto Project 2.4 Release. | ||
| 59 | * - 2.5 | ||
| 60 | - May 2018 | ||
| 61 | - Released with the Yocto Project 2.5 Release. | ||
| 62 | * - 2.6 | ||
| 63 | - November 2018 | ||
| 64 | - Released with the Yocto Project 2.6 Release. | ||
| 65 | * - 2.7 | ||
| 66 | - May 2019 | ||
| 67 | - Released with the Yocto Project 2.7 Release. | ||
| 68 | * - 3.0 | ||
| 69 | - October 2019 | ||
| 70 | - Released with the Yocto Project 3.0 Release. | ||
| 71 | * - 3.1 | ||
| 72 | - April 2020 | ||
| 73 | - Released with the Yocto Project 3.1 Release. | ||
diff --git a/documentation/bsp-guide/index.rst b/documentation/bsp-guide/index.rst deleted file mode 100644 index a4394a85ed..0000000000 --- a/documentation/bsp-guide/index.rst +++ /dev/null | |||
| @@ -1,16 +0,0 @@ | |||
| 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
| 2 | |||
| 3 | ===================================================== | ||
| 4 | Yocto Project Board Support Package Developer's Guide | ||
| 5 | ===================================================== | ||
| 6 | |||
| 7 | | | ||
| 8 | |||
| 9 | .. toctree:: | ||
| 10 | :caption: Table of Contents | ||
| 11 | :numbered: | ||
| 12 | |||
| 13 | bsp | ||
| 14 | history | ||
| 15 | |||
| 16 | .. include:: /boilerplate.rst | ||
