Transcript: Using the Yocto BSP tools to create a qemu BSP: Difference between revisions
No edit summary |
No edit summary |
||
Line 353: | Line 353: | ||
trz@elmorro:/usr/local/dev/Yocto$ cd build | trz@elmorro:/usr/local/dev/Yocto$ cd build | ||
trz@elmorro:/usr/local/dev/Yocto/build$ bitbake core-image-sato | trz@elmorro:/usr/local/dev/Yocto/build$ bitbake core-image-sato | ||
Loading cache: 100% |##########################################################| ETA: 00:00:00 | |||
Loaded 1105 entries from dependency cache. | |||
OE Build Configuration: | |||
BB_VERSION = "1.15.1" | |||
TARGET_ARCH = "arm" | |||
TARGET_OS = "linux-gnueabi" | |||
MACHINE = "myqemuarm" | |||
DISTRO = "poky" | |||
DISTRO_VERSION = "1.1+snapshot-20120317" | |||
TUNE_FEATURES = "armv5 dsp thumb arm926ejs" | |||
TARGET_FPU = "soft" | |||
meta | |||
meta-yocto | |||
meta-myqemuarm = "master0:6c6a8f5ce591ee1f2818cbc3e4c5b1d7bb9a33d6" | |||
NOTE: Resolving any missing task queue dependencies | |||
NOTE: Preparing runqueue | |||
NOTE: Executing SetScene Tasks | |||
NOTE: Executing RunQueue Tasks | |||
NOTE: Running task 4513 of 4515 (ID: 8, /usr/local/dev/Yocto/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) | |||
NOTE: package core-image-sato-1.0-r0: task do_rootfs: Started | |||
NOTE: package core-image-sato-1.0-r0: task do_rootfs: Succeeded | |||
NOTE: Running noexec task 4515 of 4515 (ID: 5, /usr/local/dev/Yocto/meta/recipes-sato/images/core-image-sato.bb, do_build) | |||
NOTE: Tasks Summary: Attempted 4515 tasks of which 4513 didn't need to be rerun and all succeeded. |
Revision as of 03:19, 17 March 2012
Here's a cut-and-paste shell session showing how to have the Yocto BSP tools create a new BSP from scratch. It starts with a fresh git checkout, then invokes yocto-bsp to create a new qemu-based ARM BSP, and finally builds a sato image and boots into a sato desktop in a qemu session (commands also shown for that).
NOTE: this transcript was from a build done on a Ubuntu 10.04 system. Please see the 'Yocto Project Quickstart' for the packages required to be installed on the host system for building [1]
One thing to note with this example is that I'm checking out from poky/master.
trz@elmorro:/usr/local/dev$ mkdir Yocto trz@elmorro:/usr/local/dev$ cd Yocto/ trz@elmorro:/usr/local/dev/Yocto$ git init Initialized empty Git repository in /usr/local/dev/Yocto/.git/ trz@elmorro:/usr/local/dev/Yocto$ git remote add yocto git://git.yoctoproject.org/poky.git trz@elmorro:/usr/local/dev/Yocto$ git remote update Fetching yocto remote: Counting objects: 134438, done. remote: Compressing objects: 100% (39702/39702), done. remote: Total 134438 (delta 93915), reused 131102 (delta 91225) Receiving objects: 100% (134438/134438), 75.48 MiB | 1.70 MiB/s, done. Resolving deltas: 100% (93915/93915), done. From git://git.yoctoproject.org/poky * [new branch] 1.1_M1 -> yocto/1.1_M1 * [new branch] 1.1_M2 -> yocto/1.1_M2 * [new branch] 1.1_M3 -> yocto/1.1_M3 * [new branch] 1.1_M4 -> yocto/1.1_M4 * [new branch] 1.2_M1 -> yocto/1.2_M1 * [new branch] 1.2_M2 -> yocto/1.2_M2 * [new branch] 1.2_M3 -> yocto/1.2_M3 * [new branch] bernard -> yocto/bernard * [new branch] blinky -> yocto/blinky * [new branch] clyde -> yocto/clyde * [new branch] edison -> yocto/edison * [new branch] elroy -> yocto/elroy * [new branch] green -> yocto/green * [new branch] laverne -> yocto/laverne * [new branch] master -> yocto/master * [new branch] pinky -> yocto/pinky * [new branch] purple -> yocto/purple * [new tag] 1.1_M1.final -> 1.1_M1.final * [new tag] 1.1_M2.final -> 1.1_M2.final * [new tag] 1.1_M2.rc3 -> 1.1_M2.rc3 * [new tag] 1.1_M3.final -> 1.1_M3.final * [new tag] 1.1_M3.rc3 -> 1.1_M3.rc3 * [new tag] 1.2_M1.final -> 1.2_M1.final * [new tag] 1.2_M1.rc2 -> 1.2_M1.rc2 * [new tag] 1.2_M2.final -> 1.2_M2.final * [new tag] 1.2_M2.rc1 -> 1.2_M2.rc1 * [new tag] 1.2_M3.rc1 -> 1.2_M3.rc1 * [new tag] bernard-5.0.2+docs -> bernard-5.0.2+docs * [new tag] pinky-3.1.2 -> pinky-3.1.2 From git://git.yoctoproject.org/poky * [new tag] 1.1_M1.rc1 -> 1.1_M1.rc1 * [new tag] 1.1_M1.rc2 -> 1.1_M1.rc2 * [new tag] 1.1_M2.rc1 -> 1.1_M2.rc1 * [new tag] 1.1_M2.rc2 -> 1.1_M2.rc2 * [new tag] 1.1_M3.rc2 -> 1.1_M3.rc2 * [new tag] 1.1_M4.rc2+ -> 1.1_M4.rc2+ * [new tag] 1.1_M4.rc3 -> 1.1_M4.rc3 * [new tag] 1.1_M4.rc4 -> 1.1_M4.rc4 * [new tag] 1.2_M1.rc1 -> 1.2_M1.rc1 * [new tag] bernard-1.0rc1 -> bernard-1.0rc1 * [new tag] bernard-5.0 -> bernard-5.0 * [new tag] bernard-5.0-alpha -> bernard-5.0-alpha * [new tag] bernard-5.0.1 -> bernard-5.0.1 * [new tag] bernard-5.0.2 -> bernard-5.0.2 * [new tag] bernard-5.0rc1 -> bernard-5.0rc1 * [new tag] bernard-5.0rc2 -> bernard-5.0rc2 * [new tag] edison-6.0 -> edison-6.0 * [new tag] laverne-4.0 -> laverne-4.0 * [new tag] laverne-4.0.1 -> laverne-4.0.1 * [new tag] m4 -> m4 * [new tag] purple-3.2 -> purple-3.2 * [new tag] purple-3.2.1 -> purple-3.2.1
Now that we've cloned the Yocto repo, we need to source the environment in order to create or build a BSP:
trz@elmorro:/usr/local/dev/Yocto$ source oe-init-build-env You had no conf/local.conf file. This configuration file has therefore been created for you with some default values. You may wish to edit it to use a different MACHINE (target hardware) or enable parallel build options to take advantage of multiple cores for example. See the file for more information as common configuration options are commented. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You had no conf/bblayers.conf file. The configuration file has been created for you with some default values. To add additional metadata layers into your configuration please add entries to this file. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86'
We're now ready to generate a BSP using the 'yocto-bsp' tool. The 'yocto-bsp' tool will step through a series of questions about how the new BSP should be configured. The Yocto BSP tools all have extensive help and usage screens built in, which can be easily displayed at any time to remind yourself of the command syntax and descriptions of what the commands and sub-commands do. The tools have a git-like interface, meaning that there's a top-level command which essentially invokes multiple lower-level subcommands.
To display help for a top-level command, simply invoke the command without any parameters:
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
In order to create a new BSP, we'll want to use the 'yocto-bsp create' command.
To display usage help for a sub-command like 'yocto-bsp create', simply invoke it without any parameters:
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
You can also get more extensive help for a sub-command by adding 'help' before the sub-command name:
trz@elmorro:/usr/local/dev/Yocto/build$ 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 possible values for the 'karch' paramter can be listed via 'yocto-bsp list karch'. The BSP-specific properties that define the values that will be used to generate a particular BSP can be specified on the command-line using the -i option and supplying a JSON object consisting of the set of name:value pairs needed by the BSP. If the -i option is not used, the user will be interactively prompted for each of the required property values, which will then be used as values for BSP generation. The set of properties available for a given architecture can be listed using the 'yocto-bsp list' command. Specifying -c causes the Python code generated and executed to create the BSP to be dumped to the 'bspgen.out' file in the current directory, and is useful for debugging. 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.
The other sub-command of 'yocto-bsp' is 'yocto-bsp list', which we can use to list all of the architectures we can create a BSP for:
trz@elmorro:/usr/local/dev/Yocto/build$ yocto-bsp list karch Architectures available: arm powerpc i386 mips x86_64 qemu
For this BSP, we'll choose the 'qemu' architecture.
To create the BSP we'll invoke 'yocto-bsp create', but first let's change directories out of the 'build' directory (we could stay there, or use the -o option to generate the BSP somewhere else, but for this example we'll just cd into the Yocto dir and generate our BSP there).
We'll call our machine 'myqemuarm'; 'yocto-bsp create' will create our BSP layer in meta-myqemuarm in the current directory:
trz@elmorro:/usr/local/dev/Yocto/build$ cd .. trz@elmorro:/usr/local/dev/Yocto$ yocto-bsp create myqemuarm qemu Which qemu architecture would you like to use? [default: i386] 1) i386 (32-bit)
2) x86_64 (64-bit) 3) ARM (32-bit) 4) PowerPC (32-bit) 5) MIPS (32-bit)
For the 'qemu' architecture, we're given the choice of actual machine architecture. For this BSP, we'll choose ARM by typing in the number in the list labeled as 'ARM':
3 Would you like to use the default (3.2) kernel? (y/n) [default: y]
We're then asked whether we'd like to use the default kernel. If we type 'n' here, we're given a choice of kernels to use. For this BSP, we'll just take the default.
Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2... Please choose a machine branch to base this BSP on: [default: standard/default/arm-versatile-926ejs] 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 Do you need SMP support? (y/n) [default: y] Does your BSP have a touchscreen? (y/n) [default: n] Does your BSP have a keyboard? (y/n) [default: y]
New qemu BSP created in meta-myqemuarm
trz@elmorro:/usr/local/dev/Yocto$ ls -al total 96 drwxr-xr-x 15 trz trz 4096 2012-03-16 20:01 . drwxrwxrwx 7 root root 4096 2012-03-16 18:42 .. drwxr-xr-x 6 trz trz 4096 2012-03-16 18:44 bitbake drwxr-xr-x 3 trz trz 4096 2012-03-16 18:50 build drwxr-xr-x 10 trz trz 4096 2012-03-16 18:44 documentation drwxr-xr-x 8 trz trz 4096 2012-03-16 19:32 .git -rw-r--r-- 1 trz trz 229 2012-03-16 18:44 .gitignore -rw-r--r-- 1 trz trz 545 2012-03-16 18:44 LICENSE drwxr-xr-x 20 trz trz 4096 2012-03-16 18:44 meta drwxr-xr-x 7 trz trz 4096 2012-03-16 18:44 meta-demoapps drwxr-xr-x 4 trz trz 4096 2012-03-16 18:44 meta-hob drwxr-xr-x 16 trz trz 4096 2012-03-16 18:44 meta-intel drwxr-xr-x 8 trz trz 4096 2012-03-16 20:05 meta-myqemuarm drwxr-xr-x 4 trz trz 4096 2012-03-16 18:44 meta-skeleton drwxr-xr-x 9 trz trz 4096 2012-03-16 18:44 meta-yocto -rwxr-xr-x 1 trz trz 1530 2012-03-16 18:44 oe-init-build-env drwxr-xr-x 5 trz trz 4096 2012-03-16 18:44 poky-extras -rw-r--r-- 1 trz trz 1375 2012-03-16 18:44 README -rw-r--r-- 1 trz trz 16494 2012-03-16 18:44 README.hardware drwxr-xr-x 7 trz trz 4096 2012-03-16 18:50 scripts
Add the layer to bblayers.conf:
trz@elmorro:/usr/local/dev/Yocto$ emacs -nw build/conf/bblayers.conf
In order to build or use the other Yocto BSP tools such as 'yocto-kernel', you need to add the new BSP layer to BBLAYERS:
Change:
BBLAYERS ?= " \ /usr/local/dev/Yocto/meta \ /usr/local/dev/Yocto/meta-yocto \ "
To:
BBLAYERS ?= " \ /usr/local/dev/Yocto/meta \ /usr/local/dev/Yocto/meta-yocto \ /usr/local/dev/Yocto/meta-myqemuarm \ "
You also need to edit local.conf set MACHINE machine to your
# This sets the default machine to be qemux86 if no other machine is selected: MACHINE ??= "qemux86"
To:
# This sets the default machine to be qemux86 if no other machine is selected: MACHINE ??= "qemux86"
MACHINE ??= "myqemuarm"
trz@elmorro:/usr/local/dev/Yocto$ cd build trz@elmorro:/usr/local/dev/Yocto/build$ bitbake core-image-sato Loading cache: 100% |##########################################################| ETA: 00:00:00 Loaded 1105 entries from dependency cache. OE Build Configuration: BB_VERSION = "1.15.1" TARGET_ARCH = "arm" TARGET_OS = "linux-gnueabi" MACHINE = "myqemuarm" DISTRO = "poky" DISTRO_VERSION = "1.1+snapshot-20120317" TUNE_FEATURES = "armv5 dsp thumb arm926ejs" TARGET_FPU = "soft" meta meta-yocto meta-myqemuarm = "master0:6c6a8f5ce591ee1f2818cbc3e4c5b1d7bb9a33d6" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Running task 4513 of 4515 (ID: 8, /usr/local/dev/Yocto/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) NOTE: package core-image-sato-1.0-r0: task do_rootfs: Started NOTE: package core-image-sato-1.0-r0: task do_rootfs: Succeeded NOTE: Running noexec task 4515 of 4515 (ID: 5, /usr/local/dev/Yocto/meta/recipes-sato/images/core-image-sato.bb, do_build) NOTE: Tasks Summary: Attempted 4515 tasks of which 4513 didn't need to be rerun and all succeeded.