yocto project

学习yocto project 最好的文档，yocto project 官网上的Guide 文档：

https://www.yoctoproject.org/documentation/archived?keys=&field_version_tid=All

The Yocto Project Quick Start

http://www.yoctoproject.org/docs/1.2/yocto-project-qs/yocto-project-qs.html

Ubuntu 需要安装的package:

The packages you need for a supported Ubuntu distribution are shown in the following command:

     $ sudo apt-get install sed wget cvs subversion git-core coreutils \
     unzip texi2html texinfo libsdl1.2-dev docbook-utils fop gawk \
     python-pysqlite2 diffstat help2man make gcc build-essential xsltproc \
     g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
     mercurial autoconf automake groff libtool xterm libxml-parser-perl
                

Initializing the Build Environment

From the parent directory of the Yocto Project Files, initialize your environment and provide a meaningful Yocto Project Build Directory name:

     $ source poky/oe-init-build-env mybuilds
            

At this point, the mybuilds directory has been created for you and it is now your current working directory. If you don't provide your own directory name it defaults to build.

执行 source poky/oe-init-build-env mybuilds 是为了加载bitbake dev shell 环境，第一次初始化好环境，建立了mybuilds 文件夹，之后关闭terminal，再打开terminal 就无法输入bitbake 命令了，这时就需要重新执行

source poky/oe-init-build-env mybuilds 来加载 bitbake dev shell 环境。
bitbake 命令的参数可以直接输入 bitbake --help
bitbake -c -f 参数的意义：
  -f, --force           force run of specified cmd, regardless of stamp status
  -c CMD, --cmd=CMD     Specify task to execute. Note that this only executes
                        the specified task for the providee and the packages
                        it depends on, i.e. 'compile' does not implicitly call
                        stage for the dependencies (IOW: use only if you know
                        what you are doing). Depending on the base.bbclass a
                        listtasks tasks is defined and will show available
                        tasks

Running Specific Tasks

Any given package consists of a set of tasks. The standard BitBake behavior in most cases is:fetch, unpack, patch, configure, compile,install, package, package_write, and build. The default task isbuild and any tasks on which it depends build first. Some tasks exist, such asdevshell, that are not part of the default build chain. If you wish to run a task that is not part of the default build chain, you can use the-c option in BitBake as follows:

     $ bitbake matchbox-desktop -c devshell
            

If you wish to rerun a task, use the -f force option. For example, the following sequence forces recompilation after changing files in the working directory.

     $ bitbake matchbox-desktop
               .
               .
        [make some changes to the source code in the working directory]
               .
               .
     $ bitbake matchbox-desktop -c compile -f
     $ bitbake matchbox-desktop
            

This sequence first builds matchbox-desktop and then recompiles it. The last command reruns all tasks (basically the packaging tasks) after the compile. BitBake recognizes that thecompile task was rerun and therefore understands that the other tasks also need to be run again.

You can view a list of tasks in a given package by running thelisttasks task as follows:

     $ bitbake matchbox-desktop -c listtasks
            

The results are in the file ${WORKDIR}/temp/log.do_listtasks.

Building the Image

At this point, you need to select an image to build for the BeagleBoard xM. If this is your first build using the Yocto Project, you should try the smallest and simplest image:

     $ bitbake core-image-minimal
            

Now you just wait for the build to finish.

Here are some variations on the build process that could be helpful:

• Fetch all the necessary sources without starting the build:

       $ bitbake -c fetchall core-image-minimal
                      

  This variation guarantees that you have all the sources for that BitBake target should you to disconnect from the net and want to do the build later offline.

• Specify to continue the build even if BitBake encounters an error. By default, BitBake aborts the build when it encounters an error. This command keeps a faulty build going:

       $ bitbake -k core-image-minimal
                      

Run QEMU emulator

The final command runs the image:

     $ runqemu qemux86
             

Board Support Packages (BSP) - Developer's Guide

http://www.yoctoproject.org/docs/1.2/yocto-project-qs/yocto-project-qs.html

BSP Layers

The BSP consists of a file structure inside a base directory. Collectively, you can think of the base directory and the file structure as a BSP Layer. BSP Layers use the following naming convention:

     meta-
                

"bsp_name" is a placeholder for the machine or platform name.

The layer's base directory (meta-) is the root of the BSP Layer. This root is what you add to theBBLAYERS variable in the conf/bblayers.conf file found in theYocto Project Build Directory. Adding the root allows the Yocto Project build system to recognize the BSP definition and from it build an image. Here is an example:

     BBLAYERS = " \
        /usr/local/src/yocto/meta \
        /usr/local/src/yocto/meta-yocto \
        /usr/local/src/yocto/meta- \
        "
                

Some BSPs require additional layers on top of the BSP's root layer in order to be functional. For these cases, you also need to add those layers to theBBLAYERS variable in order to build the BSP. You must also specify in the "Dependencies" section of the BSP'sREADME file any requirements for additional layers and, preferably, any build instructions that might be contained elsewhere in theREADME file.

Some layers function as a layer to hold other BSP layers. An example of this type of layers is themeta-intel layer. Themeta-intel layer contains over 10 individual BSP layers.

For more detailed information on layers, see the "Understanding and Creating Layers" section of the Yocto Project Development Manual. You can also see the detailed examples in the appendices of The Yocto Project Development Manual.

Layer Configuration File

You can find this file in the BSP Layer at:

     meta-/conf/layer.conf
                

The conf/layer.conf file identifies the file structure as a Yocto Project layer, identifies the contents of the layer, and contains information about how Yocto Project should use it. Generally, a standard boilerplate file such as the following works. In the following example, you would replace "bsp" and "_bsp" with the actual name of the BSP (i.e. from the example template).

     # We have a conf and classes directory, add to BBPATH
     BBPATH := "${BBPATH}:${LAYERDIR}"

     # We have a recipes directory, add to BBFILES
     BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ 
                 ${LAYERDIR}/recipes/*/*.bbappend"

     BBFILE_COLLECTIONS += "bsp"
     BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
     BBFILE_PRIORITY_bsp = "6"
                

To illustrate the string substitutions, here are the last three statements from the Crown Bayconf/layer.conf file:

     BBFILE_COLLECTIONS += "crownbay"
     BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
     BBFILE_PRIORITY_crownbay = "6"
                

This file simply makes BitBake aware of the recipes and configuration directories. The file must exist so that the Yocto Project build system can recognize the BSP.

Hardware Configuration Options

You can find these files in the BSP Layer at:

     meta-/conf/machine/*.conf
                

The machine files bind together all the information contained elsewhere in the BSP into a format that the Yocto Project build system can understand. If the BSP supports multiple machines, multiple machine configuration files can be present. These filenames correspond to the values to which users have set the MACHINE variable.

These files define things such as the kernel package to use (PREFERRED_PROVIDER of virtual/kernel), the hardware drivers to include in different types of images, any special software components that are needed, any bootloader information, and also any special image format requirements.

Each BSP Layer requires at least one machine file. However, you can supply more than one file. For example, in the Crown Bay BSP shown earlier in this section, theconf/machine directory contains two configuration files:crownbay.conf and crownbay-noemgd.conf. Thecrownbay.conf file is used for the Crown Bay BSP that supports theIntel® Embedded Media and Graphics Driver (Intel® EMGD), while thecrownbay-noemgd.conf file is used for the Crown Bay BSP that does not support theIntel® EMGD.

This crownbay.conf file could also include a hardware "tuning" file that is commonly used to define the package architecture and specify optimization flags, which are carefully chosen to give best performance on a given processor.

Tuning files are found in the meta/conf/machine/include directory of theYocto Project Files. Tuning files can also reside in the BSP Layer itself. For example, theia32-base.inc file resides in themeta-intel BSP Layer inconf/machine/include.

To use an include file, you simply include them in the machine configuration file. For example, the Crown Bay BSPcrownbay.conf has the following statements:

     include conf/machine/include/tune-atom.inc
     include conf/machine/include/ia32-base.inc
                

Linux Kernel Configuration

You can find these files in the BSP Layer at:

     meta-/recipes-kernel/linux/linux-yocto_*.bbappend
                

These files append your specific changes to the kernel you are using.

For your BSP, you typically want to use an existing Yocto Project kernel found in theYocto Project Files atmeta/recipes-kernel/linux. You can append your specific changes to the kernel recipe by using a similarly named append file, which is located in the BSP Layer (e.g. themeta-/recipes-kernel/linux directory).

Suppose the BSP uses the linux-yocto_3.0.bb kernel, which is the preferred kernel to use for developing a new BSP using the Yocto Project.In other words, you have selected the kernel in your.conf file by adding the following statements:

     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
     PREFERRED_VERSION_linux-yocto = "3.0%"
                

You would use the linux-yocto_3.0.bbappend file to append specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.

As an example, look at the existing Crown Bay BSP. The append file used is:

     meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
                

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 themeta-intel Git source repository.

     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

     COMPATIBLE_MACHINE_crownbay = "crownbay"
     KMACHINE_crownbay  = "yocto/standard/crownbay"
     KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"

     COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
     KMACHINE_crownbay-noemgd  = "yocto/standard/crownbay"
     KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"

     SRCREV_machine_pn-linux-yocto_crownbay ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
     SRCREV_meta_pn-linux-yocto_crownbay ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"

     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
                

This append file contains statements used to support the Crown Bay BSP for bothIntel® EMGD and the VESA graphics. The build process, in this case, recognizes and uses only the statements that apply to the defined machine name -crownbay in this case. So, the applicable statements in thelinux-yocto_3.0.bbappend file are follows:

     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

     COMPATIBLE_MACHINE_crownbay = "crownbay"
     KMACHINE_crownbay  = "yocto/standard/crownbay"
     KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"

     SRCREV_machine_pn-linux-yocto_crownbay ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
     SRCREV_meta_pn-linux-yocto_crownbay ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
                

The append file defines crownbay as the compatible machine and defines theKMACHINE. The file also points to some configuration fragments to use by setting theKERNEL_FEATURES variable. The location for the configuration fragments is the kernel tree itself in theYocto Project Build Directory underlinux/meta. Finally, the append file points to the specific commits in theYocto Project Files Git repository and themeta Git repository branches to identify the exact kernel needed to build the Crown Bay BSP.

One thing missing in this particular BSP, which you will typically need when developing a BSP, is the kernel configuration file (.config) 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 append file and having the same name as the kernel. With all these conditions met simply reference those files in aSRC_URI statement in the append file.

For example, suppose you had a set of configuration options in a file called myconfig. If you put that file inside a directory named /linux-yocto and then added a SRC_URI statement such as the following to the append file, those configuration options will be picked up and applied when the kernel is built.

     SRC_URI += "file://myconfig"
                

As mentioned earlier, you can group related configurations into multiple files and name them all in theSRC_URI statement as well. For example, you could group separate configurations specifically for Ethernet and graphics into their own files and add those by using aSRC_URI statement like the following in your append file:

     SRC_URI += "file://myconfig \
            file://eth.cfg \
            file://gfx.cfg"
                

The FILESEXTRAPATHS 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 SRC_URI. The FILESEXTRAPATHS variable enables the build process to find those configuration files.

Note

Other methods exist to accomplish grouping and defining configuration options. For example, if you are working with a local clone of the kernel repository, you could checkout the kernel'smeta branch, make your changes, and then push the changes to the local bare clone of the kernel. The result is that you directly add configuration options to the Yocto kernelmeta branch for your BSP. The configuration options will likely end up in that location anyway if the BSP gets added to the Yocto Project. For an example showing how to change the BSP configuration, see the "Changing the BSP Configuration" section in the Yocto Project Development Manual. For a better understanding of working with a local clone of the kernel repository and a local bare clone of the kernel, see the "Modifying the Kernel Source Code" section also in the Yocto Project Development Manual.

In general, however, the Yocto Project maintainers take care of moving the SRC_URI-specified configuration options to the kernel's meta branch. Not only is it easier for BSP developers to not have to worry about putting those configurations in the branch, but having the maintainers do it allows them to apply 'global' knowledge about the kinds of common configuration options multiple BSPs in the tree are typically using. This allows for promotion of common configurations into common features.

Customizing a Recipe for a BSP

If you plan on customizing a recipe for a particular BSP, you need to do the following:

• Include within the BSP layer a .bbappend file for the modified recipe.

• Place the BSP-specific file in the BSP's recipe .bbappend file path under a directory named after the machine.

To better understand this, consider an example that customizes a recipe by adding a BSP-specific configuration file namedinterfaces to thenetbase_4.47.bb recipe for machine "xyz". Do the following:

1. Edit the netbase_4.47.bbappend file so that it contains the following:

        FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
        PRINC := "${@int(PRINC) + 2}"
                          

2. Create and place the new interfaces configuration file in the BSP's layer here:

        meta-xyz/recipes-core/netbase/files/xyz/interfaces
                          

Using the Yocto Project's BSP Tools

The Yocto Project includes a couple of tools that enable you to create a BSP layer from scratch and do basic configuration and maintenance of the kernel without ever looking at a Yocto Project metadata file. These tools areyocto-bsp andyocto-kernel, respectively.

The following sections describe the common location and help features as well as details for theyocto-bsp andyocto-kernel tools.

Common Features

Designed to have a command interface somewhat like Git, each tool is structured as a set of sub-commands under a top-level command. The top-level command (yocto-bsp oryocto-kernel) itself does nothing but invoke or provide help on the sub-commands it supports.

Both tools reside in the scripts/ subdirectory of theYocto Project Files. Consequently, to use the scripts, you must source the environment just as you would when invoking a build:

     $ source oe-init-build-env [build_dir]
                    

The most immediately useful function is to get help on both tools. The built-in help system makes it easy to drill down at any time and view the syntax required for any specific command. Simply enter the name of the command, or the command along withhelp to display a list of the available sub-commands. Here is an example:

     $ yocto-bsp
     $ yocto-bsp help

     Usage:

     Create a customized Yocto BSP layer.

     usage: yocto-bsp [--version] [--help] COMMAND [ARGS]

     The most commonly used 'yocto-bsp' commands are:
     create            Create a new Yocto BSP
     list              List available values for options and BSP properties

     See 'yocto-bsp 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
     -D, --debug  output debug information
                    

Similarly, entering just the name of a sub-command shows the detailed usage for that sub-command:

     $ yocto-bsp create

     Usage:

     Create a new Yocto BSP
     usage: yocto-bsp create   [-o  | --outdir ]
             [-i  | --infile ]

                 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
                 the top-level directory specified as 'meta-bsp-name'.  The -o option
                 can be used to place the BSP layer in a directory with a different
                 name and location.

                 ...
                    

For any sub-command, you can also use the word 'help' just before the sub-command to get more extensive documentation:

     $ yocto-bsp help create

     NAME
     yocto-bsp create - Create a new Yocto BSP

     SYNOPSIS
     yocto-bsp create   [-o  | --outdir ]
             [-i  | --infile ]

     DESCRIPTION
     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 the top-level directory specified as
     '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.
			    
     ...
			    
     NOTE: Once created, you should add your new layer to your
     bblayers.conf file in order for it to be subsequently seen and
     modified by the yocto-kernel tool.
			    
     NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
     presence of the of the meta-intel layer, so you should also have a
     meta-intel layer present and added to your bblayers.conf as well.
                    

Now that you know where these two commands reside and how to access information on them, you should find it relatively straightforward to discover the commands necessary to create a BSP and perform basic kernel maintainence on that BSP using the tools. The next sections provide a concrete starting point to expand on a few points that might not be immediately obvious or that could use further explanation.

Creating a new BSP Layer Using the yocto-bsp Script

The yocto-bsp script creates a new BSP layer for any architecture supported by the Yocto Project, as well as QEMU versions of the same. The default mode of the script's operation is to prompt you for information needed to generate the BSP layer. For the current set of BSPs, the script prompts you for various important parameters such as:

• which kernel to use

• which branch of that kernel to use (or re-use)

• whether or not to use X, and if so, which drivers to use

• whether to turn on SMP

• whether the BSP has a keyboard

• whether the BSP has a touchscreen

• any remaining configurable items associated with the BSP

You use the yocto-bsp create sub-command to create a new BSP layer. This command requires you to specify a particular architecture on which to base the BSP. Assuming you have sourced the environment, you can use theyocto-bsp list karch sub-command to list the architectures available for BSP creation as follows:

     $ yocto-bsp list karch
     Architectures available:
         arm
         powerpc
         i386
         mips
         x86_64
         qemu
                    

The remainder of this section presents an example that uses myarm as the machine name and qemu as the machine architecture. Of the available architectures,qemu is the only architecture that causes the script to prompt you further for an actual architecture. In every other way, this architecture is representative of how creating a BSP for a 'real' machine would work. The reason the example uses this architecture is because it is an emulated architecture and can easily be followed without requireing actual hardware.

As the yocto-bsp create command runs, default values for the prompts appear in brackets. Pressing enter without supplying anything on the command line or pressing enter and providing an invalid response causes the script to accept the default value.

Following is the complete example:

     $ yocto-bsp create myarm qemu
     Which qemu architecture would you like to use? [default: x86]
             1) common 32-bit x86
             2) common 64-bit x86
             3) common 32-bit ARM
             4) common 32-bit PowerPC
             5) common 32-bit MIPS
     3
     Would you like to use the default (3.2) kernel? (Y/n)
     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n]
     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...
     Please choose a machine branch to base this BSP on => [default: standard/default/common-pc]
             1) base
             2) standard/base
             3) standard/default/arm-versatile-926ejs
             4) standard/default/base
             5) standard/default/beagleboard
             6) standard/default/cedartrailbsp (copy).xml
             7) standard/default/common-pc-64/base
             8) standard/default/common-pc-64/jasperforest
             9) standard/default/common-pc-64/romley
             10) standard/default/common-pc-64/sugarbay
             11) standard/default/common-pc/atom-pc
             12) standard/default/common-pc/base
             13) standard/default/crownbay
             14) standard/default/emenlow
             15) standard/default/fishriver
             16) standard/default/fri2
             17) standard/default/fsl-mpc8315e-rdb
             18) standard/default/mti-malta32-be
             19) standard/default/mti-malta32-le
             20) standard/default/preempt-rt
             21) standard/default/qemu-ppc32
             22) standard/default/routerstationpro
             23) standard/preempt-rt/base
             24) standard/preempt-rt/qemu-ppc32
             25) standard/preempt-rt/routerstationpro
             26) standard/tiny
     3
     Do you need SMP support? (Y/n)
     Does your BSP have a touchscreen? (y/N)
     Does your BSP have a keyboard? (Y/n)
     New qemu BSP created in meta-myarm
                    

Let's take a closer look at the example now:

1. For the qemu architecture, the script first prompts you for which emulated architecture to use. In the example, we use thearm architecture.

2. The script then prompts you for the kernel. The default kernel is 3.2 and 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 (e.g. 3.0, 3.2_preempt-rt, etc.).

3. Next, the script asks whether you would like to have a new branch created especially for your BSPin the localLinux Yocto Kernel Git repository . If not, then the script re-uses an existing branch.

   In this example, the default (or 'yes') is accepted. Thus, a new branch is created for the BSP rather than using a common, shared branch. The new branch is the branch committed to for any patches you might later add. The reason a new branch is the default is that typically new BSPs do require BSP-specific patches. The tool thus assumes that most of time a new branch is required.

   Note

   In the current implementation, creation or re-use of a branch does not actually matter. The reason is because the generated BSPs assume that patches and configurations live in recipe-space, which is something that can be done with or without a dedicated branch. Generated BSPs, however, are different. This difference becomes significant once the tool's 'publish' functionality is implemented.

4. Regardless of which choice is made in the previous step, you are now given the opportunity to select a particular machine branch on which to base your new BSP-specific machine branch on (or to re-use if you had elected to not create a new branch). Because this example is generating an arm BSP, the example uses#3 at the prompt, which selects the arm-versatile branch.

5. The remainder of the prompts are routine. Defaults are accepted for each.

6. By default, the script creates the new BSP Layer in the Yocto Project Build Directory.

Once the BSP Layer is created, you must add it to your bblayers.conf file. Here is an example:

     BBLAYERS = " \
        /usr/local/src/yocto/meta \
        /usr/local/src/yocto/meta-yocto \
        /usr/local/src/yocto/meta-myarm \
        "
                    

Adding the layer to this file allows the build system to build the BSP and theyocto-kernel tool to be able to find the layer and other metadata it needs on which to operate.

Managing Kernel Patches and Config Items with yocto-kernel

Assuming you have created a Yocto Project BSP Layer using yocto-bsp and you added it to your BBLAYERS variable in the bblayers.conf file, you can now use the yocto-kernel script to add patches and configuration items to the BSP's kernel.

The yocto-kernel script allows you to add, remove, and list patches and kernel config settings to a Yocto Project BSP's kernel.bbappend file. All you need to do is use the appropriate sub-command. Recall that the easiest way to see exactly what sub-commands are available is to use the yocto-kernel built-in help as follows:

     $ yocto-kernel
     Usage:

     Modify and list Yocto BSP kernel config items and patches.

     usage: yocto-kernel [--version] [--help] COMMAND [ARGS]

     The most commonly used '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 
     config rm         Remove bare kernel config options from a BSP
     patch list        List the patches associated with a BSP
     patch add         Patch the Yocto kernel for a BSP
     patch rm          Remove patches from a BSP

     See 'yocto-kernel help COMMAND' for more information on a specific command.
                    

The yocto-kernel patch add sub-command allows you to add a patch to a BSP. The following example adds two patches to themyarm BSP:

     $ yocto-kernel patch add myarm ~/test.patch
     Added patches:
             test.patch

     $ yocto-kernel patch add myarm ~/yocto-testmod.patch
     Added patches:
             yocto-testmod.patch
                    

Note

Although the previous example adds patches one at a time, it is possible to add multiple patches at the same time.

You can verify patches have been added by using the yocto-kernel patch list sub-command. Here is an example:

     $ yocto-kernel patch list myarm
     The current set of machine-specific patches for myarm is:
             1) test.patch
             2) yocto-testmod.patch
                    

You can also use the yocto-kernel script to remove a patch using theyocto-kernel patch rm sub-command. Here is an example:

     $ yocto-kernel patch rm myarm
     Specify the patches to remove:
             1) test.patch
             2) yocto-testmod.patch
     1
     Removed patches:
             test.patch
                    

Again, using the yocto-kernel patch list sub-command, you can verify that the patch was in fact removed:

     $ yocto-kernel patch list myarm
     The current set of machine-specific patches for myarm is:
             1) yocto-testmod.patch
                    

In a completely similar way, you can use the yocto-kernel config add sub-command to add one or more kernel config item settings to a BSP. The following commands add a couple of config items to themyarm BSP:

     $ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y
     Added items:
             CONFIG_MISC_DEVICES=y

     $ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y
     Added items:
             CONFIG_YOCTO_TESTMOD=y
                    

Note

Although the previous example adds config items one at a time, it is possible to add multiple config items at the same time.

You can list the config items now associated with the BSP. Doing so shows you the config items you added as well as others associated with the BSP:

     $ yocto-kernel config list myarm
     The current set of machine-specific kernel config items for myarm is:
             1) CONFIG_MISC_DEVICES=y
             2) CONFIG_YOCTO_TESTMOD=y
                    

Finally, you can remove one or more config items using the yocto-kernel config rm sub-command in a manner completely analogous to yocto-kernel patch rm.