diff --git a/documentation/yocto-project-qs/figures/yocto-project-transp.png b/documentation/yocto-project-qs/figures/yocto-project-transp.png
deleted file mode 100755
index 31d2b147fd..0000000000
Binary files a/documentation/yocto-project-qs/figures/yocto-project-transp.png and /dev/null differ
diff --git a/documentation/yocto-project-qs/figures/ypqs-title.png b/documentation/yocto-project-qs/figures/ypqs-title.png
deleted file mode 100644
index 25c7a42b99..0000000000
Binary files a/documentation/yocto-project-qs/figures/ypqs-title.png and /dev/null differ
diff --git a/documentation/yocto-project-qs/qs-style.css b/documentation/yocto-project-qs/qs-style.css
deleted file mode 100644
index 5085b9d0be..0000000000
--- a/documentation/yocto-project-qs/qs-style.css
+++ /dev/null
@@ -1,989 +0,0 @@
-/*
- Generic XHTML / DocBook XHTML CSS Stylesheet.
-
- Browser wrangling and typographic design by
- Oyvind Kolas / pippin@gimp.org
-
- Customised for Poky by
- Matthew Allum / mallum@o-hand.com
-
- Thanks to:
- Liam R. E. Quin
- William Skaggs
- Jakub Steiner
-
- Structure
- ---------
-
- The stylesheet is divided into the following sections:
-
- Positioning
- Margins, paddings, width, font-size, clearing.
- Decorations
- Borders, style
- Colors
- Colors
- Graphics
- Graphical backgrounds
- Nasty IE tweaks
- Workarounds needed to make it work in internet explorer,
- currently makes the stylesheet non validating, but up until
- this point it is validating.
- Mozilla extensions
- Transparency for footer
- Rounded corners on boxes
-
-*/
-
-
- /*************** /
- / Positioning /
-/ ***************/
-
-body {
- font-family: Verdana, Sans, sans-serif;
-
- min-width: 640px;
- width: 80%;
- margin: 0em auto;
- padding: 2em 5em 5em 5em;
- color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
- font-family: Arial, Sans;
- color: #00557D;
- clear: both;
-}
-
-h1 {
- font-size: 2em;
- text-align: left;
- padding: 0em 0em 0em 0em;
- margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
- margin: 0.10em 0em 3.0em 0em;
- padding: 0em 0em 0em 0em;
- font-size: 1.8em;
- padding-left: 20%;
- font-weight: normal;
- font-style: italic;
-}
-
-h2 {
- margin: 2em 0em 0.66em 0em;
- padding: 0.5em 0em 0em 0em;
- font-size: 1.5em;
- font-weight: bold;
-}
-
-h3.subtitle {
- margin: 0em 0em 1em 0em;
- padding: 0em 0em 0em 0em;
- font-size: 142.14%;
- text-align: right;
-}
-
-h3 {
- margin: 1em 0em 0.5em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 140%;
- font-weight: bold;
-}
-
-h4 {
- margin: 1em 0em 0.5em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 120%;
- font-weight: bold;
-}
-
-h5 {
- margin: 1em 0em 0.5em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 110%;
- font-weight: bold;
-}
-
-h6 {
- margin: 1em 0em 0em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 110%;
- font-weight: bold;
-}
-
-.authorgroup {
- background-color: transparent;
- background-repeat: no-repeat;
- padding-top: 256px;
- background-image: url("figures/ypqs-title.png");
- background-position: left top;
- margin-top: -256px;
- padding-right: 50px;
- margin-left: 0px;
- text-align: right;
- width: 740px;
-}
-
-h3.author {
- margin: 0em 0me 0em 0em;
- padding: 0em 0em 0em 0em;
- font-weight: normal;
- font-size: 100%;
- color: #333;
- clear: both;
-}
-
-.author tt.email {
- font-size: 66%;
-}
-
-.titlepage hr {
- width: 0em;
- clear: both;
-}
-
-.revhistory {
- padding-top: 2em;
- clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
- padding: 1.33em 0em 2.5em 0em;
- color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
- padding: 0em 0em 0em 0em;
- padding: 0em 0em 0.3em;
- margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
- font-size: 100.0%;
- font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
- margin: 0em 0em 0.5em 0em;
- padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
- margin: 0em 0em 0em 0em;
- padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
- margin: 0em 0em 0em 2.6em;
- padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
- font-weight: normal;
- width: 20em;
- text-align: right;
-}
-
-.variablelist dl dt {
- margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
- margin-top: -1em;
- margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
- margin-top: 0em;
- margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
- padding: 0em 0em 0em 0em;
- margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
- margin-top: 0em;
- margin-bottom: 1em;
-}
-
-div p.copyright {
- text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
- margin-bottom: 0em;
-}
-
-p {
- line-height: 1.5em;
- margin-top: 0em;
-
-}
-
-dl {
- padding-top: 0em;
-}
-
-hr {
- border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
- text-align: center;
-}
-
-img {
- border: none;
-}
-
-ul {
- padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
- padding: 0em 0em 0em 0em;
-}
-
-ul li p {
- text-align: left;
-}
-
-table {
- width :100%;
-}
-
-th {
- padding: 0.25em;
- text-align: left;
- font-weight: normal;
- vertical-align: top;
-}
-
-td {
- padding: 0.25em;
- vertical-align: top;
-}
-
-p a[id] {
- margin: 0px;
- padding: 0px;
- display: inline;
- background-image: none;
-}
-
-a {
- text-decoration: underline;
- color: #444;
-}
-
-pre {
- overflow: auto;
-}
-
-a:hover {
- text-decoration: underline;
- /*font-weight: bold;*/
-}
-
-/* This style defines how the permalink character
- appears by itself and when hovered over with
- the mouse. */
-
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
- margin: 1em 0em;
- padding: 1em;
- page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
- padding-top: 0em;
- margin-top: 0em;
- font-size: 100%;
- font-weight: normal;
-}
-
-.mediaobject .caption,
-.mediaobject .caption p {
- text-align: center;
- font-size: 80%;
- padding-top: 0.5em;
- padding-bottom: 0.5em;
-}
-
-.epigraph {
- padding-left: 55%;
- margin-bottom: 1em;
-}
-
-.epigraph p {
- text-align: left;
-}
-
-.epigraph .quote {
- font-style: italic;
-}
-.epigraph .attribution {
- font-style: normal;
- text-align: right;
-}
-
-span.application {
- font-style: italic;
-}
-
-.programlisting {
- font-family: monospace;
- font-size: 80%;
- white-space: pre;
- margin: 1.33em 0em;
- padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
- margin-top: 1em;
- margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
- border: none;
- width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
- padding: 0.8em 0.0em 0.0em 0.0em;
- margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
- margin-top: 0.5em;
- margin-bottom: 0.5em;
- padding-right: 1em;
- text-align: left;
-}
-
-.acronym {
- text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
- padding: 0.09em 0.3em;
- margin: 0em;
-}
-
-.itemizedlist li {
- clear: none;
-}
-
-.filename {
- font-size: medium;
- font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
- position: absolute;
- left: 0em;
- top: 0em;
- width: 100%;
- background-color: #cdf;
- width: 100%;
-}
-
-div.navfooter, div.footing{
- position: fixed;
- left: 0em;
- bottom: 0em;
- background-color: #eee;
- width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
- font-size: 66%;
-}
-
-div.navheader table th {
- /*font-family: Georgia, Times, serif;*/
- /*font-size: x-large;*/
- font-size: 80%;
-}
-
-div.navheader table {
- border-left: 0em;
- border-right: 0em;
- border-top: 0em;
- width: 100%;
-}
-
-div.navfooter table {
- border-left: 0em;
- border-right: 0em;
- border-bottom: 0em;
- width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
- color: #777;
- text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
- color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
- color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
- text-decoration: underline;
- background-color: transparent;
- color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
- display: none;
-}
-
-
-.qandaset tr.question td p {
- margin: 0em 0em 1em 0em;
- padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
- margin: 0em 0em 1em 0em;
- padding: 0em 0em 0em 0em;
-}
-.answer td {
- padding-bottom: 1.5em;
-}
-
-.emphasis {
- font-weight: bold;
-}
-
-
- /************* /
- / decorations /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
- border: none;
-}
-
-/*
-h1 {
- border: none;
-}
-
-h2 {
- border-top: solid 0.2em;
- border-bottom: solid 0.06em;
-}
-
-h3 {
- border-top: 0em;
- border-bottom: solid 0.06em;
-}
-
-h4 {
- border: 0em;
- border-bottom: solid 0.06em;
-}
-
-h5 {
- border: 0em;
-}
-*/
-
-.programlisting {
- border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
- border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
- border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
- border-bottom: 1px solid;
-}
-
-.question td {
- border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
- border: 1px solid;
-}
-
-
-div.navheader, div.heading{
- border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
- border-top: 1px solid;
-}
-
- /********* /
- / colors /
-/ *********/
-
-body {
- color: #333;
- background: white;
-}
-
-a {
- background: transparent;
-}
-
-a:hover {
- background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
- background-color: transparent;
-}
-
-hr {
- border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
- border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
- border-bottom-color: #fff;
-}
-
-
-.warning {
- background-color: #f0f0f2;
-}
-
-.caution {
- background-color: #f0f0f2;
-}
-
-.tip {
- background-color: #f0f0f2;
-}
-
-.note {
- background-color: #f0f0f2;
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
- color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
- border-color: #aaa;
-}
-
-pre.programlisting {
- color: black;
- background-color: #fff;
- border-color: #aaa;
- border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
- background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
- background-color: #eee;
- border-color: #999;
-}
-
-
-div.navheader {
- border-color: black;
-}
-
-
-div.navfooter {
- border-color: black;
-}
-
-
-.writernotes {
- color: red;
-}
-
-
- /*********** /
- / graphics /
-/ ***********/
-
-/*
-body {
- background-image: url("images/body_bg.jpg");
- background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
- background-image: url("images/note_bg.jpg");
- background-attachment: fixed;
-}
-
-.warning,
-.caution {
- background-image: url("images/warning_bg.jpg");
- background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
- background-image: url("images/figure_bg.jpg");
- background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
- background-image: url("figures/white-on-black.png");
- background-position: center;
- background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title,
-div.colophon .title,
-div.chapter .titlepage .title {
- background-position: bottom;
- background-repeat: repeat-x;
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
- background: none;
-}
-
-
-h1.title {
- background-color: transparent;
- background-repeat: no-repeat;
- height: 256px;
- text-indent: -9000px;
- overflow:hidden;
-}
-
-h2.subtitle {
- background-color: transparent;
- text-indent: -9000px;
- overflow:hidden;
- width: 0px;
- display: none;
-}
-
- /*************************************** /
- / pippin.gimp.org specific alterations /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
- color: #777;
- font-size: 80%;
- padding: 0;
- margin: 0;
- text-align: left;
- position: absolute;
- top: 0px;
- left: 0px;
- width: 100%;
- height: 50px;
- background: url('/gfx/heading_bg.png') transparent;
- background-repeat: repeat-x;
- background-attachment: fixed;
- border: none;
-}
-
-div.heading a {
- color: #444;
-}
-
-div.footing, div.navfooter {
- border: none;
- color: #ddd;
- font-size: 80%;
- text-align:right;
-
- width: 100%;
- padding-top: 10px;
- position: absolute;
- bottom: 0px;
- left: 0px;
-
- background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
- /****************** /
- / nasty ie tweaks /
-/ ******************/
-
-/*
-div.heading, div.navheader {
- width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
- width:expression(document.body.clientWidth + "px");
- margin-left:expression("-5em");
-}
-body {
- padding:expression("4em 5em 0em 5em");
-}
-*/
-
- /**************************************** /
- / mozilla vendor specific css extensions /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
- -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
- -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
- -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
- display: none;
-}
-
-
-hr {
- display: none;
-}
-
-table {
- border: 0em;
-}
-
- .photo {
- float: right;
- margin-left: 1.5em;
- margin-bottom: 1.5em;
- margin-top: 0em;
- max-width: 17em;
- border: 1px solid gray;
- padding: 3px;
- background: white;
-}
- .seperator {
- padding-top: 2em;
- clear: both;
- }
-
- #validators {
- margin-top: 5em;
- text-align: right;
- color: #777;
- }
- @media print {
- body {
- font-size: 8pt;
- }
- .noprint {
- display: none;
- }
- }
-
-
-.tip,
-.note {
- background: #f0f0f2;
- color: #333;
- padding: 20px;
- margin: 20px;
-}
-
-.tip h3,
-.note h3 {
- padding: 0em;
- margin: 0em;
- font-size: 2em;
- font-weight: bold;
- color: #333;
-}
-
-.tip a,
-.note a {
- color: #333;
- text-decoration: underline;
-}
-
-.footnote {
- font-size: small;
- color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
- font-size:large;
- color: #00557D;
-}
diff --git a/documentation/yocto-project-qs/qs.xml b/documentation/yocto-project-qs/qs.xml
deleted file mode 100644
index 2e5defe6a0..0000000000
--- a/documentation/yocto-project-qs/qs.xml
+++ /dev/null
@@ -1,1113 +0,0 @@
- %poky; ] >
-
-
-
-
- Welcome!
-
-
- Welcome to the Yocto Project!
- The Yocto Project is an open-source collaboration project whose
- focus is developers of embedded Linux systems.
- The Yocto Project provides a development
- environment that eases application, kernel image, and Linux image
- development for embedded hardware systems.
- You can think of the Yocto Project as an umbrella over-arching
- many components, which include a build system, a reference or
- test distribution, and various tools all designed to enhance
- your embedded Linux development experience.
-
-
-
- The Yocto Project uses a build host based on the OpenEmbedded
- (OE) project, which uses the
- BitBake
- tool, to construct complete images.
- The BitBake and OE components combine together to form
- a reference build host, historically known as
- Poky
- (Pock-ee).
- Tools exist that facilitate aspects of development such as
- layer creation to isolate your work, emulation for testing
- modules, modification of existing source code, integration of
- new or modified modules into existing images, and so forth.
-
-
-
- Rather than go into great detail about the Yocto Project and its
- many capabilities, this quick start provides high-level
- practical information that lets you try out the Yocto Project.
- The quick start is written to help introduce you to the Yocto
- Project, get a feel for how to use it to build a Linux image or
- two, and provide you with a "road map" to other areas of interest
- for the new user.
- Tips
-
-
- For more introductory and conceptual information on the
- Yocto Project, see the
- Getting Started With Yocto Project Manual.
-
-
- For guidance on where to look for information beyond
- this quick start, see the
- "Where To Go Next"
- section.
-
-
-
-
-
-
-
- Reference Build
-
-
- This section of the quick start lets you work through setting up
- a build host and then shows you how to build two images: one for
- emulation and one for target hardware.
- The steps do not go into great detail but are rather focused on
- just letting you get set up and quickly experience the Yocto
- Project.
-
-
-
- Setting Up to Use the Yocto Project
-
-
- Setting up to use the Yocto Project involves getting your build
- host ready.
- If you have a native Linux machine that runs a Yocto Project
- supported distribution as described by the
- "Supported Linux Distributions"
- section in the Yocto Project Reference Manual, you can prepare
- that machine as your build host.
- See the
- "Using a Native Linux Machine"
- section for more information.
-
-
-
- If you do not want to use the Yocto Project on a native Linux
- machine, you can prepare your build host to use
- CROPS,
- which leverages
- Docker Containers.
- You can set up a build host for Windows, Mac, and Linux
- machines.
- See the
- "Using CROPS and Containers"
- section for more information.
-
-
-
- Using CROPS and Containers
-
-
- Follow these steps to get your build host set up with a
- Poky container that you can use to complete the build
- examples further down in the Quick Start:
-
-
- Set Up to use CROss PlatformS (CROPS):
- Work through the first six steps of the procedure
- in the
- "Setting Up to Use CROss PlatformS (CROPS)"
- section of the Yocto Project Development Tasks Manual.
-
-
- Set Up the Poky Container to Use the Yocto Project:
- Go to
-
- and follow the directions to set up the Poky container
- on your build host.
-
- Once you complete the setup instructions for your
- machine, you need to get a copy of the
- poky repository on your build
- host.
- See the
- "Yocto Project Release"
- section to continue.
-
-
-
-
-
-
- Using a Native Linux Machine
-
-
- The following list shows what you need in order to use a
- Linux-based build host to use the Yocto Project to build images:
-
-
-
- Build Host
- A build host with a minimum of 50 Gbytes of free disk
- space that is running a supported Linux distribution (i.e.
- recent releases of Fedora, openSUSE, CentOS, Debian, or
- Ubuntu).
-
- Build Host Packages
- Appropriate packages installed on the build host.
-
-
-
-
- The Linux Distribution
-
-
- The Yocto Project team verifies each release against recent
- versions of the most popular Linux distributions that
- provide stable releases.
- In general, if you have the current release minus one of the
- following distributions, you should have no problems.
-
-
- Ubuntu
-
-
- Fedora
-
-
- openSUSE
-
-
- CentOS
-
-
- Debian
-
-
- For a more detailed list of distributions that support the
- Yocto Project, see the
- "Supported Linux Distributions"
- section in the Yocto Project Reference Manual.
-
-
-
- The OpenEmbedded build system should be able to run on any
- modern distribution that has the following versions for
- Git, tar, and Python.
-
-
- Git 1.8.3.1 or greater
-
-
- tar 1.27 or greater
-
-
- Python 3.4.0 or greater.
-
-
- If your build host does not meet any of these three listed
- version requirements, you can take steps to prepare the
- system so that you can still use the Yocto Project.
- See the
- "Required Git, tar, and Python Versions"
- section in the Yocto Project Reference Manual for information.
-
-
-
-
- The Build Host Packages
-
-
- Required build host packages vary depending on your
- build machine and what you want to do with the Yocto Project.
- For example, if you want to build an image that can run
- on QEMU in graphical mode (a minimal, basic build
- requirement), then the build host package requirements
- are different than if you want to build an image on a headless
- system or build out the Yocto Project documentation set.
-
-
-
- Collectively, the number of required packages is large
- if you want to be able to cover all cases.
-
- In general, you need to have root access and then install
- the required packages.
- Thus, the commands in the following section may or may
- not work depending on whether or not your Linux
- distribution has sudo installed.
-
-
-
-
- The following list shows the required packages needed to build
- an image that runs on QEMU in graphical mode (e.g. essential
- plus graphics support).
- For lists of required packages for other scenarios, see the
- "Required Packages for the Host Development System"
- section in the Yocto Project Reference Manual.
-
- Ubuntu and Debian
-
- $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
-
-
- Fedora
-
- $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
-
-
- OpenSUSE
-
- $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
-
-
- CentOS
-
- $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
-
- Notes
-
-
- Extra Packages for Enterprise Linux
- (i.e. epel-release)
- is a collection of packages from Fedora
- built on RHEL/CentOS for easy installation
- of packages not included in enterprise
- Linux by default.
- You need to install these packages
- separately.
-
-
- The makecache command
- consumes additional Metadata from
- epel-release.
-
-
-
-
-
-
-
-
-
- Once you complete the setup instructions for your
- machine, you need to get a copy of the
- poky repository on your build
- host.
- Continue with the
- "Yocto Project Release"
- section.
-
-
-
-
- Yocto Project Release
-
-
- Now that your build host has the right packages (native
- Linux machine) or you have the Poky container set up
- (CROPS), you need to get a copy of the Yocto Project.
- It is recommended that you get the latest Yocto Project release
- by setting up (cloning in
- Git
- terms) a local copy of the poky Git
- repository on your build host and then checking out the
- latest release.
- Doing so allows you to easily update to newer Yocto Project
- releases as well as contribute back to the Yocto Project.
-
-
-
- Here is an example from a native Linux machine that is
- running Ubuntu.
-
- If your build host is using a Poky container, you can
- use the same Git commands.
-
- The following example clones the poky
- repository and then checks out the latest Yocto Project Release
- by tag (i.e. &DISTRO_REL_TAG;):
-
- $ git clone git://git.yoctoproject.org/poky
- Cloning into 'poky'...
- remote: Counting objects: 361782, done.
- remote: Compressing objects: 100% (87100/87100), done.
- remote: Total 361782 (delta 268619), reused 361439 (delta 268277)
- Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s, done.
- Resolving deltas: 100% (268619/268619), done.
- Checking connectivity... done.
- $ cd poky
- $ git checkout tags/&DISTRO_REL_TAG; -b poky_&DISTRO;
-
-
-
-
- The previous Git checkout command
- creates a local branch named
- poky_&DISTRO;.
- The files available to you in that branch exactly match the
- repository's files in the
- &DISTRO_NAME_NO_CAP;
- development branch at the time of the Yocto Project &DISTRO;
- release.
-
- Rather than checking out the entire development branch
- of a release (i.e. the tip), which could be continuously
- changing while you are doing your development, you would
- check out a branch based on a release tag as shown in
- the previous example.
- Doing so provides you with an unchanging, stable set of
- files.
-
-
-
-
- For more options and information about accessing Yocto
- Project related repositories, see the
- "Working With Yocto Project Source Files"
- section in the Yocto Project Development Tasks Manual.
-
-
-
-
-
- Building Images
-
-
- You are now ready to give the Yocto Project a try.
- For this example, you will be using the command line to build
- your images.
-
- A graphical user interface to the Yocto Project is available
- through
- Toaster.
- See the
- Toaster User Manual
- for more information.
-
-
-
-
- The remainder of this quick start steps you through the
- following:
-
-
- Build a qemux86 reference image
- and run it in the QEMU emulator.
-
-
- Easily change configurations so that you can quickly
- create a second image that you can load onto bootable
- media and actually boot target hardware.
- This example uses the MinnowBoard
- Turbot-compatible boards.
-
-
-
- The steps in the following two sections do not provide detail,
- but rather provide minimal, working commands and examples
- designed to just get you started.
- For more details, see the appropriate manuals in the
- Yocto Project manual set.
-
-
-
-
- Building an Image for Emulation
-
-
- Use the following commands to build your image.
- The OpenEmbedded build system creates an entire Linux
- distribution, including the toolchain, from source.
- Notes about Network Proxies
-
-
- By default, the build process searches for source
- code using a pre-determined order through a set of
- locations.
- If you are working behind a firewall and your build
- host is not set up for proxies, you could encounter
- problems with the build process when fetching source
- code (e.g. fetcher failures or Git failures).
-
-
- If you do not know your proxy settings, consult your
- local network infrastructure resources and get that
- information.
- A good starting point could also be to check your
- web browser settings.
- Finally, you can find more information on using the
- Yocto Project behind a firewall in the Yocto Project
- Reference Manual
- FAQ
- and on the
- "Working Behind a Network Proxy"
- wiki page.
-
-
-
-
-
-
-
-
- Be Sure Your Build Host is Set Up:
- The steps to build an image in this section depend on
- your build host being properly set up.
- Be sure you have worked through the requirements
- described in the
- "Setting Up to Use the Yocto Project"
- section.
-
-
- Check Out Your Branch:
- Be sure you are in the
- Source Directory
- (e.g. poky) and then check out
- the branch associated with the latest Yocto Project
- Release:
-
- $ cd ~/poky
- $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
-
- Git's checkout command checks out
- the current Yocto Project release into a local branch
- whose name matches the release (i.e.
- &DISTRO_NAME_NO_CAP;).
- The local branch tracks the upstream branch of the
- same name.
- Creating your own branch based on the released
- branch ensures you are using the latest files for
- that release.
-
-
- Initialize the Build Environment:
- Run the
- &OE_INIT_FILE;
- environment setup script to define the OpenEmbedded
- build environment on your build host.
-
- $ source &OE_INIT_FILE;
-
- Among other things, the script creates the
- Build Directory,
- which is build in this case
- and is located in the
- Source Directory.
- After the script runs, your current working directory
- is set to the Build Directory.
- Later, when the build completes, the Build Directory
- contains all the files created during the build.
-
-
- Examine Your Local Configuration File:
- When you set up the build environment, a local
- configuration file named
- local.conf becomes available in
- a conf subdirectory of the
- Build Directory.
- Before using BitBake to start the build, you can
- look at this file and be sure your general
- configurations are how you want them:
-
-
- To help conserve disk space during builds,
- you can add the following statement to your
- project's configuration file, which for this
- example is
- poky/build/conf/local.conf.
- Adding this statement deletes the work
- directory used for building a recipe once the
- recipe is built.
-
- INHERIT += "rm_work"
-
-
-
- By default, the target machine for the build is
- qemux86,
- which produces an image that can be used in
- the QEMU emulator and is targeted at an
- Intel
- 32-bit based architecture.
- Further on in this example, this default is
- easily changed through the
- MACHINE
- variable so that you can quickly
- build an image for a different machine.
-
-
- Another consideration before you build is the
- package manager used when creating the image.
- The default local.conf
- file selects the RPM package manager.
- You can control this configuration by using the
- PACKAGE_CLASSES
- variable.
- Selection of the package manager is separate
- from whether package management is used at runtime
- in the target image.
- For additional package manager selection
- information, see the
- "package.bbclass"
- section in the Yocto Project Reference Manual.
-
-
-
-
- Start the Build:
- Continue with the following command to build an OS image
- for the target, which is
- core-image-sato in this example:
-
- Depending on the number of processors and cores, the
- amount of RAM, the speed of your Internet connection
- and other factors, the build process could take
- several hours the first time you run it.
- Subsequent builds run much faster since parts of the
- build are cached.
-
-
- $ bitbake core-image-sato
-
-
-
- If you experience a build error due to resources
- temporarily being unavailable and it appears you
- should not be having this issue, it might be due
- to the combination of a 4.3+ Linux kernel and
- systemd version 228+
- (i.e. see this
- link
- for information).
-
-
-
- To work around this issue, you can try either
- of the following:
-
-
- Try the build again.
-
-
- Modify the "DefaultTasksMax"
- systemd parameter
- by uncommenting it and setting it to
- "infinity".
- You can find this parameter in the
- system.conf file
- located in
- /etc/systemd
- on most systems.
-
-
-
-
- For information on using the
- bitbake command, see the
- "BitBake"
- section in the Yocto Project Concepts Manual, or
- see the
- "BitBake Command"
- section in the BitBake User Manual.
- For information on other targets, see the
- "Images"
- chapter in the Yocto Project Reference Manual.
-
-
- Simulate Your Image Using QEMU:
- Once this particular image is built, you can start QEMU
- and run the image:
-
- $ runqemu qemux86
-
- If you want to learn more about running QEMU, see the
- "Using the Quick EMUlator (QEMU)"
- chapter in the Yocto Project Development Tasks Manual.
-
-
- Exit QEMU:
- Exit QEMU by either clicking on the shutdown icon or by
- typing Ctrl-C in the QEMU
- transcript window from which you evoked QEMU.
-
-
-
-
-
-
- Building an Image for Hardware
-
-
- The following steps show how easy it is to set up to build an
- image for a new machine.
- These steps build an image for the MinnowBoard Turbot, which is
- supported by the Yocto Project and the
- meta-intelintel-corei7-64
- and intel-core2-32 Board Support Packages
- (BSPs).
-
- The MinnowBoard Turbot ships with 64-bit firmware.
- If you want to use the board in 32-bit mode, you must
- download the
- 32-bit firmware.
-
-
-
-
-
-
- Create a Local Copy of the
- meta-intel Repository:
- Building an image for the MinnowBoard Turbot requires
- the
- meta-intel layer.
- Use the git clone command to create
- a local copy of the repository inside your
- Source Directory,
- which is poky in this example:
-
- $ cd $HOME/poky
- $ git clone git://git.yoctoproject.org/meta-intel
- Cloning into 'meta-intel'...
- remote: Counting objects: 14039, done.
- remote: Compressing objects: 100% (4471/4471), done.
- remote: Total 14039 (delta 8130), reused 13837 (delta 7947)
- Receiving objects: 100% (14039/14039), 4.27 MiB | 3.98 MiB/s, done.
- Resolving deltas: 100% (8130/8130), done.
- Checking connectivity... done.
-
- By default when you clone a Git repository, the
- "master" branch is checked out.
- Before you build your image that uses the
- meta-intel layer, you must be
- sure that both repositories
- (meta-intel and
- poky) are using the same releases.
- Because you used the &DISTRO_REL_TAG;
- tag when you checked out the poky
- repository by tag, you should use a
- meta-intel
- tag that corresponds with the release you used for
- poky.
- Consequently, you need to checkout out the
- "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
- branch after cloning meta-intel:
-
- $ cd $HOME/poky/meta-intel
- $ git checkout tags/&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION; -b meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;
- Switched to a new branch 'meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;'
-
- The previous Git checkout command
- creates a local branch named
- meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;.
- You have the option to name your local branch whatever
- you want by providing any name you like for
- "meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
- in the above example.
-
-
- Configure the Build:
- To configure the build, you edit the
- bblayers.conf and
- local.conf files, both of which are
- located in the build/conf directory.
-
-
- Here is a quick way to make the edits.
- The first command uses the
- bitbake-layers add-layer command
- to add the meta-intel
- layer, which contains the intel-core*
- BSPs to the build.
- The second command selects the BSP by setting the
- MACHINE
- variable.
-
- $ cd $HOME/poky/build
- $ bitbake-layers add-layer "$HOME/poky/meta-intel"
- $ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
-
- Notes
-
- If you want a 64-bit build, use the following:
-
- $ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
-
-
-
-
- If you want 32-bit images, use the following:
-
- $ echo 'MACHINE = "intel-core2-32"' >> conf/local.conf
-
-
-
-
-
- Build an Image for MinnowBoard
- Turbot:
- The type of image you build depends on your goals.
- For example, the previous build created a
- core-image-sato image, which is an
- image with Sato support.
- It is possible to build many image types for the
- MinnowBoard Turbot.
- Some possibilities are core-image-base,
- which is a console-only image.
- Another choice could be a
- core-image-full-cmdline, which is
- another console-only image but has more full-features
- Linux system functionality installed.
- For types of images you can build using the Yocto
- Project, see the
- "Images"
- chapter in the Yocto Project Reference Manual.
- Because configuration changes are minimal to set up
- for this second build, the OpenEmbedded build system can
- re-use files from previous builds as much as possible.
- Re-using files means this second build will be much faster
- than an initial build.
- For this example, the core-image-base
- image is built:
-
- $ bitbake core-image-base
-
-
-
- If you experience a build error due to resources
- temporarily being unavailable and it appears you
- should not be having this issue, it might be due
- to the combination of a 4.3+ Linux kernel and
- systemd version 228+
- (i.e. see this
- link
- for information).
-
-
-
- To work around this issue, you can try either
- of the following:
-
-
- Try the build again.
-
-
- Modify the "DefaultTasksMax"
- systemd parameter
- by uncommenting it and setting it to
- "infinity".
- You can find this parameter in the
- system.conf file
- located in
- /etc/systemd
- on most systems.
-
-
-
-
- Once the build completes, the resulting console-only image
- is located in the Build Directory here:
-
- tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.wic
-
-
-
- Write the Image:
- You can write the image just built to a bootable media
- (e.g. a USB key, SATA drive, SD card, etc.) using the
- dd utility:
-
- $ sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.wic of=TARGET_DEVICE
-
- In the previous command, the
- TARGET_DEVICE is the device node in
- the host machine (e.g. /dev/sdc, which
- is most likely a USB stick, or
- /dev/mmcblk0, which is most likely an
- SD card).
-
-
- Boot the Hardware:
- With the boot device provisioned, you can insert the
- media into the MinnowBoard Turbot and boot the hardware.
- The board should automatically detect the media and boot to
- the bootloader and subsequently the operating system.
-
-
- If the board does not boot automatically, you can
- boot it manually from the EFI shell as follows:
-
- Shell> connect -r
- Shell> map -r
- Shell> fs0:
- Shell> bootx64
-
-
- For a 32-bit image use the following:
-
- Shell> bootia32
-
-
-
-
-
-
-
-
-
-
- Where To Go Next
-
-
- Now that you have experienced using the Yocto Project, you might
- be asking yourself "What now?"
- This next section of the Quick Start provides some "sign posts"
- that can help you find additional information depending on what
- you want to accomplish with the Yocto Project.
- The section provides a list of resources for more information,
- some links into sections that provide basic tasks, and some
- links into more specialized areas that go beyond building images.
-
- You can also see the
- page for
- suggested sets of Yocto Project manuals designed for various
- levels of experience.
-
-
-
-
- Additional Resources
-
-
- The Yocto Project has many sources of information including
- the website, wiki pages, and user manuals.
- This section lists resources you might find helpful:
-
-
- Website:
- The
- Yocto Project Website
- provides background information, the latest builds,
- breaking news, full development documentation, and
- access to a rich Yocto Project Development Community
- into which you can tap.
-
-
- FAQs:
- Lists commonly asked Yocto Project questions and
- answers.
- You can find two FAQs:
- Yocto Project FAQ
- on a wiki, and the
- "FAQ"
- chapter in the Yocto Project Reference Manual.
-
-
- Developer Screencast:
- The
- Getting Started with the Yocto Project - New Developer Screencast Tutorial
- provides a 30-minute video created for users unfamiliar
- with the Yocto Project but familiar with Linux build
- hosts.
- While this screencast is somewhat dated, the
- introductory and fundamental concepts are useful for
- the beginner.
-
-
- Yocto Project Implementation of Bugzilla:
- The Yocto Project uses its own implementation of
- Bugzilla that you can find
- here.
- Bugzilla allows you to report and track the progress
- of defects and improvements to the Yocto Project.
-
-
- Yocto Project Wiki:
- The
- Yocto Project Wiki
- provides additional information on where to go next
- when ramping up with the Yocto Project, release
- information, project planning, and QA information.
-
-
- Yocto Project Mailing Lists:
- Related mailing lists provide a forum for discussion,
- patch submission and announcements.
- Several mailing lists exist and are grouped according
- to areas of concern.
- See the
- "Mailing lists"
- section in the Yocto Project Reference Manual for a
- complete list of Yocto Project mailing lists.
-
-
- Comprehensive List of Links and Other Documentation:
- The
- "Links and Related Documentation"
- section in the Yocto Project Reference Manual provides a
- comprehensive list of all related links and other
- user documentation.
-
-
-
-
-
-
- Guided Examples
-
-
- Depending on what you primary interests are with the Yocto
- Project, you could consider any of the following:
-
-
- Add a Layer for Hardware Support:
- For steps on how to add a Board Support Package (BSP)
- layer that supports specific hardware, see the
- "Creating a new BSP Layer Using the bitbake-layers Script"
- section in the Yocto Project Board Support Package
- (BSP) Developer's Guide.
- For background information on BSP layers, see the
- "BSP Layers"
- section in the same manual.
-
-
- Create a Layer for Software:
- For steps on how to create a general layer for software,
- see the
- "Creating a General Layer Using the bitbake-layers Script"
- section in the Yocto Project Development Tasks Manual.
- For background information on layers in general, see the
- "Understanding and Creating Layers"
- section in the same manual.
-
-
- Write a New Recipe:
- For steps on how to write a new recipe,
- see the
- "Writing a New Recipe"
- section in the Yocto Project Development Tasks Manual.
-
-
- Create a Layer for Customizations:
- This is a step suggested by Richard.
- I don't know the distinction between creating a layer
- for customizations and creating a general layer as
- pointed out earlier for creating a general layer
- (i.e. a layer for software).
- I need some help on this bullet item.
-
-
- Add a Custom Kernel:
- For steps on how to modify and create your own custom
- kernel, see the
- "Using devtool to Patch the Kernel"
- section in the Yocto Project Linux Kernel Development
- Manual.
-
-
- Change the Default Kernel Configuration:
- For steps on how to configure the kernel, see the
- "Configuring the Kernel"
- section in the Yocto Project Linux Kernel Development
- Manual.
-
-
- Submit a Change to the Yocto Project:
- For steps on how to submit a change or patch to the
- Yocto Project, see the
- "Submitting a Change to the Yocto Project"
- section in the Yocto Project Development Tasks Manual.
-
-
-
-
-
-
- Going Beyond Builds
-
-
- This section presents some pointers to topics that go beyond
- building images:
-
-
- The OpenEmbedded Layer Index:
- This index shows layers that exist for use with the
- Yocto Project.
- More times than not, you can find layers for your own
- use or layers that are close to what you need and can
- be leveraged when creating your own layers.
- See
- http://layers.openembedded.org/layerindex/branch/master/layers/
- for the layer index.
-
-
- Yocto Project Autobuilder:
- Autobuilders provide automatic building in a
- development or production environment.
- For information on the autobuilders used by the Yocto
- Project, see the
- "Setting Up a Team Yocto Project Development Environment"
- section of the Yocto Project Development Tasks Manual.
- You can also see the
- http://autobuilder.yoctoproject.org/
- link.
-
-
- Yocto Project Compatibility:
- When you create layers, you can take steps to make sure
- your layer is compatible with the Yocto Project.
- See the
- "Making Sure Your Layer is Compatible With Yocto Project"
- section in the Yocto Project Development Tasks Manual
- for more information.
-
-
- Auto Upgrade Tools:
- Tools exits to help ease upgrading recipe versions.
- In particular, you can use the
- Auto Upgrade Helper (AUH)
- and
- devtool upgrade
- to upgrade recipes to newer versions.
-
-
- Patches and Patchwork:
- This is a step suggested by Richard.
- I don't know what this is and need help with this
- bullet item.
-
-
- Pseudo:
- Pseudo gives the illusion of running under root and is
- used by the OpenEmbedded build system during the image
- generation process.
- For information on Fakeroot and Pseudo, see the
- "Fakeroot and Pseudo"
- section in the Yocto Project Concepts Manual.
-
-
- OPKG:
- OPKG is a file management system.
- I am not sure what Richard had in mind for suggesting
- this "beyond builds" topic.
- I have one reference at
- "Using IPK"
- in the Yocto Project Development Tasks Manual that
- is the bulk of my known information.
- I need more help with this bullet item.
-
-
- Team Yocto Project Development Environments:
- For information on Yocto Project development team
- environments, see the
- "Setting Up a Team Yocto Project Development Environment"
- section in the Yocto Project Development Tasks Manual.
-
-
-
-
-
-
-
diff --git a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
deleted file mode 100644
index 3372c7a7c3..0000000000
--- a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
+++ /dev/null
@@ -1,37 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl
deleted file mode 100644
index 50e6830dde..0000000000
--- a/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/documentation/yocto-project-qs/yocto-project-qs-titlepage.xsl b/documentation/yocto-project-qs/yocto-project-qs-titlepage.xsl
deleted file mode 100644
index a435ac77ab..0000000000
--- a/documentation/yocto-project-qs/yocto-project-qs-titlepage.xsl
+++ /dev/null
@@ -1,3820 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-