mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 21:09:03 +02:00
cfdf4c78eb
This involved removing the general information about layers from the dev-manual and incorporating it into the new section of the getting-started manual. (From yocto-docs rev: 26438b03751948661f48fb0c023e393101b80e19) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
417 lines
21 KiB
XML
417 lines
21 KiB
XML
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
|
|
|
<chapter id='overview-yp'>
|
|
<title>Introducing the Yocto Project</title>
|
|
|
|
<section id='what-is-the-yocto-project'>
|
|
<title>What is the Yocto Project?</title>
|
|
|
|
<para>
|
|
The Yocto Project is an open source collaboration project
|
|
that helps developers create custom Linux-based systems that are
|
|
designed for embedded products regardless of the product's hardware
|
|
architecture.
|
|
Yocto Project provides a flexible toolset and a development
|
|
environment that allows embedded device developers across the
|
|
world to collaborate through shared technologies, software stacks,
|
|
configurations, and best practices used to create these tailored
|
|
Linux images.
|
|
</para>
|
|
|
|
<para>
|
|
Thousands of developers worldwide have discovered that Yocto
|
|
Project provides advantages in both systems and applications
|
|
development, archival and management benefits, and customizations
|
|
used for speed, footprint, and memory utilization.
|
|
The project is a standard when it comes to delivering hardware
|
|
support and software stacks, allowing software configuration
|
|
and build interchange, and build and support customizations for
|
|
multiple hardware platforms and software stacks that can be
|
|
maintained and scaled.
|
|
</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/key-dev-elements.png"
|
|
format="PNG" align='center' width="8in"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
|
|
<para>
|
|
For further introductory information on the Yocto Project, you
|
|
might be interested in this
|
|
<ulink url='https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project-'>article</ulink>
|
|
by Drew Moseley and in this short introductory
|
|
<ulink url='https://www.youtube.com/watch?v=utZpKM7i5Z4'>video</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
The remainder of this section overviews advantages and challenges
|
|
tied to the Yocto Project.
|
|
</para>
|
|
|
|
<section id='gs-features'>
|
|
<title>Features</title>
|
|
|
|
<para>
|
|
The following list describes features and advantages of the
|
|
Yocto Project:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<emphasis>Widely Adopted Across the Industry:</emphasis>
|
|
Semiconductor, operating system, software, and
|
|
service vendors exist whose products and services
|
|
adopt and support the Yocto Project.
|
|
For a look at the companies involved with the Yocto
|
|
Project, see the membership, associate, and
|
|
participant pages on the Yocto Project home page.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Architecture Agnostic:</emphasis>
|
|
Yocto Project supports Intel, ARM, MIPS, AMD, PPC
|
|
and other architectures.
|
|
Most ODMs, OSVs, and chip vendors create and supply
|
|
BSPs that support their hardware.
|
|
If you have custom silicon, you can create a BSP
|
|
that supports that architecture.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Images and Code Transfer Easily:</emphasis>
|
|
Yocto Project output can easily move between
|
|
architectures without moving to new development
|
|
environments.
|
|
Additionally, if you have used the Yocto Project to
|
|
create an image or application and you find yourself
|
|
not able to support it, commercial Linux vendors such
|
|
as Wind River, Mentor Graphics, Timesys, and ENEA could
|
|
take it and provide ongoing support.
|
|
These vendors have offerings that are built using
|
|
the Yocto Project.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Flexibility:</emphasis>
|
|
Corporations use the Yocto Project many different ways.
|
|
One example is to create an internal Linux distribution
|
|
as a code base the corporation can use across multiple
|
|
product groups.
|
|
Through customization and layering, a project group
|
|
can leverage the base Linux distribution to create
|
|
a distribution that works for their product needs.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Ideal for Constrained Embedded and IoT devices:</emphasis>
|
|
Unlike a full Linux distribution, you can use the
|
|
Yocto Project to create exactly what you need for
|
|
embedded devices.
|
|
You only add the feature support or packages that you
|
|
absolutely need for the device.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Comprehensive Toolchain Capabilities:</emphasis>
|
|
Toolchains for supported architectures satisfy most
|
|
use cases.
|
|
However, if your hardware supports features that are
|
|
not part of a standard toolchain, you can easily
|
|
customize that toolchain through specification of
|
|
platform-specific tuning parameters.
|
|
And, should you need to use a third-party toolchain,
|
|
mechanisms built into the Yocto Project allow for that.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Mechanism Rules Over Policy:</emphasis>
|
|
Focusing on mechanism rather than policy ensures that
|
|
you are free to set policies based on the needs of your
|
|
design instead of adopting decisions enforced by some
|
|
system software provider.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Uses a Layer Model:</emphasis>
|
|
The Yocto Project layer infrastructure groups related
|
|
functionality into separate bundles.
|
|
You can incrementally add these grouped functionalities
|
|
to your project as needed.
|
|
Using layers to isolate and group functionality
|
|
reduces project complexity and redundancy.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Supports Partial Builds:</emphasis>
|
|
You can build and rebuild individual packages as
|
|
needed.
|
|
Yocto Project accomplishes this through its
|
|
shared-state cache (sstate) scheme.
|
|
Being able to build and debug components individually
|
|
eases project development.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Releases According to a Strict Schedule:</emphasis>
|
|
Major releases occur on a six-month cycle predictably
|
|
in October and April.
|
|
The most recent two releases support point releases
|
|
to address common vulnerabilities and exposures.
|
|
This predictability is crucial for projects based on
|
|
the Yocto Project and allows development teams to
|
|
plan activities.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Rich Ecosystem of Individuals and Organizations:</emphasis>
|
|
For open source projects, the value of community is
|
|
very important.
|
|
Support forums, expertise, and active developers who
|
|
continue to push the Yocto Project forward are readily
|
|
available.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Binary Reproducibility:</emphasis>
|
|
The Yocto Project you to be very specific about
|
|
dependencies and achieves very high percentages of
|
|
binary reproducibility (e.g. 99.8% for
|
|
<filename>core-image-minimal</filename>).
|
|
When distributions are not specific about which
|
|
packages are pulled in and in what order to support
|
|
dependencies, other build systems can arbitrarily
|
|
include packages.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>License Manifest:</emphasis>
|
|
The Yocto Project provides a license manifest for
|
|
review by people that need to track the use of open
|
|
source licenses (e.g.legal teams).
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</section>
|
|
|
|
<section id='gs-challenges'>
|
|
<title>Challenges</title>
|
|
|
|
<para>
|
|
The following list presents challenges you might encounter
|
|
when developing using the Yocto Project:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<emphasis>Steep Learning Curve:</emphasis>
|
|
The Yocto Project has a steep learning curve and has
|
|
many different ways to accomplish similar tasks.
|
|
It can be difficult to choose how to proceed when
|
|
varying methods exist by which to accomplish a given
|
|
task.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Understanding What Changes You Need to Make
|
|
For Your Design Requires Some Research:</emphasis>
|
|
Beyond the simple tutorial stage, understanding what
|
|
changes need to be made for your particular design
|
|
can require a significant amount of research and
|
|
investigation.
|
|
For information that helps you transition from
|
|
trying out the Yocto Project to using it for your
|
|
project, see the "What I wish I'd Known" and
|
|
"Transitioning to a Custom Environment for Systems
|
|
Development" documents on the Yocto Project website.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Project Workflow Could Be Confusing:</emphasis>
|
|
The Yocto Project workflow could be confusing if you
|
|
used to traditional desktop and server software
|
|
development.
|
|
In a desktop development environment, mechanisms exist
|
|
to easily pull and install new packages, which are
|
|
typically pre-compiled binaries from servers accessible
|
|
over the Internet.
|
|
Using the Yocto Project, you must modify your
|
|
configuration and rebuild to add additional packages.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Working in a Cross-Build Environment Can
|
|
Feel Unfamiliar:</emphasis>
|
|
When developing code to run on a target, compilation,
|
|
execution, and testing done on the actual target
|
|
can be faster than running a BitBake build on a
|
|
development host and then deploying binaries to the
|
|
target for test.
|
|
While the Yocto Project does support development tools
|
|
on the target, the additional step of integrating your
|
|
changes back into the Yocto Project build environment
|
|
would be required.
|
|
Yocto Project supports an intermediate approach that
|
|
involves making changes on the development system
|
|
within the BitBake environment and then deploying only
|
|
the updated packages to the target.</para>
|
|
|
|
<para>The Yocto Project OpenEmbedded build system
|
|
produces packages in standard formats (i.e. RPM,
|
|
DEB, IPK, and TAR).
|
|
You can deploy these packages into the running system
|
|
on the target by using utilities on the target such
|
|
as <filename>rpm</filename> or
|
|
<filename>ipk</filename>.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Initial Build Times Can be Significant:</emphasis>
|
|
Long initial build times are unfortunately unavoidable
|
|
due to the large number of packages initially built
|
|
from scratch for a fully functioning Linux system.
|
|
Once that initial build is completed, however, the
|
|
shared-state (sstate) cache mechanism Yocto Project
|
|
uses keeps the system from rebuilding packages that
|
|
have not been "touched" since the last build.
|
|
The sstate mechanism significantly reduces times
|
|
for successive builds.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id='the-yocto-project-layer-model'>
|
|
<title>The Yocto Project Layer Model</title>
|
|
|
|
<para>
|
|
The Yocto Project's "Layer Model" is a development model for
|
|
embedded and IoT Linux creation that distinguishes the
|
|
Yocto Project from other simple build systems.
|
|
The Layer Model simultaneously supports collaboration and
|
|
customization.
|
|
Layers are repositories that contain related sets of instructions
|
|
that tell the OpenEmbedded build system what to do.
|
|
You can collaborate, share, and reuse layers.
|
|
</para>
|
|
|
|
<para>
|
|
Layers can contain changes to previous instructions or settings
|
|
at any time.
|
|
This powerful override capability is what allows you to customize
|
|
previously supplied collaborative or community layers to suit your
|
|
product requirements.
|
|
</para>
|
|
|
|
<para>
|
|
You use different layers to logically separate information in your
|
|
build.
|
|
As an example, you could have BSP, GUI, distro configuration,
|
|
middleware, or application layers.
|
|
Putting your entire build into one layer limits and complicates
|
|
future customization and reuse.
|
|
Isolating information into layers, on the other hand, helps
|
|
simplify future customizations and reuse.
|
|
You might find it tempting to keep everything in one layer when
|
|
working on a single project.
|
|
However, the more modular your Metadata, the easier
|
|
it is to cope with future changes.
|
|
<note><title>Notes</title>
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
Use Board Support Package (BSP) layers from silicon
|
|
vendors when possible.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
Familiarize yourself with the
|
|
<ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project curated layer index</ulink>
|
|
or the
|
|
<ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded layer index</ulink>.
|
|
The latter contains more layers but they are less
|
|
universally validated.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
Layers support the inclusion of technologies, hardware
|
|
components, and software components.
|
|
The Yocto Project Compatible designation provides a
|
|
minimum level of standardization that contributes to a
|
|
strong ecosystem.
|
|
"YP Compatible" is applied to appropriate products and
|
|
software components such as BSPs, other OE-compatible
|
|
layers, and related open-source projects, allowing the
|
|
producer to use Yocto Project badges and branding
|
|
assets.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
To illustrate how layers are used to keep things modular, consider
|
|
machine customizations.
|
|
These types of customizations typically reside in a special layer,
|
|
rather than a general layer, called a BSP Layer.
|
|
Furthermore, the machine customizations should be isolated from
|
|
recipes and Metadata that support a new GUI environment,
|
|
for example.
|
|
This situation gives you a couple of layers: one for the machine
|
|
configurations, and one for the GUI environment.
|
|
It is important to understand, however, that the BSP layer can
|
|
still make machine-specific additions to recipes within the GUI
|
|
environment layer without polluting the GUI layer itself
|
|
with those machine-specific changes.
|
|
You can accomplish this through a recipe that is a BitBake append
|
|
(<filename>.bbappend</filename>) file, which is described later
|
|
in this section.
|
|
<note>
|
|
For general information on BSP layer structure, see the
|
|
<ulink url='&YOCTO_DOCS_BSP_URL;#bsp'>Board Support Packages (BSP) - Developer's Guide</ulink>.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
The
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
|
|
contains both general layers and BSP layers right out of the box.
|
|
You can easily identify layers that ship with a Yocto Project
|
|
release in the Source Directory by their names.
|
|
Layers typically have names that begin with the string
|
|
<filename>meta-</filename>.
|
|
<note>
|
|
It is not a requirement that a layer name begin with the
|
|
prefix <filename>meta-</filename>, but it is a commonly
|
|
accepted standard in the Yocto Project community.
|
|
</note>
|
|
For example, if you were to examine the
|
|
<ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/'>tree view</ulink>
|
|
of the <filename>poky</filename> repository, you will see several
|
|
layers: <filename>meta</filename>,
|
|
<filename>meta-skeleton</filename>,
|
|
<filename>meta-selftest</filename>,
|
|
<filename>meta-poky</filename>, and
|
|
<filename>meta-yocto-bsp</filename>.
|
|
Each of these repositories represents a distinct layer.
|
|
</para>
|
|
|
|
<para>
|
|
For procedures on how to create layers, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
|
|
section in the Yocto Project Development Tasks Manual.
|
|
</para>
|
|
</section>
|
|
|
|
<section id='components-and-tools'>
|
|
<title>Components and Tools</title>
|
|
|
|
</section>
|
|
|
|
<section id='the-development-environment'>
|
|
<title>The Development Environment</title>
|
|
|
|
</section>
|
|
|
|
<section id='reference-embedded-distribution'>
|
|
<title>Reference Embedded Distribution (Poky)</title>
|
|
|
|
</section>
|
|
|
|
<section id='the-yocto-project-workflow'>
|
|
<title>The Yocto Project Workflow</title>
|
|
|
|
</section>
|
|
|
|
|
|
<section id='some-basic-terms'>
|
|
<title>Some Basic Terms</title>
|
|
|
|
</section>
|
|
|
|
</chapter>
|
|
<!--
|
|
vim: expandtab tw=80 ts=4
|
|
-->
|