dev-manual: Edits from a 2.1 read-through.

* Removed some eMenlow stuff
* Cleaned up the description of the BSP structures we have now.
* Various links fixed into the SDK manual.
* Other minor fixes.

(From yocto-docs rev: 5e45005d7ff2254df2754a5ea2d7efd7f1c19a42)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2016-03-17 12:59:39 -07:00 committed by Richard Purdie
parent a3896841f2
commit 19e3648390
6 changed files with 117 additions and 77 deletions

View File

@ -550,8 +550,8 @@
<para>
Following is the append file, which is named
<filename>formfactor_0.0.bbappend</filename> and is from the
Emenlow BSP Layer named
<filename>meta-intel/meta-emenlow</filename>.
Raspberry Pi BSP Layer named
<filename>meta-raspberrypi</filename>.
The file is in <filename>recipes-bsp/formfactor</filename>:
<literallayout class='monospaced'>
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@ -577,7 +577,7 @@
which resolves to a directory named
<filename>formfactor</filename> in the same directory
in which the append file resides (i.e.
<filename>meta-intel/meta-emenlow/recipes-bsp/formfactor/formfactor</filename>.
<filename>meta-raspberrypi/recipes-bsp/formfactor/formfactor</filename>.
This implies that you must have the supporting directory
structure set up that will contain any files or patches you
will be including from the layer.
@ -5492,10 +5492,6 @@
"<ulink url='http://elinux.org/images/6/6f/Security-issues.pdf'>Security Issues for Embedded Devices</ulink>"</emphasis>
by Jake Edge
</para></listitem>
<listitem><para><emphasis>
"<ulink url='https://www.nccgroup.com/media/18475/exploiting_security_gateways_via_their_web_interfaces.pdf'>They ought to know better: Exploiting Security Gateways via their Web Interfaces</ulink>"</emphasis>
by Ben Williams
</para></listitem>
</itemizedlist>
</para>
@ -9160,7 +9156,7 @@
Before you can initiate a remote debugging session, you need
to be sure you have set up the cross-development environment,
toolchain, and sysroot.
The <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
The <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
describes this process.
</para>
</section>

View File

@ -29,8 +29,8 @@
<para>
The Yocto Project Development Manual does, however, provide
guidance and examples on how to change the kernel source code,
reconfigure the kernel, and develop an application using the
popular <trademark class='trade'>Eclipse</trademark> IDE.
reconfigure the kernel, and develop an application using
<filename>devtool</filename>.
</para>
<note>
@ -86,16 +86,21 @@
<itemizedlist>
<listitem><para><emphasis>Step-by-step instructions when those instructions exist in other Yocto
Project documentation:</emphasis>
For example, the Yocto Project Software Development Kit (SDK) Developer's Guide contains detailed
instructions on how to install an SDK, which is used to
develop applications for target hardware.</para></listitem>
For example, the
<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
manual contains detailed instructions on how to install an
SDK, which is used to develop applications for target
hardware.
</para></listitem>
<listitem><para><emphasis>Reference material:</emphasis>
This type of material resides in an appropriate reference manual.
For example, system variables are documented in the
<ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.</para></listitem>
<ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.
</para></listitem>
<listitem><para><emphasis>Detailed public information that is not specific to the Yocto Project:</emphasis>
For example, exhaustive information on how to use Git is covered better through the
Internet than in this manual.</para></listitem>
Internet than in this manual.
</para></listitem>
</itemizedlist>
</para>
</section>

View File

@ -48,7 +48,9 @@
that allows you to start builds and examine build statistics.
</para></listitem>
<listitem><para><emphasis>Using a Development Shell:</emphasis>
You can use a <filename>devshell</filename> to efficiently debug
You can use a
<link linkend='platdev-appdev-devshell'><filename>devshell</filename></link>
to efficiently debug
commands or simply edit packages.
Working inside a development shell is a quick way to set up the
OpenEmbedded build environment to work on parts of a project.
@ -147,38 +149,60 @@
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
section in the Yocto Project Board Support (BSP) Developer's Guide.
</para>
<para>
Another example that illustrates a layer is an application.
Suppose you are creating an application that has library or other dependencies in
order for it to compile and run.
The layer, in this case, would be where all the recipes that define those dependencies
are kept.
The key point for a layer is that it is an isolated area that contains
all the relevant information for the project that the OpenEmbedded build
system knows about.
For more information on layers, see the
"<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
section.
For more information on BSP layers, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the
Yocto Project Board Support Package (BSP) Developer's Guide.</para>
<note>Five BSPs exist that are part of the
Yocto Project release: <filename>genericx86</filename>, <filename>genericx86-64</filename>,
<filename>beaglebone</filename> (ARM),
<filename>mpc8315e</filename> (PowerPC),
and <filename>edgerouter</filename> (MIPS).
The recipes and configurations for these five BSPs are located and dispersed
within the <link linkend='source-directory'>Source Directory</link>.
On the other hand, the <filename>meta-intel</filename> layer
contains BSP layers for many supported BSPs (e.g.
Crystal Forest, Emenlow, Fish River Island 2, Haswell,
Jasper Forest, and so forth).
Aside from the BSPs in the <filename>meta-intel</filename>
layer, the
<ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
contain additional BSP layers such as
<filename>meta-minnow</filename> and
<filename>meta-raspberrypi</filename>.</note>
Another example that illustrates a layer
is an application.
Suppose you are creating an application that has
library or other dependencies in order for it to
compile and run.
The layer, in this case, would be where all the
recipes that define those dependencies are kept.
The key point for a layer is that it is an isolated
area that contains all the relevant information for
the project that the OpenEmbedded build system knows
about.
For more information on layers, see the
"<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
section.
For more information on BSP layers, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
section in the Yocto Project Board Support Package (BSP)
Developer's Guide.
<note>
<para>
Five BSPs exist that are part of the Yocto Project release:
<filename>beaglebone</filename> (ARM),
<filename>mpc8315e</filename> (PowerPC),
and <filename>edgerouter</filename> (MIPS).
The recipes and configurations for these five BSPs
are located and dispersed within the
<link linkend='source-directory'>Source Directory</link>.
</para>
<para>
Three core Intel BSPs exist as part of the Yocto
Project release in the
<filename>meta-intel</filename> layer:
<itemizedlist>
<listitem><para><filename>intel-core2-32</filename>,
which is a BSP optimized for the Core2 family of CPUs
as well as all CPUs prior to the Silvermont core.
</para></listitem>
<listitem><para><filename>intel-corei7-64</filename>,
which is a BSP optimized for Nehalem and later
Core and Xeon CPUs as well as Silvermont and later
Atom CPUs, such as the Baytrail SoCs.
</para></listitem>
<listitem><para><filename>intel-quark</filename>,
which is a BSP optimized for the Intel Galileo
gen1 &amp; gen2 development boards.
</para></listitem>
</itemizedlist>
</para>
</note>
</para>
<para>When you set up a layer for a new BSP, you should follow a standard layout.
This layout is described in the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
@ -288,18 +312,6 @@
Within this group, you will find several kernels supported by
the Yocto Project:
<itemizedlist>
<listitem><para><emphasis>
<filename>linux-yocto-3.8</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
Project Release 1.4. This kernel is based on the
Linux 3.8 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-3.10</filename></emphasis> - An
additional, unsupported Yocto Project kernel used with
the Yocto Project Release 1.5.
This kernel is based on the Linux 3.10 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-3.14</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
@ -318,12 +330,36 @@
Project Release 1.8.
This kernel is based on the Linux 3.19 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-4.1</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
Project Release 2.0.
This kernel is based on the Linux 4.1 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-4.4</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
Project Release 2.1.
This kernel is based on the Linux 4.4 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-dev</filename></emphasis> - A
development kernel based on the latest upstream release
candidate available.
</para></listitem>
</itemizedlist>
<note>
Long Term Support Initiative (LTSI) for Yocto Project kernels
is as follows:
<itemizedlist>
<listitem><para>For Yocto Project releases 1.7, 1.8, and 2.0,
the LTSI kernel is <filename>linux-yocto-3.14</filename>.
</para></listitem>
<listitem><para>For Yocto Project release 2.1, the
LTSI kernel is <filename>linux-yocto-4.1</filename>.
</para></listitem>
</itemizedlist>
</note>
</para>
<para>
@ -538,7 +574,7 @@
Tools exist to help the application developer during any phase
of development.
For information on how to install and use an SDK, see the
<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
</para>
</section>

View File

@ -96,7 +96,10 @@
<para>
For developers who mainly do application level work
on top of an existing software stack,
here are some practices that work best:
the following list shows practices that work best.
For information on using a Software Development Kit (SDK), see
the
<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:
<itemizedlist>
<listitem><para>Use a pre-built toolchain that
contains the software stack itself.
@ -1045,9 +1048,10 @@
</para>
<para>
Some key tags are <filename>dylan-9.0.4</filename>,
<filename>dora-10.0.4</filename>, <filename>daisy-11.0.2</filename>,
<filename>dizzy-12.0.0</filename>, and
Some key tags are
<filename>dizzy-12.0.0</filename>,
<filename>fido-13.0.0</filename>,
<filename>jethro-14.0.0</filename>, and
<filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
These tags represent Yocto Project releases.
</para>
@ -1127,20 +1131,20 @@
into the projects upstream (or master) repository.</para></listitem>
<listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
possibly need to be staged and committed.</para></listitem>
<listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
<listitem><para><emphasis><filename>git checkout</filename> <replaceable>branch-name</replaceable>:</emphasis> Changes
your working branch.
This command is analogous to "cd".</para></listitem>
<listitem><para><emphasis><filename>git checkout b &lt;working-branch&gt;</filename>:</emphasis> Creates
<listitem><para><emphasis><filename>git checkout b</filename> <replaceable>working-branch</replaceable>:</emphasis> Creates
a working branch on your local machine where you can isolate work.
It is a good idea to use local branches when adding specific features or changes.
This way if you do not like what you have done you can easily get rid of the work.</para></listitem>
<listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports
existing local branches and
tells you the branch in which you are currently working.</para></listitem>
<listitem><para><emphasis><filename>git branch -D &lt;branch-name&gt;</filename>:</emphasis>
<listitem><para><emphasis><filename>git branch -D</filename> <replaceable>branch-name</replaceable>:</emphasis>
Deletes an existing local branch.
You need to be in a local branch other than the one you are deleting
in order to delete <filename>&lt;branch-name&gt;</filename>.</para></listitem>
in order to delete <replaceable>branch-name</replaceable>.</para></listitem>
<listitem><para><emphasis><filename>git pull</filename>:</emphasis> Retrieves information
from an upstream Git
repository and places it in your local Git repository.

View File

@ -50,7 +50,7 @@
One method is to install a Software Development Kit (SDK).
For more information on how to make sure you have
QEMU available, see the
<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
</para>
</section>

View File

@ -221,10 +221,8 @@
</literallayout>
where <replaceable>bsp_name</replaceable> is the recognized
BSP name.
Here are some examples:
Here is an example:
<literallayout class='monospaced'>
meta-crownbay
meta-emenlow
meta-raspberrypi
</literallayout>
See the
@ -263,11 +261,12 @@
$ cd ~/poky
$ git clone git://git.yoctoproject.org/meta-intel.git
Cloning into 'meta-intel'...
remote: Counting objects: 8844, done.
remote: Compressing objects: 100% (2864/2864), done.
remote: Total 8844 (delta 4931), reused 8780 (delta 4867)
Receiving objects: 100% (8844/8844), 2.48 MiB | 264 KiB/s, done.
Resolving deltas: 100% (4931/4931), done.
remote: Counting objects: 11917, done.
remote: Compressing objects: 100% (3842/3842), done.
remote: Total 11917 (delta 6840), reused 11699 (delta 6622)
Receiving objects: 100% (11917/11917), 2.92 MiB | 2.88 MiB/s, done.
Resolving deltas: 100% (6840/6840), done.
Checking connectivity... done.
</literallayout></para>
<para>The same