From 2c7834cae617d75c89192ba65444a2f5c9b00357 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 22 Jul 2011 15:04:43 -0700 Subject: documentation/dev-manual/dev-manual-cases.xml: re-write of BSP example Completed the terminology scrub for the yp files. (From yocto-docs rev: c99f64541bf09ad7267625828894e3364dcdf937) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-cases.xml | 82 ++++++++++++++------------- 1 file changed, 44 insertions(+), 38 deletions(-) (limited to 'documentation') diff --git a/documentation/dev-manual/dev-manual-cases.xml b/documentation/dev-manual/dev-manual-cases.xml index bb8389bc10..610412d166 100644 --- a/documentation/dev-manual/dev-manual-cases.xml +++ b/documentation/dev-manual/dev-manual-cases.xml @@ -97,10 +97,23 @@ contributing back to the Yocto Project. However, if you just want a hierarchical file structure that contains the recipes and metadata that let you develop you can download tarballs from the - download page. + download page. + + + + Regardless of the method you use this manual will refer to the resulting + hierarchical set of files as "the local Yocto Project files." + + + + [WRITER'S NOTE: I need to substitute correct and actual filenames for the + 1.1 release throughout this example once they become available.] + + + If you download a tarball you can extract it into any directory you want using the tar command. - For example, the following command extracts the Yocto Project 1.1_M2 release tarball + For example, the following command extracts the Yocto Project 1.1 release tarball into the current working directory and sets up a file structure whose top-level directory is named poky-1.1: @@ -124,8 +137,8 @@ - Once you have the repository set up you have many development branches from which - you can work. + Once you have the local poky Git repository set up, + you have many development branches from which you can work. From inside the repository you can see the branch names and the tag names used in the Git repository using either of the following two commands: @@ -133,8 +146,8 @@ $ git tag -l For this example we are going to use the Yocto Project 1.1 Release, - which maps to the [NEED BRANCH] branch in the repository. - These commands create a local branch named [NEED BRANCH] + which maps to the 1.1 branch in the repository. + These commands create a local branch named 1.1 that tracks the remote branch of the same name. @@ -142,7 +155,6 @@ $ git checkout -b 1.1 origin/1.1 Switched to a new branch '1.1' - [WRITER'S NOTE: I NEED THE REAL BRANCH NAMES IN THE EXAMPLE.] @@ -181,11 +193,11 @@ You need to have the base BSP layer on your development system. - Like the Yocto Project's poky Git repository you can get the BSP + Like the local Yocto Project files, you can get the BSP layer one of two ways: download the BSP tarball and extract it, or set up a local Git repository that has the Yocto Project BSP layers. - You should use the same method that you used to get the Yocto Project files earlier. + You should use the same method that you used to get the local Yocto Project files earlier. @@ -202,14 +214,14 @@ - If you cloned a Yocto Project Git repository (poky) - then you need to do the same for the - BSP, which is located in Yocto Project's meta-intel Git repository. - The meta-intel repository contains all the metadata + If you cloned a poky Git repository + then you need to set up a different local Git repository + (meta-intel) for the BSP. + The meta-intel Git repository contains all the metadata that supports BSP creation. When you set up the meta-intel Git repository you can set it up anywhere you want. - We will set up the meta-intel Git repository inside the + We will set up the repository inside the poky Git repository in this example. @@ -232,13 +244,12 @@ Because meta-intel is its own Git repository you will want to be sure you are in the appropriate branch for your work. - For this example we are going to use the [NEED BRANCH] branch. + For this example we are going to use the 1.1 branch. $ cd meta-intel $ git checkout -b 1.1 origin/1.1 Switched to a new branch 'bernard' - [WRITER'S NOTE: I NEED THE REAL BRANCH NAMES IN THE EXAMPLE.] @@ -246,7 +257,7 @@ Making a Copy of the Base BSP to Create Your New BSP Layer - Now that you have the Yocto Project and base BSP files you need to create a + Now that you have the local Yocto Project files and the base BSP files you need to create a new layer for your BSP. @@ -267,16 +278,11 @@ Yocto Project release: atom-pc, beagleboard, mpc8315e, and routerstationpro. The recipes and configurations for these four BSPs are located and dispersed - within meta-yocto, which can be found in the - area you unpacked the Yocto Project release tarball or set up your local - poky Git repository. + within local Yocto Project files. Consequently, they are not totally isolated in the spirit of layers unless you think of meta-yocto as a layer itself. - On the other hand, the Yocto Project has isolated BSP layers within - meta-intel Git repository for the Crown Bay, Emenlow, Jasper Forest, - N450, and Sugar Bay. - If you are not using a meta-intel Git repository then you would - downloaded a tarball for one of these isolated BSP layers. + On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, + N450, and Sugar Bay are isolated. @@ -289,8 +295,7 @@ configuration information. You can see the standard layout for the Crown Bay BSP in this example by examining the directory structure of the meta-crownbay layer inside the - meta-intel Git repository or the area where you unpacked the - Crown Bay BSP tarball. + local Yocto Project files. @@ -300,10 +305,11 @@ The name must follow the BSP layer naming convention, which is meta-<name>. The following example assumes your working directory is meta-intel - inside the meta-intel Git repository. + inside the local Yocto Project files. If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting meta-crownbay directory structure to a location of your choice. - Good practice for a Git repository is to just copy the new layer alongside the existing + Good practice for a Git repository, however, is to just copy the new layer alongside + the existing BSP layers in the meta-intel Git repository: $ cp -a meta-crownbay/ meta-mymachine @@ -429,7 +435,7 @@ Now let's look at changes in recipes-core. The file task-core-tools.bbappend in recipes-core/tasks appends the similarly named recipe - located in the poky Git repository at + located in the local Yocto Project files at meta/recipes-core/tasks. The "append" file in our layer right now is Crown Bay-specific and supports EMGD and non-EMGD. @@ -454,13 +460,13 @@ Finally, let's look at recipes-kernel changes. Recall that the BSP uses the linux-yocto kernel as determined earlier in the mymachine.conf. - The recipe for that kernel is located is not located in the - BSP layer but rather in the poky Git repository at + The recipe for that kernel is not located in the + BSP layer but rather in the local Yocto Project files at meta/recipes-kernel/linux and is named linux-yocto-2.6.37.bb. The SRCREV_machine and SRCREV_meta - statements point to the exact commits in the poky Git repository - that identify the right kernel for our hardware. + statements point to the exact commits used by the Yocto Project development team + in their source repositories that identify the right kernel for our hardware. @@ -518,7 +524,8 @@ If you are familiar with Git repositories you probably won’t have trouble locating the - exact commit strings you need to change the SRCREV statements. + exact commit strings in the Yocto Project source repositories you need to change + the SRCREV statements. You can find all the machine and meta branch points (commits) for the linux-yocto-2.6.37 kernel here. @@ -607,9 +614,8 @@ Get the environment ready for the build by sourcing the environment script. - The environment script is in the top-level of the poky - Git repository or the top-level directory in which you unpacked the Yocto Project - release tarball. + The environment script is in the top-level of the local Yocto Project files + directory structure. The script has the string init-build-env in the file’s name. For this example, the following command gets the build environment ready: -- cgit v1.2.3-54-g00ecf