diff --git a/documentation/adt-manual/adt-eclipse.xml b/documentation/adt-manual/adt-eclipse.xml
index 3a6dce5da7..aead5d8ee2 100644
--- a/documentation/adt-manual/adt-eclipse.xml
+++ b/documentation/adt-manual/adt-eclipse.xml
@@ -324,7 +324,7 @@
Point to the Toolchain:
If you are using a stand-alone pre-built toolchain, you should be pointing to the
- /opt/poky/1.1 directory.
+ &YOCTO_ADTPATH_DIR; directory.
This is the location for toolchains installed by the ADT Installer or by hand.
Sections "Configuring
and Running the ADT Installer Script" and
diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index fef07e5797..25f74763b1 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -43,7 +43,7 @@
$ git clone git://git.yoctoproject.org/poky
$ cd poky
- Alternatively, you can start with the downloaded Poky "edison" tarball.
+ Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" 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-&YOCTO_POKY;:
@@ -54,7 +54,7 @@
If you're using the tarball method, you can ignore all the following steps that
ask you to carry out Git operations.
You already have the results of those operations
- in the form of the edison release tarballs.
+ in the form of the &DISTRO_NAME; release tarballs.
Consequently, there is nothing left to do other than extract those tarballs into the
proper locations.
@@ -160,7 +160,7 @@
$ cd meta-intel
Alternatively, you can start with the downloaded Crown Bay tarball.
- You can download the edison version of the BSP tarball from the
+ You can download the &DISTRO_NAME; version of the BSP tarball from the
Download page of the
Yocto Project website.
Here is the specific link for the tarball needed for this example:
@@ -177,7 +177,7 @@
The meta-intel directory contains all the metadata
that supports BSP creation.
If you're using the Git method, the following
- step will switch to the edison metadata.
+ step will switch to the &DISTRO_NAME; metadata.
If you're using the tarball method, you already have the correct metadata and can
skip to the next step.
Because meta-intel is its own Git repository, you will want
@@ -445,11 +445,11 @@
and insert the commit identifiers to identify the kernel in which we
are interested, which will be based on the atom-pc-standard
kernel.
- In this case, because we're working with the edison branch of everything, we
+ In this case, because we're working with the &DISTRO_NAME; branch of everything, we
need to use the SRCREV values for the atom-pc branch
- that are associated with the edison release.
+ that are associated with the &DISTRO_NAME; release.
To find those values, we need to find the SRCREV
- values that edison uses for the atom-pc branch, which we find in the
+ values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend
file.
@@ -474,8 +474,8 @@
In this example, we're using the SRCREV values we
- found already captured in the edison release because we're creating a BSP based on
- edison.
+ found already captured in the &DISTRO_NAME; release because we're creating a BSP based on
+ &DISTRO_NAME;.
If, instead, we had based our BSP on the master branches, we would want to use
the most recent SRCREV values taken directly from the kernel repo.
We will not be doing that for this example.
@@ -682,7 +682,7 @@
- For reference, the sato image produced by the previous steps for edison
+ For reference, the sato image produced by the previous steps for &DISTRO_NAME;
should look like the following in terms of size.
If your sato image is much different from this,
you probably made a mistake in one of the above steps:
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 7fd19cb54c..971a63655e 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -248,8 +248,8 @@
Append files files must have the same name as the underlying recipe.
- For example, the append file someapp_1.1.bbappend must
- apply to someapp_1.1.bb.
+ For example, the append file someapp_&DISTRO;.bbappend must
+ apply to someapp_&DISTRO;.bb.
This means the original recipe and append file names are version number specific.
If the underlying recipe is renamed to update to a newer version, the
corresponding .bbappend file must be renamed as well.
diff --git a/documentation/dev-manual/dev-manual-kernel-appendix.xml b/documentation/dev-manual/dev-manual-kernel-appendix.xml
index 58f33e8ef3..865c43b3ec 100644
--- a/documentation/dev-manual/dev-manual-kernel-appendix.xml
+++ b/documentation/dev-manual/dev-manual-kernel-appendix.xml
@@ -155,13 +155,13 @@
$ git branch -a
$ git tag -l
- This example uses the Yocto Project 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 &DISTRO; 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 &DISTRO_NAME; origin/&DISTRO_NAME;
- Branch edison set up to track remote branch &DISTRO_NAME; from origin.
+ Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
Switched to a new branch '&DISTRO_NAME;'
@@ -184,7 +184,7 @@
Setting Up the Bare Clone and its Copy
- This example modifies the linux-yocto-3.0-1.1.x kernel.
+ This example modifies the linux-yocto-3.2 kernel.
Thus, you need to create a bare clone of that kernel and then make a copy of the
bare clone.
See the bulleted item
@@ -196,12 +196,12 @@
The bare clone exists for the kernel build tools and simply as the receiving end
of git push
commands after you make edits and commits inside the copy of the clone.
- The copy (my-linux-yocto-3.0-1.1.x-work in this example) has to have
+ The copy (my-linux-yocto-3.2-work in this example) has to have
a local branch created and checked out for your work.
This example uses common-pc-base as the local branch.
The following commands create and checkout the branch:
- $ cd ~/my-linux-yocto-3.0-1.1.x-work
+ $ cd ~/my-linux-yocto-3.2-work
$ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
Branch common-pc-base set up to track remote branch
yocto/standard/common-pc/base from origin.
@@ -296,7 +296,7 @@
The file you change in this example is named calibrate.c
- and is located in the my-linux-yocto-3.0-1.1.x-work Git repository
+ and is located in the my-linux-yocto-3.2-work Git repository
(the copy of the bare clone) in init.
This example simply inserts several printk statements
at the beginning of the calibrate_delay function.
@@ -420,13 +420,13 @@
poky-extras/meta-kernel-dev/recipes-kernel/linux
directory, you need to identify the location of the
local source code, which in this example is the bare clone named
- linux-yocto-3.0-1.1.x.git.
+ linux-yocto-3.2.git.
To do this, set the KSRC_linux_yocto variable to point to your
- local linux-yocto-3.0-1.1.x.git Git repository by adding the
+ local linux-yocto-3.2.git Git repository by adding the
following statement.
Be sure to substitute your user information in the statement:
- KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
+ KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.2.git
Specify the Kernel Machine: Also in the
linux-yocto_3.0.bbappend file, you need to specify
@@ -545,13 +545,13 @@
$ git branch -a
$ git tag -l
- This example uses the Yocto Project 1.1.1 Release code named "&DISTRO_NAME;",
+ This example uses the Yocto Project &DISTRO; 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 &DISTRO_NAME; origin/&DISTRO_NAME;
- Branch edison set up to track remote branch &DISTRO_NAME; from origin.
+ Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
Switched to a new branch '&DISTRO_NAME;'
@@ -654,7 +654,7 @@
After setting up the environment to run menuconfig, you are ready
to use the tool to interactively change the kernel configuration.
- In this example, we are basing our changes on the linux-yocto-3.0-1.1.x
+ In this example, we are basing our changes on the linux-yocto-3.2
kernel.
The Yocto Project build environment recognizes this kernel as
linux-yocto.
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index 29840ee720..1950210644 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -247,6 +247,9 @@
linux-yocto-3.0-1.1.x - The
stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x. This kernel
is based on the Linux 3.0 release
+ linux-yocto-3.2 - The
+ stable Linux Yocto kernel to use with the Yocto Project Release 1.2. This kernel
+ is based on the Linux 3.2 releaselinux-yocto-dev - A development
kernel based on the latest upstream release candidate available.
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 0cf9f3110f..132888a196 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -494,7 +494,8 @@
Git uses "branches" to organize different development efforts.
For example, the poky repository has
laverne, bernard,
- edison, and master branches among
+ edison, denzil and
+ master branches among
others.
You can see all the branches by going to
and
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index 02f6599179..791315c960 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -132,18 +132,18 @@
For simplicity, it is recommended that you create these structures outside of the
Yocto Project Files Git repository.As an example, the following transcript shows how to create the bare clone
- of the linux-yocto-3.0-1.1.x kernel and then create a copy of
+ of the linux-yocto-3.2 kernel and then create a copy of
that clone.
When you have a local Linux Yocto kernel Git repository, you can
reference that repository rather than the upstream Git repository as
part of the clone command.
Doing so can speed up the process.In the following example, the bare clone is named
- linux-yocto-3.0-1.1.x.git, while the
- copy is named my-linux-yocto-3.0-1.1.x-work:
+ linux-yocto-3.2.git, while the
+ copy is named my-linux-yocto-3.2-work:
- $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
- Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
+ $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2 linux-yocto-3.2.git
+ Initialized empty Git repository in /home/scottrif/linux-yocto-3.2.git/
remote: Counting objects: 2259181, done.
remote: Compressing objects: 100% (373259/373259), done.
remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
@@ -152,8 +152,8 @@
Now create a clone of the bare clone just created:
- $ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
- Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
+ $ git clone linux-yocto-3.2.git my-linux-yocto-3.2-work
+ Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.2/.git/
Checking out files: 100% (36898/36898), done.