diff options
| author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2012-04-02 12:40:19 -0600 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2012-04-03 14:04:58 +0100 |
| commit | 23e85906e0230697188d8d03287720e726c722da (patch) | |
| tree | 1eafa73bcac76c9ea5a430cf7f0e7e08c9ccaca0 /documentation/bsp-guide | |
| parent | 0be0e3b350ce247da338758f79518d2f1d2ec72b (diff) | |
| download | ast2050-yocto-poky-23e85906e0230697188d8d03287720e726c722da.zip ast2050-yocto-poky-23e85906e0230697188d8d03287720e726c722da.tar.gz | |
documentation/bsp-guide/bsp.xml: Edits to the BSP Tools section
I have scrubbed the new section for the BSP Tools. Changes reflect
re-wordings, formatting, etc.
(From yocto-docs rev: c13d5a42665d256c6da6d663611291eef9617f1f)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/bsp-guide')
| -rw-r--r-- | documentation/bsp-guide/bsp.xml | 860 |
1 files changed, 429 insertions, 431 deletions
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index e4a113a..df1a557 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml @@ -754,454 +754,452 @@ You must eventually rebuild the image if you want to remove this restriction. </note> </section> - <section id='yocto-bsp-tools'> - <title>Using the Yocto BSP Tools</title> - <para> - The Yocto Project includes a couple of tools that enable - you to create a BSP from scratch - (<filename>yocto-bsp</filename>) and do basic - configuration and maintenance of the kernel - (<filename>yocto-kernel</filename>) without ever looking at - a Yocto metadata file. - </para> - <para> - The following sections describe each of those tools in - detail, but there are some features common to both that - will be useful to describe before delving into the - details of either. - </para> - <para> - First, a word about how the tools are structured. - Designed to have a 'git-like' command interface, each - tool is structured as a set of sub-commands under a - 'top-level' command. The top-level command - (<filename>yocto-bsp</filename> - or <filename>yocto-kernel</filename>) itself does - nothing but invoke or provide help on the sub-commands - it supports. - </para> - <para> - Secondly, since the tools themselves live in - the <filename>scripts/</filename> subdirectory, in order - to use them, you need to 'source' the environment just - as you would when invoking a build: - <literallayout class='monospaced'> - $ source oe-init-build-env [build_dir] - </literallayout> - </para> - <para> - With that in mind, the most immediately useful function - to describe is the built-in help system common to both - tools. - </para> - <para> - The built-in help system makes it easy to drill down at - any time and remind oneself of the syntax required for - any specific command. - </para> - <para> - Simply entering the name of the command, or the command - along with 'help' will display a list of the available - sub-commands. For example: - </para> - <para> - <literallayout class='monospaced'> - $ 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 - </literallayout> - </para> - <para> - Similarly, entering just the name of a sub-command will - show the detailed usage for that sub-command: - </para> - <para> - <literallayout class='monospaced'> - $ yocto-bsp create - - 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>] - - 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. - - ... - </literallayout> - </para> - <para> - For any sub-command, you can also use the word 'help' - just before the sub-command to get more extensive - documentation on the sub-command: + + <section id='using-the-yocto-projects-bsp-tools'> + <title>Using the Yocto Project's BSP Tools</title> + + <para> + The Yocto Project includes a couple of tools that enable + you to create a <link linkend='bsp-layers'>BSP layer</link> + from scratch and do basic configuration and maintenance + of the kernel without ever looking at a Yocto Project metadata file. + These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>, + respectively. </para> - <para> - <literallayout class='monospaced'> - $ yocto-bsp help create - - NAME - yocto-bsp create - Create a new Yocto BSP - - SYNOPSIS - yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] - [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] - - 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. + + <para> + The following sections describe the common location and help features as well + as details for the <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> + tools. + </para> + + <section id='common-features'> + <title>Common Features</title> + + <para> + Designed to have a command interface somewhat like + <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>, each + tool is structured as a set of sub-commands under a + top-level command. + The top-level command (<filename>yocto-bsp</filename> + or <filename>yocto-kernel</filename>) itself does + nothing but invoke or provide help on the sub-commands + it supports. + </para> + + <para> + Both tools reside in the <filename>scripts/</filename> subdirectory + of the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project + Files</ulink>. + Consequently, to use the scripts, you must <filename>source</filename> the + environment just as you would when invoking a build: + <literallayout class='monospaced'> + $ source oe-init-build-env [build_dir] + </literallayout> + </para> + + <para> + 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 with + <filename>help</filename> to display a list of the available sub-commands. + Here is an example: + <literallayout class='monospaced'> + $ 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 + </literallayout> + </para> + + <para> + Similarly, entering just the name of a sub-command shows the detailed usage + for that sub-command: + <literallayout class='monospaced'> + $ yocto-bsp create + + 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>] + + 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. + + ... + </literallayout> + </para> + + <para> + For any sub-command, you can also use the word 'help' just before the + sub-command to get more extensive documentation: + <literallayout class='monospaced'> + $ yocto-bsp help create + + NAME + yocto-bsp create - Create a new Yocto BSP + + SYNOPSIS + yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>] + [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>] + + 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. + 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 subsquently seen and - modified by the yocto-kernel tool. + NOTE: Once created, you should add your new layer to your + bblayers.conf file in order for it to be subsquently 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. - </literallayout> - </para> - <para> - With the knowledge that there are two - commands, <filename>yocto-bsp</filename> - and <filename>yocto-kernel</filename> and a built-in - help system available for each, it should be relatively - straightforward to discover the commands necessary to - create a BSP and do basic kernel maintainence of that - BSP using the tools. The following sections are - provided, however, in order to serve as a concrete - starting point and to expand on a few points that may - not be immediately obvious or that could use further - explanation. - </para> - <section id='using-yocto-bsp'> - <title>Creating a new BSP using <filename>yocto-bsp</filename></title> - <para> - <filename>yocto-bsp</filename> is a Yocto script that - allows you to create a new Yocto BSP for any - architecture supported Yocto, as well as qemu versions - of the same. The default mode of operation when invoked - from the command-line is to prompt the user for - information needed to generate the BSP. For the current - set of BSPs, the user is prompted 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, touchscreen, or anything - that happens to be configurable and has an associated - input prompt. - </para> - <para> - The <filename>yocto-bsp create</filename> sub-command is - the sub-command you use to create a new BSP. It - requires you to specify a particular architecture to - base the BSP on. You can use the <filename>yocto-bsp - list karch</filename> sub-command to list the - architectures available for BSP creation: - </para> - <para> - Assuming you've sourced the environment, you can invoke - the <filename>yocto-bsp create</filename> command to - create the BSP. The example below uses 'myarm' as the - machine name, and tells it to use the 'qemu' - architecture (the specific qemu machine architecture to - use will be prompted for). You can use the 'yocto-bsp - list karch' command to list the aviailable architectures - for BSP creation: - </para> - <para> - <literallayout class='monospaced'> - $ yocto-bsp list karch - Architectures available: - arm - powerpc - i386 - mips - x86_64 - qemu - </literallayout> - </para> - <para> - For the example output below, we'll use the 'qemu' - architecture, which is a special architecture that is - the only one of the supported architectures that will - prompt you further for a 'real' architecture. In every - other way, it's representative of how creating a BSP for - a 'real' machine would work; the reason we're using it - here as an example is that since it's an emulated - architecture, it's easy for readers to try out - themselves without having any special hardware - requirements. - </para> - <para> - The 'yocto-bsp create' command for the qemu architecture - will display the following prompts along the way to - gather the input required for BSP generation. Each - prompt asks for input, but has a default value [in - brackets]. If you press 'enter' (or any invalid value), - the default value will automatically be used. - </para> - <para> - In the case of the qemu architecture, the first prompt - asks which emulated architecture to use. In this - example, we'll use the 'arm' qemu architecture. - </para> - <para> - It then asks if the default kernel (3.2) is ok, and we - press enter, essentially telling it 'yes'. If we had - entered 'n', we would have been prompted to choose a - different kernel from a list of available kernels (3.0, - 3.2_preempt-rt, etc). - </para> - <para> - Once we've selected the kernel, the next prompt asks - whether we'd like to have a new branch in the Yocto - kernel git repository created especially for this BSP, - or whether we'll just re-use an existing branch. If we - say 'yes', which is the default, the BSP code generated - will create a new branch specifically for the BSP rather - than a common shared branch; this is the branch that any - patches we add later would be committed. The reason - creating a new branch is the default is that typically - new BSPs do require BSP-specific patches and so the BSP - tool assumes that most of time a new branch will be - required. Note that in the current implementation it - doesn't actually matter, since the generated BSPs assume - that patches and configuration live in recipe-space, - which is something that can be done with or without a - dedicated branch. The BSP that's generated, however, - will be different, and this difference will become - significant once 'publish' functionality is implemented. - </para> - <para> - Regardless of which choice we made in the previous step, - we're then given the opportunity to select a particular - machine branch to base our new BSP-specific machine - branch on (or re-use if we elected not to create a new - branch). Because we're generating an arm BSP, we choose - #3 at that prompt to select the arm-versatile branch. - The rest of the prompts are routine, and once all the - questions have been completed, the BSP is generated - along with a message telling you so. The output of the - complete session is shown below: - </para> - <para> - <literallayout class='monospaced'> -$ 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/cedartrail - 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 - </literallayout> - </para> - <para> - Now that we have our BSP created, we need to add it to - our bblayers.conf. This of course is required in order - to build the BSP, but it's also required in order for - the <filename>yocto-kernel</filename> tool to be able to - find the layer and other metadata it needs to operate - on. - <literallayout class='monospaced'> + 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. + </literallayout> + </para> + + <para> + 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. + </para> + </section> + + + <section id='creating-a-new-bsp-layer-using-the-yocto-bsp-script'> + <title>Creating a new BSP Layer Using the yocto-bsp Script</title> + + <para> + The <filename>yocto-bsp</filename> script creates a new + <link linkend='bsp-layers'>BSP layer</link> 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: + <itemizedlist> + <listitem><para>which kernel to use</para></listitem> + <listitem><para>which branch of that kernel to use (or re-use)</para></listitem> + <listitem><para>whether or not to use X, and if so, which drivers to use</para></listitem> + <listitem><para>whether to turn on SMP</para></listitem> + <listitem><para>whether the BSP has a keyboard</para></listitem> + <listitem><para>whether the BSP has a touchscreen</para></listitem> + <listitem><para>any remaining configurable items associated with the BSP</para></listitem> + </itemizedlist> + </para> + + <para> + You use the <filename>yocto-bsp create</filename> 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 the + <filename>yocto-bsp list karch</filename> sub-command to list the + architectures available for BSP creation as follows: + <literallayout class='monospaced'> + $ yocto-bsp list karch + Architectures available: + arm + powerpc + i386 + mips + x86_64 + qemu + </literallayout> + </para> + + <para> + The remainder of this section presents an example that uses + <filename>myarm</filename> as the machine name and <filename>qemu</filename> + as the machine architecture. + Of the available architectures, <filename>qemu</filename> 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. + </para> + + <para> + As the <filename>yocto-bsp create</filename> 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. + </para> + + <para> + Following is the complete example: + <literallayout class='monospaced'> + $ 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 + </literallayout> + Let's take a closer look at the example now: + <orderedlist> + <listitem><para>For the <filename>qemu</filename> architecture, + the script first prompts you for which emulated architecture to use. + In the example, we use the <filename>arm</filename> architecture. + </para></listitem> + <listitem><para>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.).</para></listitem> + <listitem><para>Next, the script asks whether you would like to have a new + branch created especially for your BSPin the local + <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink> + Git repository . + If not, then the script re-uses an existing branch.</para> + <para>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.</note></para></listitem> + <listitem><para>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 <filename>arm</filename> BSP, the example + uses <filename>#3</filename> at the prompt, which selects the arm-versatile branch. + </para></listitem> + <listitem><para>The remainder of the prompts are routine. + Defaults are accepted for each.</para></listitem> + <listitem><para>By default, the script creates the new BSP Layer in the + <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project + Build Directory</ulink>.</para></listitem> + </orderedlist> + </para> + + <para> + Once the BSP Layer is created, you must add it to your + <filename>bblayers.conf</filename> file. + Here is an example: + <literallayout class='monospaced'> BBLAYERS = " \ /usr/local/src/yocto/meta \ /usr/local/src/yocto/meta-yocto \ /usr/local/src/yocto/meta-myarm \ " - </literallayout> - </para> + </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 + other metadata it needs on which to operate. + </para> </section> - <section id='using-yocto-kernel'> - <title>Managing Kernel Patches and Config Items - with <filename>yocto-kernel</filename></title> - <para> - Assuming we've created a Yocto BSP layer - using <filename>yocto-bsp</filename> and added it to our - BBLAYERS, we can now use - the <filename>yocto-kernel</filename> command to add - patches and config items to the BSP's - kernel. <filename>yocto-kernel</filename> is a Yocto - script that allows you to add, remove, and list patches - and kernel config settings to a Yocto BSP's kernel - .bbappend file. The easiest way to see exactly what - sub-commands are available - using <filename>yocto-kernel</filename> is again to make - use of the built-in help: - </para> - <para> - <literallayout class='monospaced'> -$ yocto-kernel -Usage: - Modify and list Yocto BSP kernel config items and patches. + <section id='managing-kernel-patches-and-config-items-with-yocto-kernel'> + <title>Managing Kernel Patches and Config Items with yocto-kernel</title> - usage: yocto-kernel [--version] [--help] COMMAND [ARGS] + <para> + Assuming you have created a Yocto Project + <link linkend='bsp-layers'>BSP Layer</link> using + <link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'> + <filename>yocto-bsp</filename></link> and you added it to your + <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink> + variable in the <filename>bblayers.conf</filename> file, you can now use + the <filename>yocto-kernel</filename> script to add patches and configuration + items to the BSP's kernel. + </para> - 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 + <para> + The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches + and kernel config settings to a Yocto Project BSP's kernel + <filename>.bbappend</filename> 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 <filename>yocto-kernel</filename> built-in help as follows: + <literallayout class='monospaced'> + $ 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. + </literallayout> + </para> - See 'yocto-kernel help COMMAND' for more information on a specific command. - </literallayout> - </para> - <para> - The <filename>yocto-kernel patch add</filename> - sub-command allows us to add a patch to a BSP. The - following commands add a couple of patches to the - 'myarm' BSP: - <literallayout class='monospaced'> -$ yocto-kernel patch add myarm ~/test.patch -Added patches: - test.patch + <para> + The <filename>yocto-kernel patch add</filename> sub-command allows you to add a + patch to a BSP. + The following example adds two patches to the <filename>myarm</filename> BSP: + <literallayout class='monospaced'> + $ yocto-kernel patch add myarm ~/test.patch + Added patches: + test.patch + + $ yocto-kernel patch add myarm ~/yocto-testmod.patch + Added patches: + yocto-testmod.patch + </literallayout> + <note>Although the previous example adds patches one at a time, it is possible + to add multiple patches at the same time.</note> + </para> -$ yocto-kernel patch add myarm ~/yocto-testmod.patch -Added patches: - yocto-testmod.patch - </literallayout> - Note that though we added patches one by one above, we - could also add multiple patches at the same time if we - wanted to. - </para> - <para> - We can verify that the patches were added by using - the <filename>yocto-kernel patch list</filename> - sub-command: - <literallayout class='monospaced'> -$ yocto-kernel patch list myarm -The current set of machine-specific patches for myarm is: - 1) test.patch - 2) yocto-testmod.patch - </literallayout> - </para> - <para> - We can also use <filename>yocto-kernel</filename> to - remove a patch using the <filename>yocto-kernel patch - rm</filename> sub-command: - <literallayout class='monospaced'> -$ yocto-kernel patch rm myarm -Specify the patches to remove: - 1) test.patch - 2) yocto-testmod.patch -1 -Removed patches: - test.patch - </literallayout> - </para> - <para> - Again using <filename>yocto-kernel patch list</filename> - we can verify that it was in fact removed: - <literallayout class='monospaced'> -$ yocto-kernel patch list myarm -The current set of machine-specific patches for myarm is: - 1) yocto-testmod.patch - </literallayout> - </para> - <para> - In a completely similar way, we can use - the <filename>yocto-kernel config add</filename> - sub-command to add one or more kernel config item - settings to a BSP. The following commands add a couple - of config items to the 'myarm' BSP: - <literallayout class='monospaced'> -$ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y -Added items: - CONFIG_MISC_DEVICES=y + <para> + You can verify patches have been added by using the + <filename>yocto-kernel patch list</filename> sub-command. + Here is an example: + <literallayout class='monospaced'> + $ yocto-kernel patch list myarm + The current set of machine-specific patches for myarm is: + 1) test.patch + 2) yocto-testmod.patch + </literallayout> + </para> -$ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y -Added items: - CONFIG_YOCTO_TESTMOD=y - </literallayout> - Note that though we added config items one by one - above, we could also add multiple configuration - settings at the same time if we wanted to. - </para> - <para> - Finally, we can list the config items now associated - with the BSP and see the config items we added along - with some others. - <literallayout class='monospaced'> -$ 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 - </literallayout> - </para> - <para> - Similarly, we can remove one or more config items using - <filename>yocto-kernel config rm</filename> in a manner - completely analogous to <filename>yocto-kernel patch - rm</filename>. - </para> + <para> + You can also use the <filename>yocto-kernel</filename> script to + remove a patch using the <filename>yocto-kernel patch rm</filename> sub-command. + Here is an example: + <literallayout class='monospaced'> + $ yocto-kernel patch rm myarm + Specify the patches to remove: + 1) test.patch + 2) yocto-testmod.patch + 1 + Removed patches: + test.patch + </literallayout> + </para> + + <para> + Again, using the <filename>yocto-kernel patch list</filename> sub-command, + you can verify that the patch was in fact removed: + <literallayout class='monospaced'> + $ yocto-kernel patch list myarm + The current set of machine-specific patches for myarm is: + 1) yocto-testmod.patch + </literallayout> + </para> + + <para> + In a completely similar way, you can use the <filename>yocto-kernel config add</filename> + sub-command to add one or more kernel config item settings to a BSP. + The following commands add a couple of config items to the + <filename>myarm</filename> BSP: + <literallayout class='monospaced'> + $ 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 + </literallayout> + <note>Although the previous example adds config items one at a time, it is possible + to add multiple config items at the same time.</note> + </para> + + <para> + 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: + <literallayout class='monospaced'> + $ 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 + </literallayout> + </para> + + <para> + Finally, you can remove one or more config items using the + <filename>yocto-kernel config rm</filename> sub-command in a manner + completely analogous to <filename>yocto-kernel patch rm</filename>. + </para> </section> </section> </chapter> |
