diff options
Diffstat (limited to 'yocto-poky/documentation/bsp-guide/bsp.xml')
-rw-r--r-- | yocto-poky/documentation/bsp-guide/bsp.xml | 477 |
1 files changed, 308 insertions, 169 deletions
diff --git a/yocto-poky/documentation/bsp-guide/bsp.xml b/yocto-poky/documentation/bsp-guide/bsp.xml index ec39ec9b3..b0562c7d4 100644 --- a/yocto-poky/documentation/bsp-guide/bsp.xml +++ b/yocto-poky/documentation/bsp-guide/bsp.xml @@ -60,16 +60,28 @@ <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>. If you go to that interface, you will find near the bottom of the list under "Yocto Metadata Layers" several BSP layers all of which are - supported by the Yocto Project (e.g. <filename>meta-minnow</filename>, - <filename>meta-raspberrypi</filename>, and + supported by the Yocto Project (e.g. <filename>meta-raspberrypi</filename> and <filename>meta-intel</filename>). Each of these layers is a repository unto itself and clicking on a layer reveals information that includes two links from which you can choose to set up a clone of the layer's repository on your local host system. - Here is an example that clones the MinnowBoard BSP layer: + Here is an example that clones the Raspberry Pi BSP layer: <literallayout class='monospaced'> - $ git clone git://git.yoctoproject.org/meta-minnow + $ git clone git://git.yoctoproject.org/meta-raspberrypi </literallayout> + </para> + + <para> + In addition to BSP layers near the bottom of that referenced + Yocto Project Source Repository, the + <filename>meta-yocto-bsp</filename> layer is part of the + shipped <filename>poky</filename> repository. + The <filename>meta-yocto-bsp</filename> layer maintains several + BSPs such as the Beaglebone, EdgeRouter, and generic versions of + both 32 and 64-bit IA machines. + </para> + + <para> For information on the BSP development workflow, see the "<ulink url='&YOCTO_DOCS_DEV_URL;#developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</ulink>" section in the Yocto Project Development Manual. @@ -80,8 +92,9 @@ </para> <para> - The layer's base directory (<filename>meta-<replaceable>bsp_name</replaceable></filename>) is the root - of the BSP Layer. + The layer's base directory + (<filename>meta-<replaceable>bsp_name</replaceable></filename>) + is the root of the BSP Layer. This root is what you add to the <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> variable in the <filename>conf/bblayers.conf</filename> file found in the @@ -97,7 +110,7 @@ <literallayout class='monospaced'> BBLAYERS ?= " \ /usr/local/src/yocto/meta \ - /usr/local/src/yocto/meta-yocto \ + /usr/local/src/yocto/meta-poky \ /usr/local/src/yocto/meta-yocto-bsp \ /usr/local/src/yocto/meta-mylayer \ " @@ -121,6 +134,8 @@ An example of this type of layer is the <filename>meta-intel</filename> layer, which contains a number of individual BSP sub-layers, as well as a directory named <filename>common/</filename> full of common content across those layers. + Another example is the <filename>meta-yocto-bsp</filename> layer mentioned + earlier. </para> <para> @@ -130,7 +145,6 @@ </para> </section> - <section id="bsp-filelayout"> <title>Example Filesystem Layout</title> @@ -194,33 +208,142 @@ </para> <para> - Below is an example of the eMenlow BSP: + Below is an example of the Raspberry Pi BSP: <literallayout class='monospaced'> - meta-emenlow/COPYING.MIT - meta-emenlow/README - meta-emenlow/README.sources - meta-emenlow/binary/ - meta-emenlow/conf/ - meta-emenlow/conf/layer.conf - meta-emenlow/conf/machine/ - meta-emenlow/conf/machine/emenlow-noemgd.conf - meta-emenlow/recipes-bsp/ - meta-emenlow/recipes-bsp/formfactor/ - meta-emenlow/recipes-bsp/formfactor/formfactor/ - meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend - meta-emenlow/recipes-bsp/formfactor/formfactor/emenlow-noemgd/ - meta-emenlow/recipes-bsp/formfactor/formfactor/emenlow-noemgd/machconfig - meta-emenlow/recipes-graphics/ - meta-emenlow/recipes-graphics/xorg-xserver - meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config - meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend - meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd - meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd/xorg.config - meta-emenlow/recipes-kernel/ - meta-emenlow/recipes-kernel/linux/ - meta-emenlow/recipes-kernel/linux/linux-yocto-dev.bbappend - meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend + meta-raspberrypi/COPYING.MIT + meta-raspberrypi/README + meta-raspberrypi/classes + meta-raspberrypi/classes/linux-raspberrypi-base.bbclass + meta-raspberrypi/classes/sdcard_image-rpi.bbclass + meta-raspberrypi/conf/ + meta-raspberrypi/conf/layer.conf + meta-raspberrypi/conf/machine/ + meta-raspberrypi/conf/machine/raspberrypi.conf + meta-raspberrypi/conf/machine/raspberrypi0.conf + meta-raspberrypi/conf/machine/raspberrypi2.conf + meta-raspberrypi/conf/machine/raspberrypi3.conf + meta-raspberrypi/conf/machine/include + meta-raspberrypi/conf/machine/include/rpi-base.inc + meta-raspberrypi/conf/machine/include/rpi-default-providers.inc + meta-raspberrypi/conf/machine/include/rpi-default-settings.inc + meta-raspberrypi/conf/machine/include/rpi-default-versions.inc + meta-raspberrypi/conf/machine/include/rpi-tune-arm1176jzf-s.inc + meta-raspberrypi/files + meta-raspberrypi/files/custom-licenses + meta-raspberrypi/files/custom-licenses/Broadcom + meta-raspberrypi/recipes-bsp + meta-raspberrypi/recipes-bsp/bootfiles + meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb + meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb + meta-raspberrypi/recipes-bsp/common + meta-raspberrypi/recipes-bsp/common/firmware.inc + meta-raspberrypi/recipes-bsp/formfactor_00.bbappend + meta-raspberrypi/recipes-bsp/formfactor/raspberrypi/machconfig + meta-raspberrypi/recipes-bsp/rpi-mkimage_git.bb + meta-raspberrypi/recipes-bsp/rpi-mkimage/License + meta-raspberrypi/recipes-bsp/rpi-mkimage/open-files-relative-to-script.patch + meta-raspberrypi/recipes-bsp/u-boot/u-boot-rpi_git.bb + meta-raspberrypi/recipes-core + meta-raspberrypi/recipes-core/images + meta-raspberrypi/recipes-core/images/rpi-basic-image.bb + meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb + meta-raspberrypi/recipes-core/images/rpi-test-image.bb + meta-raspberrypi/recipes-core/packagegroups + meta-raspberrypi/recipes-core/packagegroups/packagegroup-rpi-test.bb + meta-raspberrypi/recipes-core/psplash + meta-raspberrypi/recipes-core/psplash/files + meta-raspberrypi/recipes-core/psplash/psplash_git.bbappend + meta-raspberrypi/recipes-core/psplash/files/psplash-raspberrypi-img.h + meta-raspberrypi/recipes-devtools + meta-raspberrypi/recipes-devtools/bcm2835 + meta-raspberrypi/recipes-devtools/bcm2835/bcm2835_1.46.bb + meta-raspberrypi/recipes-devtools/pi-blaster + meta-raspberrypi/recipes-devtools/pi-blaster/files + meta-raspberrypi/recipes-devtools/pi-blaster/*.patch + meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster.inc + meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster_git.bb + meta-raspberrypi/recipes-devtools/python + meta-raspberrypi/recipes-devtools/python/python-rtimu + meta-raspberrypi/recipes-devtools/python/python-rtimu/*.patch + meta-raspberrypi/recipes-devtools/python/python-rtimu_git.bb + meta-raspberrypi/recipes-devtools/python/python-sense-hat_2.1.0.bb + meta-raspberrypi/recipes-devtools/python/rpi-gpio + meta-raspberrypi/recipes-devtools/python/rpi-gpio/*.patch + meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.1.bb + meta-raspberrypi/recipes-devtools/python/rpio + meta-raspberrypi/recipes-devtools/python/rpio/*.patch + meta-raspberrypi/recipes-devtools/python/rpio_0.10.0.bb + meta-raspberrypi/recipes-devtools/wiringPi + meta-raspberrypi/recipes-devtools/wiringPi/files + meta-raspberrypi/recipes-devtools/wiringPi/files/*.patch + meta-raspberrypi/recipes-devtools/wiringPi/wiringpi + meta-raspberrypi/recipes-devtools/wiringPi/wiringpi/*.patch + meta-raspberrypi/recipes-devtools/wiringPi/wiringpi_git.bb + meta-raspberrypi/recipes-graphics + meta-raspberrypi/recipes-graphics/eglinfo + meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-fb_%.bbappend + meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-x11_%.bbappend + meta-raspberrypi/recipes-graphics/userland + meta-raspberrypi/recipes-graphics/userland/userland + meta-raspberrypi/recipes-graphics/userland/userland/*.patch + meta-raspberrypi/recipes-graphics/userland/userland_git.bb + meta-raspberrypi/recipes-graphics/vc-graphics + meta-raspberrypi/recipes-graphics/vc-graphics/files + meta-raspberrypi/recipes-graphics/vc-graphics/files/egl.pc + meta-raspberrypi/recipes-graphics/vc-graphics/files/vchiq.sh + meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics-hardfp.bb + meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.bb + meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.inc + meta-raspberrypi/recipes-graphics/wayland + meta-raspberrypi/recipes-graphics/wayland/weston_%.bbappend + meta-raspberrypi/recipes-graphics/weston + meta-raspberrypi/recipes-graphics/weston/weston_%.bbappend + meta-raspberrypi/recipes-graphics/xorg-xserver + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/99-pitft.conf + meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend + meta-raspberrypi/recipes-kernel + meta-raspberrypi/recipes-kernel/linux-firmware + meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware + meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware/LICENSE.broadcom_brcm80211 + meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware/brcmfmac43430-sdio.bin + meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware/brcmfmac43430-sdio.txt + meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_git.bbappend + meta-raspberrypi/recipes-kernel/linux + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.14 + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.14/*.patch + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.18 + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.18/*.patch + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.1 + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.1/*.patch + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_3.14.bb + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_3.18.bb + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.1.bb + meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.4.bb + meta-raspberrypi/recipes-kernel/linux/linux.inc + meta-raspberrypi/recipes-multimedia + meta-raspberrypi/recipes-multimedia/gstreamer + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx/*.patch + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_%.bbappend + meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend + meta-raspberrypi/recipes-multimedia/omxplayer + meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer + meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer/*.patch + meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb + meta-raspberrypi/scripts + meta-raspberrypi/scripts/lib + meta-raspberrypi/scripts/lib/image + meta-raspberrypi/scripts/lib/image/canned-wks + meta-raspberrypi/scripts/lib/image/canned-wks/sdimage-raspberrypi.wks </literallayout> </para> @@ -241,7 +364,7 @@ <para> These optional files satisfy licensing requirements for the BSP. The type or types of files here can vary depending on the licensing requirements. - For example, in the eMenlow BSP all licensing requirements are handled with the + For example, in the Raspberry Pi BSP all licensing requirements are handled with the <filename>COPYING.MIT</filename> file. </para> @@ -363,7 +486,7 @@ # We have a recipes directory, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ - ${LAYERDIR}/recipes-*/*/*.bbappend" + ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "<replaceable>bsp</replaceable>" BBFILE_PATTERN_<replaceable>bsp</replaceable> = "^${LAYERDIR}/" @@ -375,20 +498,21 @@ <para> To illustrate the string substitutions, here are the corresponding statements - from the eEmenlow <filename>conf/layer.conf</filename> file: + from the Raspberry Pi <filename>conf/layer.conf</filename> file: <literallayout class='monospaced'> - # We have a conf and classes directory, add to BBPATH + # We have a conf and classes directory, append to BBPATH BBPATH .= ":${LAYERDIR}" - # We have recipes-* directories, add to BBFILES - BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ - ${LAYERDIR}/recipes-*/*/*.bbappend" + # We have a recipes directory containing .bb and .bbappend files, add to BBFILES + BBFILES += "${LAYERDIR}/recipes*/*/*.bb \ + ${LAYERDIR}/recipes*/*/*.bbappend" - BBFILE_COLLECTIONS += "emenlow" - BBFILE_PATTERN_emenlow := "^${LAYERDIR}/" - BBFILE_PRIORITY_emenlow = "6" + BBFILE_COLLECTIONS += "raspberrypi" + BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/" + BBFILE_PRIORITY_raspberrypi = "9" - LAYERDEPENDS_emenlow = "intel" + # Additional license directories. + LICENSE_PATH += "${LAYERDIR}/files/custom-licenses" </literallayout> </para> @@ -450,13 +574,11 @@ <para> To use an include file, you simply include them in the machine configuration file. - For example, the eEmenlow BSP - <filename>emenlow-noemgd.conf</filename> contains the - following statements: + For example, the Raspberry Pi BSP + <filename>raspberrypi3.conf</filename> contains the + following statement: <literallayout class='monospaced'> - require conf/machine/include/intel-core2-32-common.inc - require conf/machine/include/intel-common-pkgarch.inc - require conf/machine/include/meta-intel.inc + include conf/machine/raspberrypi2.conf </literallayout> </para> </section> @@ -474,20 +596,22 @@ This optional directory contains miscellaneous recipe files for the BSP. Most notably would be the formfactor files. - For example, in the eMenlow BSP there is the + For example, in the Raspberry Pi BSP there is the <filename>formfactor_0.0.bbappend</filename> file, which is an append file used to augment the recipe that starts the build. Furthermore, there are machine-specific settings used during the build that are defined by the <filename>machconfig</filename> file further down in the directory. - In the eMenlow example, the <filename>machconfig</filename> - file supports the Video Electronics Standards Association - (VESA) graphics driver: + Here is the <filename>machconfig</filename> + file for the Raspberry Pi BSP: <literallayout class='monospaced'> - # Assume a USB mouse and keyboard are connected HAVE_TOUCHSCREEN=0 HAVE_KEYBOARD=1 + + DISPLAY_CAN_ROTATE=0 + DISPLAY_ORIENTATION=0 + DISPLAY_DPI=133 </literallayout> </para> @@ -515,18 +639,6 @@ special requirements for graphics support. All files that are needed for the BSP to support a display are kept here. - For example, the <filename>meta-emenlow</filename> layer, - which supports the eMenlow platform consisting of the - <trademark class='registered'>Intel</trademark> - <trademark class='trade'>Atom</trademark> - Z5xx processor with the - <trademark class='registered'>Intel</trademark> - System Controller Hub US15W, uses these files for supporting - the Video Electronics Standards Association (VESA) graphics: - <literallayout class='monospaced'> - meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend - meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd/xorg.conf - </literallayout> </para> </section> @@ -551,47 +663,63 @@ the <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory). </para> <para> - Suppose you are using the <filename>linux-yocto_3.14.bb</filename> recipe to build + Suppose you are using the <filename>linux-yocto_4.4.bb</filename> recipe to build the kernel. In other words, you have selected the kernel in your <replaceable>bsp_name</replaceable><filename>.conf</filename> file by adding these types of statements: <literallayout class='monospaced'> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" - PREFERRED_VERSION_linux-yocto ?= "3.14%" + PREFERRED_VERSION_linux-yocto ?= "4.4%" </literallayout> <note> When the preferred provider is assumed by default, the <filename>PREFERRED_PROVIDER</filename> statement does not appear in the <replaceable>bsp_name</replaceable><filename>.conf</filename> file. </note> - You would use the <filename>linux-yocto_3.14.bbappend</filename> file to append - specific BSP settings to the kernel, thus configuring the kernel for your particular BSP. + You would use the <filename>linux-yocto_4.4.bbappend</filename> + file to append specific BSP settings to the kernel, thus + configuring the kernel for your particular BSP. </para> + <para> - As an example, look at the existing eMenlow BSP. - The append file used is: + As an example, consider the following append file + used by the BSPs in <filename>meta-yocto-bsp</filename>: <literallayout class='monospaced'> - meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend + meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend </literallayout> The following listing shows the file. - Be aware that the actual commit ID strings in this example listing might be different - than the actual strings in the file from the <filename>meta-intel</filename> - Git source repository. + Be aware that the actual commit ID strings in this + example listing might be different than the actual strings + in the file from the <filename>meta-yocto-bsp</filename> + layer upstream. <literallayout class='monospaced'> - FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" - - COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd" - KMACHINE_emenlow-noemgd = "emenlow" - KBRANCH_emenlow-noemgd = "standard/base" - KERNEL_FEATURES_append_emenlow-noemgd = " features/drm-gma500/drm-gma500.scc" - - LINUX_VERSION_emenlow-noemgd = "3.14.19" - SRCREV_machine_emenlow-noemgd = "902f34d36102a4b2008b776ecae686f80d307e12" - SRCREV_meta_emenlow-noemgd = "28e39741b8b3018334021d981369d3fd61f18f5b" + KBRANCH_genericx86 = "standard/base" + KBRANCH_genericx86-64 = "standard/base" + + KMACHINE_genericx86 ?= "common-pc" + KMACHINE_genericx86-64 ?= "common-pc-64" + KBRANCH_edgerouter = "standard/edgerouter" + KBRANCH_beaglebone = "standard/beaglebone" + KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" + + SRCREV_machine_genericx86 ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2" + SRCREV_machine_genericx86-64 ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2" + SRCREV_machine_edgerouter ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2" + SRCREV_machine_beaglebone ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2" + SRCREV_machine_mpc8315e-rdb ?= "df00877ef9387b38b9601c82db57de2a1b23ce53" + + COMPATIBLE_MACHINE_genericx86 = "genericx86" + COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" + COMPATIBLE_MACHINE_edgerouter = "edgerouter" + COMPATIBLE_MACHINE_beaglebone = "beaglebone" + COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" + + LINUX_VERSION_genericx86 = "4.4.3" + LINUX_VERSION_genericx86-64 = "4.4.3" </literallayout> - This append file contains statements used to support the - eMenlow BSP. + This append file contains statements used to support + several BSPs that ship with the Yocto Project. The file defines machines using the <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink> variable and uses the @@ -602,25 +730,31 @@ The file also uses the optional <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> variable to ensure the build process uses the - <filename>standard/emenlow</filename> kernel branch. - The + appropriate kernel branch. + </para> + + <para> + Although this particular example does not use it, the <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink> - variable enables features specific to the kernel - (e.g. Intel GMA-500 DRM Driver in this case). + variable could be used to enable features specific to + the kernel. The append file points to specific commits in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> Git repository and the <filename>meta</filename> Git repository branches to identify the exact kernel needed to build the - eMenlow BSP. + BSP. </para> <para> - One thing missing in this particular BSP, which you will typically need when - developing a BSP, is the kernel configuration file (<filename>.config</filename>) for your BSP. - When developing a BSP, you probably have a kernel configuration file or a set of kernel - configuration files that, when taken together, define the kernel configuration for your BSP. - You can accomplish this definition by putting the configurations in a file or a set of files - inside a directory located at the same level as your kernel's append file and having the same + One thing missing in this particular BSP, which you will + typically need when developing a BSP, is the kernel configuration + file (<filename>.config</filename>) for your BSP. + When developing a BSP, you probably have a kernel configuration + file or a set of kernel configuration files that, when taken + together, define the kernel configuration for your BSP. + You can accomplish this definition by putting the configurations + in a file or a set of files inside a directory located at the + same level as your kernel's append file and having the same name as the kernel's main recipe file. With all these conditions met, simply reference those files in the <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> @@ -628,37 +762,42 @@ </para> <para> - For example, suppose you had some configuration options in a file called - <filename>network_configs.cfg</filename>. - You can place that file inside a directory named <filename>linux-yocto</filename> and then add - a <filename>SRC_URI</filename> statement such as the following to the append file. - When the OpenEmbedded build system builds the kernel, the configuration options are - picked up and applied. + For example, suppose you had some configuration options + in a file called <filename>network_configs.cfg</filename>. + You can place that file inside a directory named + <filename>linux-yocto</filename> and then add + a <filename>SRC_URI</filename> statement such as the + following to the append file. + When the OpenEmbedded build system builds the kernel, the + configuration options are picked up and applied. <literallayout class='monospaced'> SRC_URI += "file://network_configs.cfg" </literallayout> </para> <para> - To group related configurations into multiple files, you perform a similar procedure. - Here is an example that groups separate configurations specifically for Ethernet and graphics - into their own files and adds the configurations - by using a <filename>SRC_URI</filename> statement like the following in your append file: + To group related configurations into multiple files, you + perform a similar procedure. + Here is an example that groups separate configurations + specifically for Ethernet and graphics into their own + files and adds the configurations by using a + <filename>SRC_URI</filename> statement like the following + in your append file: <literallayout class='monospaced'> SRC_URI += "file://myconfig.cfg \ - file://eth.cfg \ - file://gfx.cfg" + file://eth.cfg \ + file://gfx.cfg" </literallayout> </para> <para> - The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> - variable is in boilerplate form in the - previous example in order to make it easy to do that. - This variable must be in your layer or BitBake will not find the patches or - configurations even if you have them in your <filename>SRC_URI</filename>. - The <filename>FILESEXTRAPATHS</filename> variable enables the build process to - find those configuration files. + Another variable you can use in your kernel recipe append + file is the + <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> + variable. + When you use this statement, you are extending the locations + used by the OpenEmbedded system to look for files and + patches as the recipe is processed. </para> <note> @@ -711,7 +850,7 @@ "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem> <listitem><para>The requirements in this section apply regardless of how you - ultimately package a BSP. + 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 @@ -731,7 +870,7 @@ </para> <para> - Following are the requirements for a released BSP that conforms to the + Following are the requirements for a released BSP that conform to the Yocto Project: <itemizedlist> <listitem><para><emphasis>Layer Name:</emphasis> @@ -777,15 +916,16 @@ You must specify which license to use since there is no default license if one is not specified. See the - <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/COPYING.MIT'><filename>COPYING.MIT</filename></ulink> - file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer - as an example.</para></listitem> + <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/COPYING.MIT'><filename>COPYING.MIT</filename></ulink> + file for the Raspberry Pi BSP in the + <filename>meta-raspberrypi</filename> BSP layer as an example. + </para></listitem> <listitem><para><emphasis>README File:</emphasis> You must include a <filename>README</filename> file in the <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. See the - <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README'><filename>README</filename></ulink> - file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer + <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/README'><filename>README</filename></ulink> + file for the Raspberry Pi BSP in the <filename>meta-raspberrypi</filename> BSP layer as an example.</para> <para>At a minimum, the <filename>README</filename> file should contain the following: @@ -828,10 +968,7 @@ This file specifies exactly where you can find the sources used to generate the binary images contained in the <filename>binary</filename> directory, if present. - See the - <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink> - file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer - as an example.</para></listitem> + </para></listitem> <listitem><para><emphasis>Layer Configuration File:</emphasis> You must include a <filename>conf/layer.conf</filename> in the <filename>meta-<replaceable>bsp_name</replaceable></filename> directory. @@ -1175,13 +1312,14 @@ for that sub-command: <literallayout class='monospaced'> $ yocto-bsp create + ERROR:root:Wrong number of arguments, exiting Usage: Create a new Yocto BSP usage: yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] - [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] + [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] This command creates a Yocto BSP based on the specified parameters. The new BSP will be a new Yocto BSP layer contained by default within @@ -1189,6 +1327,12 @@ can be used to place the BSP layer in a directory with a different name and location. + The value of the 'karch' parameter determines the set of files that + will be generated for the BSP, along with the specific set of + 'properties' that will be used to fill out the BSP-specific portions + of the BSP. The possible values for the 'karch' parameter can be + listed via 'yocto-bsp list karch'. + ... </literallayout> </para> @@ -1203,7 +1347,7 @@ yocto-bsp create - Create a new Yocto BSP SYNOPSIS - yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] + yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] DESCRIPTION @@ -1213,12 +1357,6 @@ 'meta-bsp-name'. The -o option can be used to place the BSP layer in a directory with a different name and location. - The value of the 'karch' parameter determines the set of files - that will be generated for the BSP, along with the specific set of - 'properties' that will be used to fill out the BSP-specific - portions of the BSP. The possible values for the 'karch' parameter - can be listed via 'yocto-bsp list karch'. - ... </literallayout> </para> @@ -1280,13 +1418,13 @@ <literallayout class='monospaced'> $ yocto-bsp list karch Architectures available: - qemu - mips64 powerpc x86_64 + i386 arm + qemu mips - i386 + mips64 </literallayout> </para> @@ -1320,35 +1458,34 @@ $ yocto-bsp create myarm qemu Checking basic git connectivity... Done. + Which qemu architecture would you like to use? [default: i386] - 1) i386 (32-bit) - 2) x86_64 (64-bit) - 3) ARM (32-bit) - 4) PowerPC (32-bit) - 5) MIPS (32-bit) - 6) MIPS64 (64-bit) + 1) i386 (32-bit) + 2) x86_64 (64-bit) + 3) ARM (32-bit) + 4) PowerPC (32-bit) + 5) MIPS (32-bit) + 6) MIPS64 (64-bit) 3 - Would you like to use the default (3.19) kernel? (y/n) [default: y] y + Would you like to use the default (4.1) kernel? (y/n) [default: y] Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] - Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.19.git... + Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-4.1.git... Please choose a machine branch to base your new BSP branch on: [default: standard/base] - 1) standard/arm-versatile-926ejs - 2) standard/base - 3) standard/beagleboard - 4) standard/beaglebone - 5) standard/ck - 6) standard/common-pc - 7) standard/crownbay - 8) standard/edgerouter - 9) standard/fsl-mpc8315e-rdb - 10) standard/mti-malta32 - 11) standard/mti-malta64 - 12) standard/qemuarm64 - 13) standard/qemuppc + 1) standard/arm-versatile-926ejs + 2) standard/base + 3) standard/beagleboard + 4) standard/beaglebone + 5) standard/edgerouter + 6) standard/fsl-mpc8315e-rdb + 7) standard/mti-malta32 + 8) standard/mti-malta64 + 9) standard/qemuarm64 + 10) standard/qemuppc 1 Would you like SMP support? (y/n) [default: y] Does your BSP have a touchscreen? (y/n) [default: n] Does your BSP have a keyboard? (y/n) [default: y] + New qemu BSP created in meta-myarm </literallayout> Take a closer look at the example now: @@ -1358,7 +1495,7 @@ In the example, we use the ARM architecture. </para></listitem> <listitem><para>The script then prompts you for the kernel. - The default 3.19 kernel is acceptable. + The default 4.4 kernel is acceptable. So, the example accepts the default. If you enter 'n', the script prompts you to further enter the kernel you do want to use.</para></listitem> @@ -1399,15 +1536,10 @@ <literallayout class='monospaced'> BBLAYERS = ? " \ /usr/local/src/yocto/meta \ - /usr/local/src/yocto/meta-yocto \ + /usr/local/src/yocto/meta-poky \ /usr/local/src/yocto/meta-yocto-bsp \ /usr/local/src/yocto/meta-myarm \ " - - BBLAYERS_NON_REMOVABLE ?= " \ - /usr/local/src/yocto/meta \ - /usr/local/src/yocto/meta-yocto \ - " </literallayout> Adding the layer to this file allows the build system to build the BSP and the <filename>yocto-kernel</filename> tool to be able to find the layer and @@ -1438,8 +1570,11 @@ <literallayout class='monospaced'> $ yocto-kernel --help Usage: + Modify and list Yocto BSP kernel config items and patches. + usage: yocto-kernel [--version] [--help] COMMAND [ARGS] + Current 'yocto-kernel' commands are: config list List the modifiable set of bare kernel config options for a BSP config add Add or modify bare kernel config options for a BSP @@ -1454,7 +1589,11 @@ feature describe Describe a particular feature feature create Create a new BSP-local feature feature destroy Remove a BSP-local feature + See 'yocto-kernel help COMMAND' for more information on a specific command. + + + Options: --version show program's version number and exit -h, --help show this help message and exit |