mirror of
https://git.yoctoproject.org/git/poky
synced 2026-01-01 13:58:04 +00:00
getting-started, mega-manual: New content for intro chapter
Created content for "What is the Yocto Project" section. Involved a new figure that had to be shared in the mega-manual figures folder. (From yocto-docs rev: 72c18abd11587f4d78848afb8a71ff7f4a0e76d0) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
31f0dda70b
commit
4b3ebf00dc
|
|
@ -89,7 +89,7 @@ XSLTOPTS = --xinclude
|
|||
ALLPREQ = html eclipse tarball
|
||||
TARFILES = getting-started-style.css getting-started.html figures/getting-started-title.png \
|
||||
figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \
|
||||
figures/yp-download.png figures/YP-flow-diagram.png \
|
||||
figures/yp-download.png figures/YP-flow-diagram.png figures/key-dev-elements.png \
|
||||
eclipse
|
||||
MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
|
||||
FIGURES = figures
|
||||
|
|
@ -270,7 +270,7 @@ TARFILES = mega-manual.html mega-style.css \
|
|||
figures/source-fetching.png figures/patching.png \
|
||||
figures/configuration-compile-autoreconf.png \
|
||||
figures/analysis-for-package-splitting.png \
|
||||
figures/image-generation.png \
|
||||
figures/image-generation.png figures/key-dev-elements.png\
|
||||
figures/sdk-generation.png figures/recipe-workflow.png \
|
||||
figures/build-workspace-directory.png figures/mega-title.png \
|
||||
figures/toaster-title.png figures/hosted-service.png \
|
||||
|
|
|
|||
BIN
documentation/getting-started/figures/key-dev-elements.png
Normal file
BIN
documentation/getting-started/figures/key-dev-elements.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
|
|
@ -8,6 +8,261 @@
|
|||
<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='what-are-layers'>
|
||||
|
|
|
|||
BIN
documentation/mega-manual/figures/key-dev-elements.png
Normal file
BIN
documentation/mega-manual/figures/key-dev-elements.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Loading…
Reference in New Issue
Block a user