From aa3a201629c7e40341f53d4be57b6e4223a845c8 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 9 Mar 2012 13:40:39 -0600 Subject: [PATCH] documentation/dev-manual: Converted to use poky.ent I converted the hard links to use the variables as established in the file poky.ent. Also, Cleaned up some bad text in the term "Yocto Project Files." Looks like a cut-and-paste problem. (From yocto-docs rev: e2e20bf4895d80dae73595e93132f37fb31121d1) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-bsp-appendix.xml | 43 ++--- .../dev-manual/dev-manual-common-tasks.xml | 177 +++++++++--------- documentation/dev-manual/dev-manual-intro.xml | 33 ++-- .../dev-manual/dev-manual-kernel-appendix.xml | 34 ++-- documentation/dev-manual/dev-manual-model.xml | 77 ++++---- .../dev-manual/dev-manual-newbie.xml | 127 ++++++------- documentation/dev-manual/dev-manual-start.xml | 53 +++--- documentation/dev-manual/dev-manual.xml | 9 +- 8 files changed, 280 insertions(+), 273 deletions(-) diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml index f9c4383567..035549431f 100644 --- a/documentation/dev-manual/dev-manual-bsp-appendix.xml +++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml @@ -1,5 +1,6 @@ +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %poky; ] > @@ -45,10 +46,10 @@ Alternatively, you can start with the downloaded Poky "edison" tarball. These commands unpack the tarball into a Yocto Project File directory structure. By default, the top-level directory of the file structure is named - poky-edison-6.0: + poky-&YOCTO_POKY;: - $ tar xfj poky-edison-6.0.tar.bz2 - $ cd poky-edison-6.0 + $ tar xfj &YOCTO_POKY_TARBALL; + $ cd &YOCTO_POKY; If you're using the tarball method, you can ignore all the following steps that ask you to carry out Git operations. @@ -85,24 +86,24 @@ $ git branch -a $ git tag -l - For this example, we are going to use the Yocto Project 1.1 Release, which is code - named "edison". + For this example, we are going to use the Yocto Project &DISTRO; Release, which is code + named "&DISTRO_NAME;". To make sure we have a local area (branch in Git terms) on our machine that - reflects the 1.1 release, we can use the following commands: + reflects the &DISTRO; release, we can use the following commands: $ cd ~/poky $ git fetch --tags - $ git checkout edison-6.0 -b edison - Switched to a new branch 'edison' + $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME; + Switched to a new branch '&DISTRO_NAME;' The git fetch --tags is somewhat redundant since you just set up the repository and should have all the tags. The fetch command makes sure all the tags are available in your local repository. The Git checkout command with the -b option - creates a local branch for you named edison. - Your local branch begins in the same state as the Yocto Project 1.1 released tarball - marked with the edison-6.0 tag in the source repositories. + creates a local branch for you named &DISTRO_NAME;. + Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball + marked with the &DISTRO_NAME;-&POKYVERSION; tag in the source repositories. @@ -160,14 +161,14 @@ Alternatively, you can start with the downloaded Crown Bay tarball. You can download the edison version of the BSP tarball from the - Download page of the + Download page of the Yocto Project website. Here is the specific link for the tarball needed for this example: - . + . Again, be sure that you are already in the poky directory as described previously before installing the tarball: - $ tar xfj crownbay-noemgd-edison-6.0.0.tar.bz2 + $ tar xfj crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2 $ cd meta-intel @@ -181,10 +182,10 @@ skip to the next step. 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 edison branch. + For this example we are going to use the &DISTRO_NAME; branch. - $ git checkout -b edison origin/edison - Switched to a new branch 'edison' + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Switched to a new branch '&DISTRO_NAME;' @@ -271,7 +272,7 @@ meta-mymachine/conf/layer.conf. This file identifies build information needed for the new layer. You can see the - "Layer Configuration File" section + "Layer Configuration File" section in The Board Support Packages (BSP) Development Guide for more information on this configuration file. Basically, we are changing the existing statements to work with our BSP. @@ -483,7 +484,7 @@ the SRCREV statements. You can find all the machine and meta branch points (commits) for the linux-yocto-3.0 kernel at - . + . @@ -610,7 +611,7 @@ The appendix - + Reference: Variables Glossary in the Yocto Project Reference Manual has more information on configuration variables. diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 4702ae94e3..74375c89bf 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -1,5 +1,6 @@ +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %poky; ] > @@ -60,8 +61,8 @@ and then explore that folder, you will discover many BSP layers within the meta-intel layer. For more information on BSP layers, see the - "BSP Layers" - section in the Yocto Project Development Manual. + "BSP Layers" + section in the Yocto Project Board Support Package (BSP) Developer's Guide. @@ -76,7 +77,7 @@ you should be sure someone has not already created a layer containing the metadata you need. You can see the - LayerIndex + LayerIndex for a list of layers from the OpenEmbedded community that can be used in the Yocto Project. Create a Directory: Create the directory @@ -108,24 +109,24 @@ BBFILE_PRIORITY_yocto = "5" In the previous example, the recipes for the layers are added to - BBFILES. + BBFILES. The - BBFILE_COLLECTIONS + BBFILE_COLLECTIONS variable is then appended with the layer name. The - BBFILE_PATTERN + BBFILE_PATTERN variable is set to a regular expression and is used to match files from BBFILES into a particular layer. In this case, immediate expansion of - LAYERDIR + LAYERDIR sets BBFILES_PATTERN to the layer's path. The - BBFILE_PRIORITY + BBFILE_PRIORITY variable then assigns a priority to the layer. Applying priorities is useful in situations where the same package might appear in multiple layers and allows you to choose what layer should take precedence. Note the use of the - LAYERDIR + LAYERDIR variable with the immediate expansion operator. The LAYERDIR variable expands to the directory of the current layer and requires the immediate expansion operator so that BitBake does not wait to expand the variable @@ -199,7 +200,7 @@ Before the Yocto Project build system can use your new layer, you need to enable it. To enable your layer, simply add your layer's path to the - BBLAYERS + BBLAYERS variable in your conf/bblayers.conf file, which is found in the Yocto Project Build Directory. The following example shows how to enable a layer named meta-mylayer: @@ -290,12 +291,12 @@ PRINC = "1" This example adds or overrides files in - SRC_URI + SRC_URI within a bbappend by extending the path BitBake uses to search for files. The most reliable way to do this is by prepending the FILESEXTRAPATHS variable. For example, if you have your files in a directory that is named the same as your package - (PN), + (PN), you can add this directory by adding the following to your bbappend file: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" @@ -328,7 +329,7 @@ To specify the layer's priority manually, use the - BBFILE_PRIORITY + BBFILE_PRIORITY variable. For example: @@ -338,7 +339,7 @@ It is possible for a recipe with a lower version number - PV + PV in a layer that has a higher priority to take precedence. Also, the layer priority does not currently affect the precedence order of .conf or .bbclass files. @@ -409,7 +410,8 @@ variables. For information on variables that are useful for recipes and for information about recipe naming issues, see the - "Required" section of the Yocto Project Reference Manual. + "Required" + section of the Yocto Project Reference Manual. @@ -434,12 +436,14 @@ Building an application from a single file that is stored locally (e.g. under files/) requires a recipe that has the file listed in the - SRC_URI variable. + SRC_URI + variable. Additionally, you need to manually write the do_compile and do_install tasks. - The S variable defines the + The S + variable defines the directory containing the source code, which is set to - + WORKDIR in this case - the directory BitBake uses for the build. DESCRIPTION = "Simple helloworld application" @@ -477,7 +481,7 @@ Applications that use Autotools such as autoconf and automake require a recipe that has a source archive listed in - SRC_URI and + SRC_URI and also inherits Autotools, which instructs BitBake to use the autotools.bbclass file, which contains the definitions of all the steps needed to build an Autotool-based application. @@ -500,9 +504,9 @@ The variable - LIC_FILES_CHKSUM + LIC_FILES_CHKSUM is used to track source license changes as described in the - "Track License Change" section. + "Track License Change" section. You can quickly create Autotool-based recipes in a manner similar to the previous example. @@ -512,11 +516,13 @@ Applications that use GNU make also require a recipe that has - the source archive listed in SRC_URI. + the source archive listed in + SRC_URI. You do not need to add a do_compile step since by default BitBake starts the make command to compile the application. If you need additional make options you should store them in the - EXTRA_OEMAKE variable. + EXTRA_OEMAKE + variable. BitBake passes these options into the make GNU invocation. Note that a do_install task is still required. Otherwise BitBake runs an empty do_install task by default. @@ -526,7 +532,7 @@ Some applications might require extra parameters to be passed to the compiler. For example, the application might need an additional header path. You can accomplish this by adding to the - CFLAGS variable. + CFLAGS variable. The following example shows this: CFLAGS_prepend = "-I ${S}/include " @@ -568,9 +574,9 @@ You can use the variables - PACKAGES and - FILES to split an application into - multiple packages. + PACKAGES and + FILES + to split an application into multiple packages. @@ -600,17 +606,17 @@ In the previous example, we want to ship the sxpm and cxpm binaries in separate packages. Since bindir would be packaged into the main - PN + PN package by default, we prepend the - PACKAGES + PACKAGES variable so additional package names are added to the start of list. This results in the extra - FILES_* + FILES_* variables then containing information that define which files and directories go into which packages. Files included by earlier packages are skipped by latter packages. Thus, the main - PN package + PN package does not include the above listed files. @@ -677,7 +683,7 @@ PACKAGENAME as the name of the package you want to attach to the postinst script. Normally - PN + PN can be used, which automatically expands to PACKAGENAME. A post-installation function has the following structure: @@ -716,7 +722,7 @@ The previous example delays execution until the image boots again because the - D + D variable points to the directory containing the image when the root filesystem is created at build time but is unset when executed on the first boot. @@ -749,7 +755,8 @@ By creating a custom image, a developer has total control over the contents of the image. It is important to use the correct names of packages in the - IMAGE_INSTALL variable. + IMAGE_INSTALL + variable. You must use the OpenEmbedded notation and not the Debian notation for the names (e.g. eglibc-dev instead of libc6-dev). @@ -775,13 +782,13 @@ A good example of a tasks package is meta/recipes-sato/tasks/task-poky.bb. The - PACKAGES + PACKAGES variable lists the task packages to build along with the complementary -dbg and -dev packages. For each package added, you can use - RDEPENDS + RDEPENDS and - RRECOMMENDS + RRECOMMENDS entries to provide a list of packages the parent task package should contain. Following is an example: @@ -819,7 +826,7 @@ To build an image using these task packages, you need to add task-custom-apps and/or task-custom-tools to - IMAGE_INSTALL. + IMAGE_INSTALL. For other forms of image dependencies see the other areas of this section. @@ -831,7 +838,7 @@ Ultimately users might want to add extra image features to the set used by Yocto Project with the - IMAGE_FEATURES + IMAGE_FEATURES variable. To create these features, the best reference is meta/classes/core-image.bbclass, which shows how the @@ -840,12 +847,12 @@ IMAGE_FEATURES variable and then maps that into a set of tasks or packages. Based on this information the - IMAGE_INSTALL + IMAGE_INSTALL variable is generated automatically. Users can add extra features by extending the class or creating a custom class for use with specialized image .bb files. You can also add more features by configuring the - EXTRA_IMAGE_FEATURES + EXTRA_IMAGE_FEATURES variable in the local.conf file found in the Yocto Project files located in the build directory. @@ -882,7 +889,7 @@ The simplest way to add extra packages to all images is by using the - IMAGE_INSTALL + IMAGE_INSTALL variable with the _append operator: IMAGE_INSTALL_append = " strace" @@ -917,7 +924,7 @@ You can add packages using a similar approach through the - POKY_EXTRA_INSTALL + POKY_EXTRA_INSTALL variable. If you use this variable, only core-image-* images are affected. @@ -930,7 +937,7 @@ It is possible to filter or mask out recipe and recipe append files such that BitBake ignores them. You can do this by providing an expression with the - BBMASK + BBMASK variable. Here is an example: @@ -1006,7 +1013,7 @@ so that there are some definite steps on how to do this. I need more detail her For a complete example that shows how to add a new machine to the Yocto Project, see the - "BSP Development Example" + "BSP Development Example" in Appendix A. @@ -1022,11 +1029,11 @@ so that there are some definite steps on how to do this. I need more detail her The most important variables to set in this file are as follows: - + TARGET_ARCH (e.g. "arm") - + PREFERRED_PROVIDER_virtual/kernel (see below) - + MACHINE_FEATURES (e.g. "kernel26 apm screen wifi") @@ -1034,11 +1041,11 @@ so that there are some definite steps on how to do this. I need more detail her You might also need these variables: - + SERIAL_CONSOLE (e.g. "115200 ttyS0") - + KERNEL_IMAGETYPE (e.g. "zImage") - + IMAGE_FSTYPES (e.g. "tar.gz jffs2") @@ -1065,9 +1072,9 @@ so that there are some definite steps on how to do this. I need more detail her If you are creating a new recipe, normal recipe-writing rules apply for setting up a - SRC_URI. + SRC_URI. Thus, you need to specify any necessary patches and set - S to point at the source code. + S to point at the source code. You need to create a configure task that configures the unpacked kernel with a defconfig. You can do this by using a make defconfig command or, @@ -1085,7 +1092,7 @@ so that there are some definite steps on how to do this. I need more detail her used for other machines in a given kernel. A possible way to do this is by listing the file in the SRC_URI and adding the machine to the expression in - COMPATIBLE_MACHINE: + COMPATIBLE_MACHINE: COMPATIBLE_MACHINE = '(qemux86|qemumips)' @@ -1159,7 +1166,7 @@ so that there are some definite steps on how to do this. I need more detail her During a build, the unpacked temporary source code used by recipes to build packages is available in the Yocto Project Build Directory as defined by the - S variable. + S variable. Below is the default value for the S variable as defined in the meta/conf/bitbake.conf configuration file in the Yocto Project Files: @@ -1180,7 +1187,7 @@ so that there are some definite steps on how to do this. I need more detail her The path to the work directory for the recipe - (WORKDIR) depends + (WORKDIR) depends on the package name and the architecture of the target device. For example, here is the work directory for packages whose targets are not device-dependent: @@ -1212,15 +1219,15 @@ so that there are some definite steps on how to do this. I need more detail her To better understand how the Yocto Project build system resolves directories during the build process, see the glossary entries for the - WORKDIR, - TMPDIR, - TOPDIR, - PACKAGE_ARCH, - TARGET_OS, - PN, - PV, + WORKDIR, + TMPDIR, + TOPDIR, + PACKAGE_ARCH, + TARGET_OS, + PN, + PV, and - PR + PR variables in the Yocto Project Reference Manual. @@ -1255,7 +1262,7 @@ so that there are some definite steps on how to do this. I need more detail her Change Your Working Directory: You need to be in the directory that has the temporary source code. That directory is defined by the - S + S variable. Create a New Patch: Before modifying source code, you need to create a new patch. @@ -1287,7 +1294,7 @@ so that there are some definite steps on how to do this. I need more detail her -c cleanall with BitBake for the package. Modifications will also disappear if you use the rm_work feature as described in the - "Building an Image" + "Building an Image" section of the Yocto Project Quick Start. Generate the Patch: @@ -1307,7 +1314,7 @@ so that there are some definite steps on how to do this. I need more detail her Placing the patch here guarantees that the Yocto Project build system will find the patch. Next, add the patch into the - SRC_URI + SRC_URI of the recipe. Here is an example: @@ -1315,7 +1322,7 @@ so that there are some definite steps on how to do this. I need more detail her Increment the Package Revision Number: Finally, don't forget to 'bump' the - PR + PR value in the same recipe since the resulting packages have changed. @@ -1351,7 +1358,7 @@ so that there are some definite steps on how to do this. I need more detail her Change Your Working Directory: You need to be in the directory that has the temporary source code. That directory is defined by the - S + S variable. Initialize a Git Repository: Use the git init command to initialize a new local repository @@ -1390,7 +1397,7 @@ so that there are some definite steps on how to do this. I need more detail her -c cleanall with BitBake for the package. Modifications will also disappear if you use the rm_work feature as described in the - "Building an Image" + "Building an Image" section of the Yocto Project Quick Start. See the List of Files You Changed: @@ -1435,7 +1442,7 @@ so that there are some definite steps on how to do this. I need more detail her Placing the patch here guarantees that the Yocto Project build system will find the patch. Next, add the patch into the - SRC_URI + SRC_URI of the recipe. Here is an example: @@ -1443,7 +1450,7 @@ so that there are some definite steps on how to do this. I need more detail her Increment the Package Revision Number: Finally, don't forget to 'bump' the - PR + PR value in the same recipe since the resulting packages have changed. @@ -1481,7 +1488,7 @@ so that there are some definite steps on how to do this. I need more detail her This section overviews the Multilib process only. For more details on how to implement Multilib, see the - Multilib wiki + Multilib wiki page. @@ -1630,7 +1637,7 @@ so that there are some definite steps on how to do this. I need more detail her For concepts on kernel configuration, see the - "Kernel Configuration" + "Kernel Configuration" section in the Yocto Project Kernel Architecture and Use Manual. @@ -1804,7 +1811,7 @@ so that there are some definite steps on how to do this. I need more detail her If a committed change results in changing the package output, then the value of the - PR + PR variable needs to be increased (or "bumped") as part of that commit. This means that for new recipes you must be sure to add the PR @@ -1817,7 +1824,7 @@ so that there are some definite steps on how to do this. I need more detail her If you are sharing a common .inc file with multiple recipes, you can also use the - INC_PR + INC_PR variable to ensure that the recipes sharing the .inc file are rebuilt when the .inc file itself is changed. @@ -1830,7 +1837,7 @@ so that there are some definite steps on how to do this. I need more detail her When upgrading the version of a package, assuming the - PV + PV changes, the PR variable should be reset to "r0" (or "$(INC_PR).0" if you are using INC_PR). @@ -1839,7 +1846,7 @@ so that there are some definite steps on how to do this. I need more detail her Usually, version increases occur only to packages. However, if for some reason PV changes but does not increase, you can increase the - PE + PE variable (Package Epoch). The PE variable defaults to "0". @@ -1876,7 +1883,7 @@ so that there are some definite steps on how to do this. I need more detail her If the package exists under a different name in a different distribution, you get a distro_check mismatch. You can resolve this problem by defining a per-distro recipe name alias using the - DISTRO_PN_ALIAS + DISTRO_PN_ALIAS variable. @@ -1928,16 +1935,16 @@ so that there are some definite steps on how to do this. I need more detail her In this case, you want a kernel source directory on the development machine where the development occurs. You want the recipe's - SRC_URI + SRC_URI variable to point to the external directory and use it as is, not copy it. To build from software that comes from an external source, all you need to do is change your recipe so that it inherits the - externalsrc.bbclass + externalsrc.bbclass class and then sets the - S + S variable to point to your external source code. Here are the statements to put in your recipe: @@ -1949,11 +1956,11 @@ so that there are some definite steps on how to do this. I need more detail her It is important to know that the externalsrc.bbclass assumes that the source directory S and the build directory - B + B are different even though by default these directories are the same. This assumption is important because it supports building different variants of the recipe by using the - BBCLASSEXTEND + BBCLASSEXTEND variable. You could allow the build directory to be the same as the source directory but you would not be able to build more than one variant of the recipe. diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manual/dev-manual-intro.xml index b70d384749..02769fb84b 100644 --- a/documentation/dev-manual/dev-manual-intro.xml +++ b/documentation/dev-manual/dev-manual-intro.xml @@ -1,5 +1,6 @@ +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %poky; ] > @@ -69,7 +70,7 @@ Reference material. This type of material resides in an appropriate reference manual. For example, system variables are documented in the - + Yocto Project Reference Manual. Detailed public information that is not specific to the Yocto Project. For example, exhaustive information on how to use Git is covered better through the @@ -86,31 +87,31 @@ need to supplement it with other information. The following list presents other sources of information you might find helpful: - The Yocto Project Website: + The Yocto Project Website: The home page for the Yocto Project provides lots of information on the project as well as links to software and documentation. - + The Yocto Project Quick Start: This short document lets you get started with the Yocto Project quickly and start building an image. - + The Yocto Project Reference Manual: This manual is a reference guide to the Yocto Project build component known as "Poky." The manual also contains a reference chapter on Board Support Package (BSP) layout. - + The Yocto Project Application Development Toolkit (ADT) User's Guide: This guide provides information that lets you get going with the ADT to develop projects using the Yocto Project. - + The Yocto Project Board Support Package (BSP) Developer's Guide: This guide defines the structure for BSP components. Having a commonly understood structure encourages standardization. - + The Yocto Project Kernel Architecture and Use Manual: This manual describes the architecture of the Yocto Project kernel and provides some work flow examples. @@ -120,14 +121,14 @@ demonstrates how an application developer uses Yocto Plug-in features within the Eclipse IDE. - FAQ: + FAQ: A list of commonly asked questions and their answers. - + Release Notes: Features, updates and known issues for the current release of the Yocto Project. - Bugzilla: + Bugzilla: The bug tracking application the Yocto Project uses. If you find problems with the Yocto Project, you should report them using this application. @@ -135,11 +136,11 @@ Yocto Project Mailing Lists: To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions: - for a + for a Yocto Project Discussions mailing list. - for a + for a Yocto Project Discussions mailing list about the Poky build system. - + for a mailing list to receive offical Yocto Project announcements for developments and as well as Yocto Project milestones. @@ -148,7 +149,7 @@ for Yocto Project and Poky discussions: #yocto and #poky. - OpenedHand: + OpenedHand: The company where the Yocto Project build system Poky was first developed. OpenedHand has since been acquired by Intel Corporation. @@ -156,7 +157,7 @@ The company that acquired OpenedHand in 2008 and continues development on the Yocto Project. - OpenEmbedded: + OpenEmbedded: The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives from and to which it contributes. diff --git a/documentation/dev-manual/dev-manual-kernel-appendix.xml b/documentation/dev-manual/dev-manual-kernel-appendix.xml index 0836fe9335..58f33e8ef3 100644 --- a/documentation/dev-manual/dev-manual-kernel-appendix.xml +++ b/documentation/dev-manual/dev-manual-kernel-appendix.xml @@ -1,5 +1,6 @@ +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %poky; ] > @@ -43,10 +44,15 @@ structures you need. Briefly, you need the following: - A local Yocto Project files Git repository - The poky-extras Git repository placed - within the local Yocto Project files Git repository - A bare clone of the Linux Yocto kernel upstream Git + A local + Yocto Project Files + Git repository + The + poky-extras + Git repository placed within the local Yocto Project files Git + repository + A bare clone of the + Linux Yocto Kernel upstream Git repository to which you want to push your modifications. A copy of that bare clone in which you make your source @@ -154,9 +160,9 @@ The following commands create and checkout the local edison branch: - $ git checkout -b edison origin/edison - Branch edison set up to track remote branch edison from origin. - Switched to a new branch 'edison' + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Branch edison set up to track remote branch &DISTRO_NAME; from origin. + Switched to a new branch '&DISTRO_NAME;' @@ -539,14 +545,14 @@ $ git branch -a $ git tag -l - This example uses the Yocto Project 1.1.1 Release code named "edison", - which maps to the edison branch in the repository. - The following commands create and checkout the local edison + This example uses the Yocto Project 1.1.1 Release code named "&DISTRO_NAME;", + which maps to the &DISTRO_NAME; branch in the repository. + The following commands create and checkout the local &DISTRO_NAME; branch: - $ git checkout -b edison origin/edison - Branch edison set up to track remote branch edison from origin. - Switched to a new branch 'edison' + $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; + Branch edison set up to track remote branch &DISTRO_NAME; from origin. + Switched to a new branch '&DISTRO_NAME;' diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml index 9be8673244..46adc97863 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -1,5 +1,6 @@ +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %poky; ] > @@ -24,7 +25,7 @@ For a user-space application development example that uses the Eclipse IDE, see the - + The Yocto Project Application Development Toolkit (ADT) User's Guide. @@ -79,8 +80,9 @@ Set up your host development system to support development using the Yocto Project: See the - "The Linux Distributions" and the - "The Packages" sections both + "The Linux Distributions" + and the + "The Packages" sections both in the Yocto Project Quick Start for requirements. Establish a local copy of the Yocto Project files on your system: You need to have the Yocto Project files available on your host system. @@ -112,7 +114,7 @@ Embedded Media Graphics Driver (EMGD). The remainder of this example uses that base BSP. To see the supported BSPs, go to the Yocto Project - download page and click + download page and click on “BSP Downloads.” Create your own BSP layer: Layers are ideal for isolating and storing work for a given piece of hardware. @@ -137,16 +139,17 @@ N450, and Sugar Bay are isolated. When you set up a layer for a new BSP, you should follow a standard layout. This layout is described in the section - "Example Filesystem Layout" section of the Board Support Package (BSP) Development Guide. + "Example Filesystem Layout" + section of the Board Support Package (BSP) Development Guide. In the standard layout, you will notice a suggested structure for recipes and 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 local Yocto Project files. Make configuration changes to your new BSP - layer: The standard BSP layer structure organizes the files you need to edit in - conf and several recipes-* directories within the - BSP layer. + layer: The standard BSP layer structure organizes the files you need + to edit in conf and several recipes-* + directories within the BSP layer. Configuration changes identify where your new layer is on the local system and identify which kernel you are going to use. @@ -160,7 +163,8 @@ You need to get the build environment ready by sourcing an environment setup script and you need to be sure two key configuration files are configured appropriately. The entire process for building an image is overviewed in the section - "Building an Image" section of the Yocto Project Quick Start. + "Building an Image" section + of the Yocto Project Quick Start. You might want to reference this information. Build the image: The Yocto Project uses the BitBake tool to build images based on the type of image you want to create. @@ -168,7 +172,7 @@ here. The build process supports several types of images to satisfy different needs. See the - "Reference: Images" appendix + "Reference: Images" appendix in The Yocto Project Reference Manual for information on supported images. @@ -178,10 +182,10 @@ You can view a video presentation on "Building Custom Embedded Images with Yocto" at Free Electrons. You can also find supplemental information in - + The Board Support Package (BSP) Development Guide. Finally, there is wiki page write up of the example also located - + here that you might find helpful. @@ -201,7 +205,7 @@ The remainder of this section presents a high-level overview of the Linux Yocto kernel architecture and the steps to modify the Linux Yocto kernel. For a complete discussion of the kernel, see - + The Yocto Project Kernel Architecture and Use Manual. You can reference the appendix "Kernel Modification Example" @@ -221,7 +225,7 @@ You can find a web interface to the Linux Yocto kernel source repositories at - . + . If you look at the interface, you will see to the left a grouping of Git repositories titled "Yocto Linux Kernel." Within this group, you will find the four different kernels supported by @@ -352,7 +356,7 @@ Again, for a complete discussion of the Yocto Project kernel's architcture and its branching strategy, - see the + see the The Yocto Project Kernel Architecture and Use Manual. Also, you can reference Modifying the Kernel Source Code @@ -376,8 +380,8 @@ Set up your host development system to support development using the Yocto Project: See - "The Linux Distributions" and - "The Packages" sections both + "The Linux Distributions" and + "The Packages" sections both in the Yocto Project Quick Start for requirements. Establish a local copy of the Yocto Project files on your system: Having the Yocto Project files on your system gives you access to @@ -457,7 +461,8 @@ (local.conf and bblayers.conf) are configured appropriately. The entire process for building an image is overviewed in the - "Building an Image" section of the Yocto Project Quick Start. + "Building an Image" + section of the Yocto Project Quick Start. You might want to reference this information. Also, you should look at the detailed examples found in the appendices at at the end of this manual. @@ -468,7 +473,7 @@ here. The build process supports several types of images to satisfy different needs. See the appendix - "Reference: Images" in + "Reference: Images" in The Yocto Project Reference Manual for information on supported images. Make your configuration changes available in the kernel layer: Up to this point, all the configuration changes to the @@ -519,7 +524,7 @@ provides an overview of the general development process. If you want to see a detailed example of the process as it is used from within the Eclipse IDE, see - + The Application Development Toolkit (ADT) User's Manual. @@ -536,8 +541,8 @@ Prepare the Host System for the Yocto Project: See - "The Linux Distributions" and - "The Packages" sections both + "The Linux Distributions" and + "The Packages" sections both in the Yocto Project Quick Start for requirements.