Yocto BSP Tools Documentation: Difference between revisions
(Created page with "Note: This documentation is the same as the documentation submitted to the Yocto BSP Developer's Guide. It's here temporarily as a convenience until that document has been offic...") |
No edit summary |
||
Line 1: | Line 1: | ||
Note: This documentation is the same as the documentation submitted to the Yocto BSP Developer's Guide. It's here temporarily as a convenience until that document has been officially published. | Note: This documentation is the same as the documentation submitted to the Yocto BSP Developer's Guide. It's here temporarily as a convenience until that document has been officially published. | ||
=== 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: | |||
trz@elmorro:/usr/local/dev/Yocto/build$ yocto-bsp | |||
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: | |||
trz@elmorro:/usr/local/dev/Yocto/build$ 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. | |||
The value of the 'karch' parameter determines the set of files that | |||
will be generated for the BSP, along with the specific set of | |||
'properties' that will be used to fill out the BSP-specific portions | |||
of the BSP. The possible values for the 'karch' paramter can be | |||
listed via 'yocto-bsp list karch'. | |||
Options: | |||
-h, --help show this help message and exit | |||
-o OUTDIR, --outdir=OUTDIR | |||
name of BSP dir to create | |||
-i PROPERTIES_FILE, --infile=PROPERTIES_FILE | |||
name of file containing the values for BSP properties | |||
as a JSON file | |||
-c, --codedump dump the generated code to bspgen.out | |||
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. |
Revision as of 19:18, 31 March 2012
Note: This documentation is the same as the documentation submitted to the Yocto BSP Developer's Guide. It's here temporarily as a convenience until that document has been officially published.
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:
trz@elmorro:/usr/local/dev/Yocto/build$ yocto-bsp 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:
trz@elmorro:/usr/local/dev/Yocto/build$ 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. The value of the 'karch' parameter determines the set of files that will be generated for the BSP, along with the specific set of 'properties' that will be used to fill out the BSP-specific portions of the BSP. The possible values for the 'karch' paramter can be listed via 'yocto-bsp list karch'. Options: -h, --help show this help message and exit -o OUTDIR, --outdir=OUTDIR name of BSP dir to create -i PROPERTIES_FILE, --infile=PROPERTIES_FILE name of file containing the values for BSP properties as a JSON file -c, --codedump dump the generated code to bspgen.out
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.