diff options
| author | Scott Rifenbark <srifenbark@gmail.com> | 2018-02-09 12:43:21 -0800 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2018-02-14 15:25:32 +0000 |
| commit | 4b3ebf00dc8eac6061ff077cff488f70c641d16e (patch) | |
| tree | d0f2e8b265459d777c659552feda226617212138 /documentation | |
| parent | 31f0dda70b6a53a78780c800a17bedc8ed95939e (diff) | |
| download | poky-4b3ebf00dc8eac6061ff077cff488f70c641d16e.tar.gz | |
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>
Diffstat (limited to 'documentation')
| -rw-r--r-- | documentation/Makefile | 4 | ||||
| -rw-r--r-- | documentation/getting-started/figures/key-dev-elements.png | bin | 0 -> 17052 bytes | |||
| -rw-r--r-- | documentation/getting-started/getting-started-yp-intro.xml | 255 | ||||
| -rw-r--r-- | documentation/mega-manual/figures/key-dev-elements.png | bin | 0 -> 17052 bytes |
4 files changed, 257 insertions, 2 deletions
diff --git a/documentation/Makefile b/documentation/Makefile index 9e0ba56df3..f2afc23628 100644 --- a/documentation/Makefile +++ b/documentation/Makefile | |||
| @@ -89,7 +89,7 @@ XSLTOPTS = --xinclude | |||
| 89 | ALLPREQ = html eclipse tarball | 89 | ALLPREQ = html eclipse tarball |
| 90 | TARFILES = getting-started-style.css getting-started.html figures/getting-started-title.png \ | 90 | TARFILES = getting-started-style.css getting-started.html figures/getting-started-title.png \ |
| 91 | figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \ | 91 | figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \ |
| 92 | figures/yp-download.png figures/YP-flow-diagram.png \ | 92 | figures/yp-download.png figures/YP-flow-diagram.png figures/key-dev-elements.png \ |
| 93 | eclipse | 93 | eclipse |
| 94 | MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse | 94 | MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse |
| 95 | FIGURES = figures | 95 | FIGURES = figures |
| @@ -270,7 +270,7 @@ TARFILES = mega-manual.html mega-style.css \ | |||
| 270 | figures/source-fetching.png figures/patching.png \ | 270 | figures/source-fetching.png figures/patching.png \ |
| 271 | figures/configuration-compile-autoreconf.png \ | 271 | figures/configuration-compile-autoreconf.png \ |
| 272 | figures/analysis-for-package-splitting.png \ | 272 | figures/analysis-for-package-splitting.png \ |
| 273 | figures/image-generation.png \ | 273 | figures/image-generation.png figures/key-dev-elements.png\ |
| 274 | figures/sdk-generation.png figures/recipe-workflow.png \ | 274 | figures/sdk-generation.png figures/recipe-workflow.png \ |
| 275 | figures/build-workspace-directory.png figures/mega-title.png \ | 275 | figures/build-workspace-directory.png figures/mega-title.png \ |
| 276 | figures/toaster-title.png figures/hosted-service.png \ | 276 | figures/toaster-title.png figures/hosted-service.png \ |
diff --git a/documentation/getting-started/figures/key-dev-elements.png b/documentation/getting-started/figures/key-dev-elements.png new file mode 100644 index 0000000000..ce22b98ed0 --- /dev/null +++ b/documentation/getting-started/figures/key-dev-elements.png | |||
| Binary files differ | |||
diff --git a/documentation/getting-started/getting-started-yp-intro.xml b/documentation/getting-started/getting-started-yp-intro.xml index a3ef4fcfec..8ea11baa75 100644 --- a/documentation/getting-started/getting-started-yp-intro.xml +++ b/documentation/getting-started/getting-started-yp-intro.xml | |||
| @@ -8,6 +8,261 @@ | |||
| 8 | <section id='what-is-the-yocto-project'> | 8 | <section id='what-is-the-yocto-project'> |
| 9 | <title>What is the Yocto Project?</title> | 9 | <title>What is the Yocto Project?</title> |
| 10 | 10 | ||
| 11 | <para> | ||
| 12 | The Yocto Project is an open source collaboration project | ||
| 13 | that helps developers create custom Linux-based systems that are | ||
| 14 | designed for embedded products regardless of the product's hardware | ||
| 15 | architecture. | ||
| 16 | Yocto Project provides a flexible toolset and a development | ||
| 17 | environment that allows embedded device developers across the | ||
| 18 | world to collaborate through shared technologies, software stacks, | ||
| 19 | configurations, and best practices used to create these tailored | ||
| 20 | Linux images. | ||
| 21 | </para> | ||
| 22 | |||
| 23 | <para> | ||
| 24 | Thousands of developers worldwide have discovered that Yocto | ||
| 25 | Project provides advantages in both systems and applications | ||
| 26 | development, archival and management benefits, and customizations | ||
| 27 | used for speed, footprint, and memory utilization. | ||
| 28 | The project is a standard when it comes to delivering hardware | ||
| 29 | support and software stacks, allowing software configuration | ||
| 30 | and build interchange, and build and support customizations for | ||
| 31 | multiple hardware platforms and software stacks that can be | ||
| 32 | maintained and scaled. | ||
| 33 | </para> | ||
| 34 | |||
| 35 | <mediaobject> | ||
| 36 | <imageobject> | ||
| 37 | <imagedata fileref="figures/key-dev-elements.png" | ||
| 38 | format="PNG" align='center' width="8in"/> | ||
| 39 | </imageobject> | ||
| 40 | </mediaobject> | ||
| 41 | |||
| 42 | <para> | ||
| 43 | For further introductory information on the Yocto Project, you | ||
| 44 | might be interested in this | ||
| 45 | <ulink url='https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project-'>article</ulink> | ||
| 46 | by Drew Moseley and in this short introductory | ||
| 47 | <ulink url='https://www.youtube.com/watch?v=utZpKM7i5Z4'>video</ulink>. | ||
| 48 | </para> | ||
| 49 | |||
| 50 | <para> | ||
| 51 | The remainder of this section overviews advantages and challenges | ||
| 52 | tied to the Yocto Project. | ||
| 53 | </para> | ||
| 54 | |||
| 55 | <section id='gs-features'> | ||
| 56 | <title>Features</title> | ||
| 57 | |||
| 58 | <para> | ||
| 59 | The following list describes features and advantages of the | ||
| 60 | Yocto Project: | ||
| 61 | <itemizedlist> | ||
| 62 | <listitem><para> | ||
| 63 | <emphasis>Widely Adopted Across the Industry:</emphasis> | ||
| 64 | Semiconductor, operating system, software, and | ||
| 65 | service vendors exist whose products and services | ||
| 66 | adopt and support the Yocto Project. | ||
| 67 | For a look at the companies involved with the Yocto | ||
| 68 | Project, see the membership, associate, and | ||
| 69 | participant pages on the Yocto Project home page. | ||
| 70 | </para></listitem> | ||
| 71 | <listitem><para> | ||
| 72 | <emphasis>Architecture Agnostic:</emphasis> | ||
| 73 | Yocto Project supports Intel, ARM, MIPS, AMD, PPC | ||
| 74 | and other architectures. | ||
| 75 | Most ODMs, OSVs, and chip vendors create and supply | ||
| 76 | BSPs that support their hardware. | ||
| 77 | If you have custom silicon, you can create a BSP | ||
| 78 | that supports that architecture. | ||
| 79 | </para></listitem> | ||
| 80 | <listitem><para> | ||
| 81 | <emphasis>Images and Code Transfer Easily:</emphasis> | ||
| 82 | Yocto Project output can easily move between | ||
| 83 | architectures without moving to new development | ||
| 84 | environments. | ||
| 85 | Additionally, if you have used the Yocto Project to | ||
| 86 | create an image or application and you find yourself | ||
| 87 | not able to support it, commercial Linux vendors such | ||
| 88 | as Wind River, Mentor Graphics, Timesys, and ENEA could | ||
| 89 | take it and provide ongoing support. | ||
| 90 | These vendors have offerings that are built using | ||
| 91 | the Yocto Project. | ||
| 92 | </para></listitem> | ||
| 93 | <listitem><para> | ||
| 94 | <emphasis>Flexibility:</emphasis> | ||
| 95 | Corporations use the Yocto Project many different ways. | ||
| 96 | One example is to create an internal Linux distribution | ||
| 97 | as a code base the corporation can use across multiple | ||
| 98 | product groups. | ||
| 99 | Through customization and layering, a project group | ||
| 100 | can leverage the base Linux distribution to create | ||
| 101 | a distribution that works for their product needs. | ||
| 102 | </para></listitem> | ||
| 103 | <listitem><para> | ||
| 104 | <emphasis>Ideal for Constrained Embedded and IoT devices:</emphasis> | ||
| 105 | Unlike a full Linux distribution, you can use the | ||
| 106 | Yocto Project to create exactly what you need for | ||
| 107 | embedded devices. | ||
| 108 | You only add the feature support or packages that you | ||
| 109 | absolutely need for the device. | ||
| 110 | </para></listitem> | ||
| 111 | <listitem><para> | ||
| 112 | <emphasis>Comprehensive Toolchain Capabilities:</emphasis> | ||
| 113 | Toolchains for supported architectures satisfy most | ||
| 114 | use cases. | ||
| 115 | However, if your hardware supports features that are | ||
| 116 | not part of a standard toolchain, you can easily | ||
| 117 | customize that toolchain through specification of | ||
| 118 | platform-specific tuning parameters. | ||
| 119 | And, should you need to use a third-party toolchain, | ||
| 120 | mechanisms built into the Yocto Project allow for that. | ||
| 121 | </para></listitem> | ||
| 122 | <listitem><para> | ||
| 123 | <emphasis>Mechanism Rules Over Policy:</emphasis> | ||
| 124 | Focusing on mechanism rather than policy ensures that | ||
| 125 | you are free to set policies based on the needs of your | ||
| 126 | design instead of adopting decisions enforced by some | ||
| 127 | system software provider. | ||
| 128 | </para></listitem> | ||
| 129 | <listitem><para> | ||
| 130 | <emphasis>Uses a Layer Model:</emphasis> | ||
| 131 | The Yocto Project layer infrastructure groups related | ||
| 132 | functionality into separate bundles. | ||
| 133 | You can incrementally add these grouped functionalities | ||
| 134 | to your project as needed. | ||
| 135 | Using layers to isolate and group functionality | ||
| 136 | reduces project complexity and redundancy. | ||
| 137 | </para></listitem> | ||
| 138 | <listitem><para> | ||
| 139 | <emphasis>Supports Partial Builds:</emphasis> | ||
| 140 | You can build and rebuild individual packages as | ||
| 141 | needed. | ||
| 142 | Yocto Project accomplishes this through its | ||
| 143 | shared-state cache (sstate) scheme. | ||
| 144 | Being able to build and debug components individually | ||
| 145 | eases project development. | ||
| 146 | </para></listitem> | ||
| 147 | <listitem><para> | ||
| 148 | <emphasis>Releases According to a Strict Schedule:</emphasis> | ||
| 149 | Major releases occur on a six-month cycle predictably | ||
| 150 | in October and April. | ||
| 151 | The most recent two releases support point releases | ||
| 152 | to address common vulnerabilities and exposures. | ||
| 153 | This predictability is crucial for projects based on | ||
| 154 | the Yocto Project and allows development teams to | ||
| 155 | plan activities. | ||
| 156 | </para></listitem> | ||
| 157 | <listitem><para> | ||
| 158 | <emphasis>Rich Ecosystem of Individuals and Organizations:</emphasis> | ||
| 159 | For open source projects, the value of community is | ||
| 160 | very important. | ||
| 161 | Support forums, expertise, and active developers who | ||
| 162 | continue to push the Yocto Project forward are readily | ||
| 163 | available. | ||
| 164 | </para></listitem> | ||
| 165 | <listitem><para> | ||
| 166 | <emphasis>Binary Reproducibility:</emphasis> | ||
| 167 | The Yocto Project you to be very specific about | ||
| 168 | dependencies and achieves very high percentages of | ||
| 169 | binary reproducibility (e.g. 99.8% for | ||
| 170 | <filename>core-image-minimal</filename>). | ||
| 171 | When distributions are not specific about which | ||
| 172 | packages are pulled in and in what order to support | ||
| 173 | dependencies, other build systems can arbitrarily | ||
| 174 | include packages. | ||
| 175 | </para></listitem> | ||
| 176 | <listitem><para> | ||
| 177 | <emphasis>License Manifest:</emphasis> | ||
| 178 | The Yocto Project provides a license manifest for | ||
| 179 | review by people that need to track the use of open | ||
| 180 | source licenses (e.g.legal teams). | ||
| 181 | </para></listitem> | ||
| 182 | </itemizedlist> | ||
| 183 | </para> | ||
| 184 | </section> | ||
| 185 | |||
| 186 | <section id='gs-challenges'> | ||
| 187 | <title>Challenges</title> | ||
| 188 | |||
| 189 | <para> | ||
| 190 | The following list presents challenges you might encounter | ||
| 191 | when developing using the Yocto Project: | ||
| 192 | <itemizedlist> | ||
| 193 | <listitem><para> | ||
| 194 | <emphasis>Steep Learning Curve:</emphasis> | ||
| 195 | The Yocto Project has a steep learning curve and has | ||
| 196 | many different ways to accomplish similar tasks. | ||
| 197 | It can be difficult to choose how to proceed when | ||
| 198 | varying methods exist by which to accomplish a given | ||
| 199 | task. | ||
| 200 | </para></listitem> | ||
| 201 | <listitem><para> | ||
| 202 | <emphasis>Understanding What Changes You Need to Make | ||
| 203 | For Your Design Requires Some Research:</emphasis> | ||
| 204 | Beyond the simple tutorial stage, understanding what | ||
| 205 | changes need to be made for your particular design | ||
| 206 | can require a significant amount of research and | ||
| 207 | investigation. | ||
| 208 | For information that helps you transition from | ||
| 209 | trying out the Yocto Project to using it for your | ||
| 210 | project, see the "What I wish I'd Known" and | ||
| 211 | "Transitioning to a Custom Environment for Systems | ||
| 212 | Development" documents on the Yocto Project website. | ||
| 213 | </para></listitem> | ||
| 214 | <listitem><para> | ||
| 215 | <emphasis>Project Workflow Could Be Confusing:</emphasis> | ||
| 216 | The Yocto Project workflow could be confusing if you | ||
| 217 | used to traditional desktop and server software | ||
| 218 | development. | ||
| 219 | In a desktop development environment, mechanisms exist | ||
| 220 | to easily pull and install new packages, which are | ||
| 221 | typically pre-compiled binaries from servers accessible | ||
| 222 | over the Internet. | ||
| 223 | Using the Yocto Project, you must modify your | ||
| 224 | configuration and rebuild to add additional packages. | ||
| 225 | </para></listitem> | ||
| 226 | <listitem><para> | ||
| 227 | <emphasis>Working in a Cross-Build Environment Can | ||
| 228 | Feel Unfamiliar:</emphasis> | ||
| 229 | When developing code to run on a target, compilation, | ||
| 230 | execution, and testing done on the actual target | ||
| 231 | can be faster than running a BitBake build on a | ||
| 232 | development host and then deploying binaries to the | ||
| 233 | target for test. | ||
| 234 | While the Yocto Project does support development tools | ||
| 235 | on the target, the additional step of integrating your | ||
| 236 | changes back into the Yocto Project build environment | ||
| 237 | would be required. | ||
| 238 | Yocto Project supports an intermediate approach that | ||
| 239 | involves making changes on the development system | ||
| 240 | within the BitBake environment and then deploying only | ||
| 241 | the updated packages to the target.</para> | ||
| 242 | |||
| 243 | <para>The Yocto Project OpenEmbedded build system | ||
| 244 | produces packages in standard formats (i.e. RPM, | ||
| 245 | DEB, IPK, and TAR). | ||
| 246 | You can deploy these packages into the running system | ||
| 247 | on the target by using utilities on the target such | ||
| 248 | as <filename>rpm</filename> or | ||
| 249 | <filename>ipk</filename>. | ||
| 250 | </para></listitem> | ||
| 251 | <listitem><para> | ||
| 252 | <emphasis>Initial Build Times Can be Significant:</emphasis> | ||
| 253 | Long initial build times are unfortunately unavoidable | ||
| 254 | due to the large number of packages initially built | ||
| 255 | from scratch for a fully functioning Linux system. | ||
| 256 | Once that initial build is completed, however, the | ||
| 257 | shared-state (sstate) cache mechanism Yocto Project | ||
| 258 | uses keeps the system from rebuilding packages that | ||
| 259 | have not been "touched" since the last build. | ||
| 260 | The sstate mechanism significantly reduces times | ||
| 261 | for successive builds. | ||
| 262 | </para></listitem> | ||
| 263 | </itemizedlist> | ||
| 264 | </para> | ||
| 265 | </section> | ||
| 11 | </section> | 266 | </section> |
| 12 | 267 | ||
| 13 | <section id='what-are-layers'> | 268 | <section id='what-are-layers'> |
diff --git a/documentation/mega-manual/figures/key-dev-elements.png b/documentation/mega-manual/figures/key-dev-elements.png new file mode 100644 index 0000000000..ce22b98ed0 --- /dev/null +++ b/documentation/mega-manual/figures/key-dev-elements.png | |||
| Binary files differ | |||
