From 4c19ea120a3e7a73dc8470c86744bc95997f1c90 Mon Sep 17 00:00:00 2001 From: Andrew Geissler Date: Tue, 27 Oct 2020 13:52:24 -0500 Subject: poky: subtree update:ad30a6d470..7231c10430 Akira Shibakawa (3): License-Update: attr: Add a missing file to LIC_FILES_CHKSUM. License-Update: kmod: Add a missing file to LIC_FILES_CHKSUM. License-Update: gdk-pixbuf: Fix LICENSE. Alejandro Hernandez Samaniego (1): baremetal-helloworld: Fix install path since S doesnt have a trailing slash Alexander Kanavin (4): ncurses: only include upstream releases in version check python3: fix upstream version check boost-build-native: fix upstream version check selftest/virgl: drop the custom 30 sec timeout Alistair (1): weston-init: Allow setting idle time to 0 Changqing Li (1): toolchain-shar-extract.sh: don't print useless info Charlie Davies (1): bitbake: bitbake: fetch/git: use shlex.quote() to support spaces in SRC_URI url Chen Qi (2): watchdog: use /run instead of /var/run in systemd service file cups: use /run instead /var/run in systemd's unit file David Reyna (1): bitbake: toaster: Enable Gatesgarth branch in place of Zeus Douglas Royds (1): externalsrc: No single-task lock if S != B Joshua Watt (2): ref-variables: Given example for naming sources ref-manual: Document wic --offset option Khairul Rohaizzat Jamaluddin (1): imagefeatures: New test case, test_empty_image, added Khem Raj (5): autotools.bbclass: Order CONFIG_SHELL before CACHED_CONFIGUREVARS boost: Fix build on 32-bit arches with 64bit time_t only mesa: Fix build on 32bit arches supporting 64bit time_t only packagegroup-core-tools-debug: Disable for rv32/glibc as well packagegroup-core-tools-profile: Remove lttng-tools and perf for rv32/glibc Konrad Weihmann (1): lib/oe/rootfs: introduce IMAGE_LOG_CHECK_EXCLUDES Lee Chee Yang (2): libproxy: fix CVE-2020-25219 grub2: fix CVE-2020-10713 Martin Jansa (11): tune-cortexa76ae.inc: Correct TUNE_FEATURES arch-armv7a.inc: fix typo arch-mips.inc: remove duplicated mips64el-o32 from PACKAGE_EXTRA_ARCHS_tune-mips64el-o32 arch-arm64.inc: don't append _be to ARMPKGARCH for tune-aarch64_be tune-mips64r6.inc: fix typo in mipsisa64r6-nf tune-ep9312.inc: add t suffix for thumb to PACKAGE_EXTRA_ARCHS_tune-ep9312 tune-riscv.inc: use nf suffix also for TUNE_PKGARCH tune-supersparc.inc: remove tune-thunderx.inc: don't append _be to ARMPKGARCH for tune-thunderx_be siteinfo: Recognize 32bit PPC LE siteinfo: Recognize bigendian sh3be and sh4be Max Krummenacher (2): linux-firmware: package marvel sdio 8997 firmware linux-firmware: package nvidia firmware Mingli Yu (1): tcl: adapt to potential pseudo changes Naoki Hayama (1): dev/test/ref-manual: Fix typos Neil Armstrong (1): linux-firmware: add Amlogic VDEC firmware package Nicolas Dechesne (4): sdk-manual: use built-in footnotes dev-manual/dev-manual-common-tasks: fix warning sphinx: add 3.1.3 and 3.0.4 release in the switcher dev-manual/dev-manual-common-tasks: fix typos and use extlinks Paul Eggleton (2): classes/buildhistory: record SRC_URI classes/buildhistory: also save recipe info for native recipes Quentin Schulz (17): docs: poky.yaml: use HTTPS for links docs: ref-manual: indentation, links and highlights fixes docs: remove OE_INIT_FILE variable docs: ref-manual: fix typos docs: ref-manual: migration-2.3: specify 2.3 version instead of DISTRO docs: ref-manual: ref-classes: remove dropped tinderclient class docs: ref-manual: ref-system-requirements: update requirements to build Sphinx docs docs: sphinx: yocto-vars: rebuild files when poky.yaml has changed docs: poky.yaml: fix identation in host packages variables docs: dev-manual-common-tasks: remove paragraph about race when missing DEPENDS docs: dev-manual-common-tasks: update python webserver example to python3 docs: dev-manual: fix typos, highlights, indentation and links docs: ref-manual: ref-terms: add links to terms in glossary docs: bsp-guide: bsp: fix typos, highlights and links docs: kernel-dev: fix typos, highlights and links docs: kernel-dev-common: add .patch file extension to SRC_URI files docs: kernel-dev-faq: update outdated RDEPENDS_kernel-base Reyna, David (1): bitbake: toaster: Update documentation links to new URLs Richard Purdie (10): layer.conf: Switch to gatesgarth only in preparation for release bitbake: ui/toasterui: Fix startup faults from incorrect event sequencing bitbake: bitbake: Bump version to 1.48.0 ready for the new release oeqa: Add sync call to command execution poky.conf: Bump version for 3.2 gatesgarth release build-appliance-image: Update to master head revision bitbake: tests/fetch: Update upstream master->main branchname transition Revert "classes/buildhistory: also save recipe info for native recipes" valgrind: Fix build on musl after drd fixes build-appliance-image: Update to master head revision Robert Yang (1): weston: Fix PACKAGECONFIG for remoting Roland Hieber (1): devtool: make sure .git/info exists before writing to .git/info/excludes Ross Burton (4): waf: don't assume the waf intepretter is good waf: add ${B} to do_configure[cleandirs] scripts/install-buildtools: Update to 3.2 M3 buildtools glib-2.0: fix parsing of slim encoded tzdata Sourabh Banerjee (1): layer.conf: fix sanity error for PATH variable in extensible SDK workflow Stacy Gaikovaia (2): valgrind: drd: fix pthread intercept test failures bitbake: main: Handle cooker daemon startup error Tim Orling (1): bitbake: lib/bb/ui/knotty: fix typo in parseprogress Victor Kamensky (3): Revert "qemumips: use 34Kf-64tlb CPU emulation" Revert "qemu: add 34Kf-64tlb fictitious cpu type" qemu: change TLBs number to 64 in 34Kf mips cpu model Yi Zhao (1): dhcpcd: add PACKAGECONFIG for ntp/chrony/ypbind hooks Zang Ruochen (1): harfbuzz: Refresh patch akuster (2): busybox: add rev and pgrep kea: add init scripts leimaohui (1): docs: Updated the status of spdx module. zangrc (1): classes: Fixed the problem of undefined variables when compiling meta-toolchain. Signed-off-by: Andrew Geissler Change-Id: Ic45bc219b94960751896a0ae3d4923a9f5849e70 --- poky/documentation/bsp-guide/bsp.rst | 78 +++++++++++++++++++----------------- 1 file changed, 41 insertions(+), 37 deletions(-) (limited to 'poky/documentation/bsp-guide/bsp.rst') diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index 61b295827..d0275eea9 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -31,14 +31,14 @@ convention: :: meta-bsp_root_name The string "meta-" is prepended to the -machine or platform name, which is bsp_root_name in the above form. +machine or platform name, which is "bsp_root_name" in the above form. .. note:: Because the BSP layer naming convention is well-established, it is advisable to follow it when creating layers. Technically speaking, a - BSP layer name does not need to start with - meta-. However, various scripts and tools in the Yocto Project development + BSP layer name does not need to start with ``meta-``. + However, various scripts and tools in the Yocto Project development environment assume this convention. To help understand the BSP layer concept, consider the BSPs that the @@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the ``conf/bblayers.conf`` file found in your :term:`Build Directory`, which is established after you run the OpenEmbedded build environment setup -script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\`` ). +script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``). Adding the root directory allows the :term:`OpenEmbedded Build System` to recognize the BSP layer and from it build an image. Here is an example: :: @@ -95,10 +95,11 @@ layer and from it build an image. Here is an example: :: .. note:: - Ordering and ``BBFILE_PRIORITY`` for the layers listed in BBLAYERS matter. For - example, if multiple layers define a machine configuration, the OpenEmbedded - build system uses the last layer searched given similar layer priorities. The - build system works from the top-down through the layers listed in ``BBLAYERS``. + Ordering and :term:`BBFILE_PRIORITY` for the layers listed in ``BBLAYERS`` + matter. For example, if multiple layers define a machine configuration, the + OpenEmbedded build system uses the last layer searched given similar layer + priorities. The build system works from the top-down through the layers + listed in ``BBLAYERS``. Some BSPs require or depend on additional layers beyond the BSP's root layer in order to be functional. In this case, you need to specify these @@ -107,7 +108,7 @@ Additionally, if any build instructions exist for the BSP, you must add them to the "Dependencies" section. Some layers function as a layer to hold other BSP layers. These layers -are knows as ":term:`container layers `". An example of +are known as ":term:`container layers `". An example of this type of layer is OpenEmbedded's `meta-openembedded `__ layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers. @@ -141,8 +142,8 @@ section. .. note:: - For structural information on BSPs, see the Example Filesystem Layout - section. + For structural information on BSPs, see the + :ref:`bsp-guide/bsp:example filesystem layout` section. #. *Set Up the Build Environment:* Be sure you are set up to use BitBake in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`" @@ -150,10 +151,10 @@ section. to get a build host ready that is either a native Linux machine or a machine that uses CROPS. -#. *Clone the ``poky`` Repository:* You need to have a local copy of the +#. *Clone the poky Repository:* You need to have a local copy of the Yocto Project :term:`Source Directory` (i.e. a local ``poky`` repository). See the - "ref:`dev-manual/dev-manual-start:cloning the ``poky`` repository`" and + ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and possibly the ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" or ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`" @@ -168,7 +169,7 @@ section. BSP layers, you can look at the `index of machines <&YOCTO_RELEASE_DL_URL;/machines>`__ for the release. -#. *Optionally Clone the ``meta-intel`` BSP Layer:* If your hardware is +#. *Optionally Clone the meta-intel BSP Layer:* If your hardware is based on current Intel CPUs and devices, you can leverage this BSP layer. For details on the ``meta-intel`` BSP layer, see the layer's `README `__ @@ -193,7 +194,7 @@ section. #. *Check Out the Proper Branch:* The branch you check out for ``meta-intel`` must match the same branch you are using for the - Yocto Project release (e.g. &DISTRO_NAME_NO_CAP;): :: + Yocto Project release (e.g. ``&DISTRO_NAME_NO_CAP;``): :: $ cd meta-intel $ git checkout -b &DISTRO_NAME_NO_CAP; remotes/origin/&DISTRO_NAME_NO_CAP; @@ -233,7 +234,7 @@ section. setup script to define the OpenEmbedded build environment on your build host. :: - $ source &OE_INIT_FILE; + $ source oe-init-build-env Among other things, the script creates the :term:`Build Directory`, which is ``build`` in this case and is located in the :term:`Source Directory`. After @@ -291,7 +292,9 @@ individual BSPs could differ. :: meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend Below is an example of the Raspberry Pi BSP layer that is available from -the :yocto_git:`Source Respositories <>`: :: +the :yocto_git:`Source Respositories <>`: + +.. code-block:: none meta-raspberrypi/COPYING.MIT meta-raspberrypi/README.md @@ -544,13 +547,13 @@ The ``conf/layer.conf`` file identifies the file structure as a layer, identifies the contents of the layer, and contains information about how the build system should use it. Generally, a standard boilerplate file such as the following works. In the following example, you would replace -bsp with the actual name of the BSP (i.e. bsp_root_name from the example +"bsp" with the actual name of the BSP (i.e. "bsp_root_name" from the example template). :: # We have a conf and classes directory, add to BBPATH BBPATH .= ":${LAYERDIR}" - # We have a recipes directory, add to BBFILES + # We have a recipes directory containing .bb and .bbappend files, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" @@ -694,7 +697,7 @@ located in the BSP Layer for your target device (e.g. the Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the kernel. In other words, you have selected the kernel in your -bsp_root_name\ ``.conf`` file by adding +``"bsp_root_name".conf`` file by adding :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION` statements as follows: :: @@ -704,7 +707,7 @@ statements as follows: :: .. note:: When the preferred provider is assumed by default, the ``PREFERRED_PROVIDER`` - statement does not appear in the ``bsp_root_name`` .conf file. + statement does not appear in the ``"bsp_root_name".conf`` file. You would use the ``linux-yocto_4.4.bbappend`` file to append specific BSP settings to the kernel, thus configuring the kernel for your @@ -781,7 +784,7 @@ workflow. .. note:: - - Five hardware reference BSPs exist that are part of the Yocto + - Four hardware reference BSPs exist that are part of the Yocto Project release and are located in the ``poky/meta-yocto-bsp`` BSP layer: @@ -870,8 +873,8 @@ Before looking at BSP requirements, you should consider the following: - The requirements in this section apply regardless of how you package a BSP. You should consult the packaging and distribution guidelines for your specific release process. For an example of packaging and - distribution requirements, see the "`Third Party BSP Release - Process `__" + distribution requirements, see the ":yocto_wiki:`Third Party BSP Release + Process `" wiki page. - The requirements for the BSP as it is made available to a developer @@ -897,7 +900,7 @@ Yocto Project: your BSP layer as listed in the ``recipes.txt`` file, which is found in ``poky/meta`` directory of the :term:`Source Directory` or in the OpenEmbedded-Core Layer (``openembedded-core``) at - http://git.openembedded.org/openembedded-core/tree/meta. + https://git.openembedded.org/openembedded-core/tree/meta. You should place recipes (``*.bb`` files) and recipe modifications (``*.bbappend`` files) into ``recipes-*`` subdirectories by @@ -1074,7 +1077,7 @@ also supports several other machines: .. note:: - If the meta-xyz layer did not support multiple machines, you would place + If the ``meta-xyz`` layer did not support multiple machines, you would place the interfaces configuration file in the layer here: :: meta-xyz/recipes-core/init-ifupdown/files/interfaces @@ -1233,7 +1236,7 @@ file. In this example, the ``conf/layer.conf`` is the following: :: # We have a conf and classes directory, add to BBPATH BBPATH .= ":${LAYERDIR}" - # We have recipes-\* directories, add to BBFILES + # We have a recipes directory containing .bb and .bbappend files, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" @@ -1262,13 +1265,13 @@ general or kernel layer. One or more machine configuration files exist in the ``bsp_layer/conf/machine/`` directory of the layer: :: - bsp_layer/conf/machine/machine1\.conf`` - bsp_layer/conf/machine/machine2\.conf`` - bsp_layer/conf/machine/machine3\.conf`` + bsp_layer/conf/machine/machine1\.conf + bsp_layer/conf/machine/machine2\.conf + bsp_layer/conf/machine/machine3\.conf ... more ... For example, the machine configuration file for the `BeagleBone and -BeagleBone Black development boards `__ is +BeagleBone Black development boards `__ is located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named ``beaglebone-yocto.conf``: :: @@ -1344,7 +1347,7 @@ Project Reference Manual. .. tip:: - Many ``MACHINE\*`` variables exist that help you configure a particular piece + Many ``MACHINE*`` variables exist that help you configure a particular piece of hardware. - :term:`EXTRA_IMAGEDEPENDS`: @@ -1359,12 +1362,12 @@ Project Reference Manual. These features, which are collectively known as "tuning features", exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g. ``poky/meta/conf/machine/include``). In this example, the default - tunning file is "cortexa8hf-neon". + tuning file is "cortexa8hf-neon". .. note:: The include statement that pulls in the - conf/machine/include/tune-cortexa8.inc file provides many tuning + ``conf/machine/include/tune-cortexa8.inc`` file provides many tuning possibilities. - :term:`IMAGE_FSTYPES`: The @@ -1389,7 +1392,7 @@ Project Reference Manual. - ``do_image_wic[depends]``: A task that is constructed during the build. In this example, the task depends on specific tools in order - to create the sysroot when buiding a Wic image. + to create the sysroot when building a Wic image. - :term:`SERIAL_CONSOLES`: Defines a serial console (TTY) to enable using getty. In this case, @@ -1429,7 +1432,8 @@ Project Reference Manual. .. note:: - For more information on how the SPL variables are used, see the u-boot.inc + For more information on how the SPL variables are used, see the + :yocto_git:`u-boot.inc ` include file. - :term:`UBOOT_* `: Defines @@ -1473,7 +1477,7 @@ The ``meta-yocto-bsp/recipes-kernel/linux`` directory in the layer contains metadata used to build the kernel. In this case, a kernel append file (i.e. ``linux-yocto_5.0.bbappend``) is used to override an established kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in -https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux. +:yocto_git:`/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux`. Following is the contents of the append file: :: -- cgit v1.2.3