<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.
</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
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>
</para>
</section>
-
<section id="bsp-filelayout">
<title>Example Filesystem Layout</title>
</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>
<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>
# 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}/"
<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>
<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>
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>
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>
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
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>
</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>
"<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
</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>
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:
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.
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
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>
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
'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>
<literallayout class='monospaced'>
$ yocto-bsp list karch
Architectures available:
- qemu
- mips64
powerpc
x86_64
+ i386
arm
+ qemu
mips
- i386
+ mips64
</literallayout>
</para>
$ 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.4) 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.4.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/beaglebone
+ 4) standard/edgerouter
+ 5) standard/fsl-mpc8315e-rdb
+ 6) standard/mti-malta32
+ 7) standard/mti-malta64
+ 8) standard/preempt-rt
+ 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:
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>
<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
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
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
