From 23e85906e0230697188d8d03287720e726c722da Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 2 Apr 2012 12:40:19 -0600 Subject: 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 Signed-off-by: Richard Purdie --- documentation/bsp-guide/bsp.xml | 860 ++++++++++++++++++++-------------------- 1 file changed, 429 insertions(+), 431 deletions(-) (limited to 'documentation/bsp-guide') diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index e4a113a3f2..df1a557a5d 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. -
- Using the Yocto BSP Tools - - The Yocto Project includes a couple of tools that enable - you to create a BSP from scratch - (yocto-bsp) and do basic - configuration and maintenance of the kernel - (yocto-kernel) without ever looking at - a Yocto metadata file. - - - 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. - - - 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 - (yocto-bsp - or yocto-kernel) itself does - nothing but invoke or provide help on the sub-commands - it supports. - - - Secondly, since the tools themselves live in - the scripts/ subdirectory, in order - to use them, you need to 'source' the environment just - as you would when invoking a build: - - $ source oe-init-build-env [build_dir] - - - - With that in mind, the most immediately useful function - to describe is the built-in help system common to both - tools. - - - 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. - - - Simply entering the name of the command, or the command - along with 'help' will display a list of the available - sub-commands. For 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 will - show the detailed usage for that sub-command: - - - - $ 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. - - ... - - - - 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: + +
+ 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 are yocto-bsp and yocto-kernel, + respectively. - - - $ 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 following sections describe the common location and help features as well + as details for the yocto-bsp and yocto-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 + or yocto-kernel) itself does + nothing but invoke or provide help on the sub-commands + it supports. + + + + Both tools reside in the scripts/ subdirectory + of the Yocto 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 with + help 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 <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. + + ... + + + + + 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 <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. - - - - With the knowledge that there are two - commands, yocto-bsp - and yocto-kernel 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. - -
- Creating a new BSP using <filename>yocto-bsp</filename> - - yocto-bsp 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. - - - The yocto-bsp create 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 yocto-bsp - list karch sub-command to list the - architectures available for BSP creation: - - - Assuming you've sourced the environment, you can invoke - the yocto-bsp create 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: - - - - $ yocto-bsp list karch - Architectures available: - arm - powerpc - i386 - mips - x86_64 - qemu - - - - 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. - - - 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. - - - 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. - - - 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). - - - 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. - - - 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: - - - -$ 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 - - - - 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 yocto-kernel tool to be able to - find the layer and other metadata it needs to operate - on. - + 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 the + yocto-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: + + For the qemu architecture, + the script first prompts you for which emulated architecture to use. + In the example, we use the arm architecture. + + 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.). + Next, the script asks whether you would like to have a new + branch created especially for your BSPin the local + Linux 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. + 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. + 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. + + The remainder of the prompts are routine. + Defaults are accepted for each. + 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 + the yocto-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 <filename>yocto-kernel</filename> - - Assuming we've created a Yocto BSP layer - using yocto-bsp and added it to our - BBLAYERS, we can now use - the yocto-kernel command to add - patches and config items to the BSP's - kernel. yocto-kernel 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 yocto-kernel is again to make - use of the built-in help: - - - -$ yocto-kernel -Usage: - Modify and list Yocto BSP kernel config items and patches. +
+ Managing Kernel Patches and Config Items with yocto-kernel - usage: yocto-kernel [--version] [--help] COMMAND [ARGS] + + 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 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 + + 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. + + - See 'yocto-kernel help COMMAND' for more information on a specific command. - - - - The yocto-kernel patch add - sub-command allows us to add a patch to a BSP. The - following commands add a couple of patches to the - 'myarm' BSP: - -$ yocto-kernel patch add myarm ~/test.patch -Added patches: - test.patch + + The yocto-kernel patch add sub-command allows you to add a + patch to a BSP. + The following example adds two patches to the myarm 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 + + Although the previous example adds patches one at a time, it is possible + to add multiple patches at the same time. + -$ yocto-kernel patch add myarm ~/yocto-testmod.patch -Added patches: - yocto-testmod.patch - - Note that though we added patches one by one above, we - could also add multiple patches at the same time if we - wanted to. - - - We can verify that the patches were added by using - the yocto-kernel patch list - sub-command: - -$ yocto-kernel patch list myarm -The current set of machine-specific patches for myarm is: - 1) test.patch - 2) yocto-testmod.patch - - - - We can also use yocto-kernel to - remove a patch using the yocto-kernel patch - rm sub-command: - -$ yocto-kernel patch rm myarm -Specify the patches to remove: - 1) test.patch - 2) yocto-testmod.patch -1 -Removed patches: - test.patch - - - - Again using yocto-kernel patch list - we can verify that it 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, we 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 the 'myarm' BSP: - -$ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y -Added items: - CONFIG_MISC_DEVICES=y + + 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 + + -$ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y -Added items: - CONFIG_YOCTO_TESTMOD=y - - 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. - - - Finally, we can list the config items now associated - with the BSP and see the config items we added along - with some others. - -$ 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 - - - - Similarly, we can remove one or more config items using - yocto-kernel config rm in a manner - completely analogous to yocto-kernel patch - rm. - + + You can also use the yocto-kernel script to + remove a patch using the yocto-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 the + myarm 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 + + 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. +
-- cgit v1.2.3-54-g00ecf