blob: acb3f455c508007a36cad742279b3858d0726096 [file] [log] [blame]
Andrew Geisslerf0343792020-11-18 10:42:21 -06001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002
3************
4Introduction
5************
6
7.. _sdk-manual-intro:
8
9eSDK Introduction
10=================
11
12Welcome to the Yocto Project Application Development and the Extensible
13Software Development Kit (eSDK) manual. This manual provides information
14that explains how to use both the Yocto Project extensible and standard
15SDKs to develop applications and images.
16
17.. note::
18
19 Prior to the 2.0 Release of the Yocto Project, application
20 development was primarily accomplished through the use of the
21 Application Development Toolkit (ADT) and the availability of
22 stand-alone cross-development toolchains and other tools. With the
23 2.1 Release of the Yocto Project, application development has
24 transitioned to within a tool-rich extensible SDK and the more
25 traditional standard SDK.
26
27All SDKs consist of the following:
28
29- *Cross-Development Toolchain*: This toolchain contains a compiler,
30 debugger, and various miscellaneous tools.
31
32- *Libraries, Headers, and Symbols*: The libraries, headers, and
33 symbols are specific to the image (i.e. they match the image).
34
35- *Environment Setup Script*: This ``*.sh`` file, once run, sets up the
36 cross-development environment by defining variables and preparing for
37 SDK use.
38
39Additionally, an extensible SDK has tools that allow you to easily add
40new applications and libraries to an image, modify the source of an
41existing component, test changes on the target hardware, and easily
42integrate an application into the :term:`OpenEmbedded Build System`.
43
44You can use an SDK to independently develop and test code that is
45destined to run on some target machine. SDKs are completely
46self-contained. The binaries are linked against their own copy of
47``libc``, which results in no dependencies on the target system. To
48achieve this, the pointer to the dynamic loader is configured at install
49time since that path cannot be dynamically altered. This is the reason
50for a wrapper around the ``populate_sdk`` and ``populate_sdk_ext``
51archives.
52
53Another feature for the SDKs is that only one set of cross-compiler
54toolchain binaries are produced for any given architecture. This feature
55takes advantage of the fact that the target hardware can be passed to
56``gcc`` as a set of compiler options. Those options are set up by the
57environment script and contained in variables such as
58:term:`CC` and
59:term:`LD`. This reduces the space needed
60for the tools. Understand, however, that every target still needs a
61sysroot because those binaries are target-specific.
62
63The SDK development environment consists of the following:
64
65- The self-contained SDK, which is an architecture-specific
66 cross-toolchain and matching sysroots (target and native) all built
67 by the OpenEmbedded build system (e.g. the SDK). The toolchain and
68 sysroots are based on a :term:`Metadata`
69 configuration and extensions, which allows you to cross-develop on
70 the host machine for the target hardware. Additionally, the
71 extensible SDK contains the ``devtool`` functionality.
72
73- The Quick EMUlator (QEMU), which lets you simulate target hardware.
74 QEMU is not literally part of the SDK. You must build and include
75 this emulator separately. However, QEMU plays an important role in
76 the development process that revolves around use of the SDK.
77
78In summary, the extensible and standard SDK share many features.
79However, the extensible SDK has powerful development tools to help you
80more quickly develop applications. Following is a table that summarizes
81the primary differences between the standard and extensible SDK types
82when considering which to build:
83
84+-----------------------+-----------------------+-----------------------+
85| *Feature* | *Standard SDK* | *Extensible SDK* |
86+=======================+=======================+=======================+
Andrew Geissler4c19ea12020-10-27 13:52:24 -050087| Toolchain | Yes | Yes [1]_ |
Andrew Geisslerc9f78652020-09-18 14:11:35 -050088+-----------------------+-----------------------+-----------------------+
Andrew Geissler4c19ea12020-10-27 13:52:24 -050089| Debugger | Yes | Yes [1]_ |
Andrew Geisslerc9f78652020-09-18 14:11:35 -050090+-----------------------+-----------------------+-----------------------+
91| Size | 100+ MBytes | 1+ GBytes (or 300+ |
92| | | MBytes for minimal |
93| | | w/toolchain) |
94+-----------------------+-----------------------+-----------------------+
95| ``devtool`` | No | Yes |
96+-----------------------+-----------------------+-----------------------+
97| Build Images | No | Yes |
98+-----------------------+-----------------------+-----------------------+
99| Updateable | No | Yes |
100+-----------------------+-----------------------+-----------------------+
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500101| Managed Sysroot [2]_ | No | Yes |
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500102+-----------------------+-----------------------+-----------------------+
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500103| Installed Packages | No [3]_ | Yes [4]_ |
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500104+-----------------------+-----------------------+-----------------------+
105| Construction | Packages | Shared State |
106+-----------------------+-----------------------+-----------------------+
107
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500108.. [1] Extensible SDK contains the toolchain and debugger if :term:`SDK_EXT_TYPE`
109 is "full" or :term:`SDK_INCLUDE_TOOLCHAIN` is "1", which is the default.
110.. [2] Sysroot is managed through the use of ``devtool``. Thus, it is less
111 likely that you will corrupt your SDK sysroot when you try to add
112 additional libraries.
113.. [3] You can add runtime package management to the standard SDK but it is not
114 supported by default.
115.. [4] You must build and make the shared state available to extensible SDK
116 users for "packages" you want to enable users to install.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500117
118The Cross-Development Toolchain
119-------------------------------
120
121The :term:`Cross-Development Toolchain` consists
122of a cross-compiler, cross-linker, and cross-debugger that are used to
123develop user-space applications for targeted hardware. Additionally, for
124an extensible SDK, the toolchain also has built-in ``devtool``
125functionality. This toolchain is created by running a SDK installer
126script or through a :term:`Build Directory` that is based on
127your metadata configuration or extension for your targeted device. The
128cross-toolchain works with a matching target sysroot.
129
130.. _sysroot:
131
132Sysroots
133--------
134
135The native and target sysroots contain needed headers and libraries for
136generating binaries that run on the target architecture. The target
137sysroot is based on the target root filesystem image that is built by
138the OpenEmbedded build system and uses the same metadata configuration
139used to build the cross-toolchain.
140
141The QEMU Emulator
142-----------------
143
144The QEMU emulator allows you to simulate your hardware while running
145your application or image. QEMU is not part of the SDK but is made
146available a number of different ways:
147
148- If you have cloned the ``poky`` Git repository to create a
149 :term:`Source Directory` and you have
150 sourced the environment setup script, QEMU is installed and
151 automatically available.
152
153- If you have downloaded a Yocto Project release and unpacked it to
154 create a Source Directory and you have sourced the environment setup
155 script, QEMU is installed and automatically available.
156
157- If you have installed the cross-toolchain tarball and you have
158 sourced the toolchain's setup environment script, QEMU is also
159 installed and automatically available.
160
161SDK Development Model
162=====================
163
164Fundamentally, the SDK fits into the development process as follows:
165
166.. image:: figures/sdk-environment.png
167 :align: center
168
169The SDK is installed on any machine and can be used to develop applications,
170images, and kernels. An SDK can even be used by a QA Engineer or Release
171Engineer. The fundamental concept is that the machine that has the SDK
172installed does not have to be associated with the machine that has the
173Yocto Project installed. A developer can independently compile and test
174an object on their machine and then, when the object is ready for
175integration into an image, they can simply make it available to the
176machine that has the Yocto Project. Once the object is available, the
177image can be rebuilt using the Yocto Project to produce the modified
178image.
179
180You just need to follow these general steps:
181
1821. *Install the SDK for your target hardware:* For information on how to
183 install the SDK, see the "`Installing the
184 SDK <#sdk-installing-the-sdk>`__" section.
185
1862. *Download or Build the Target Image:* The Yocto Project supports
187 several target architectures and has many pre-built kernel images and
188 root filesystem images.
189
190 If you are going to develop your application on hardware, go to the
Andrew Geisslerc3d88e42020-10-02 09:45:00 -0500191 :yocto_dl:`machines </releases/yocto/yocto-3.1.2/machines/>` download area and choose a
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500192 target machine area from which to download the kernel image and root
193 filesystem. This download area could have several files in it that
194 support development using actual hardware. For example, the area
195 might contain ``.hddimg`` files that combine the kernel image with
196 the filesystem, boot loaders, and so forth. Be sure to get the files
197 you need for your particular development process.
198
199 If you are going to develop your application and then run and test it
200 using the QEMU emulator, go to the
Andrew Geisslerc3d88e42020-10-02 09:45:00 -0500201 :yocto_dl:`machines/qemu </releases/yocto/yocto-3.1.2/machines/qemu>` download area. From this
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500202 area, go down into the directory for your target architecture (e.g.
203 ``qemux86_64`` for an Intel-based 64-bit architecture). Download the
204 kernel, root filesystem, and any other files you need for your
205 process.
206
207 .. note::
208
209 To use the root filesystem in QEMU, you need to extract it. See
210 the "
211 Extracting the Root Filesystem
212 " section for information on how to extract the root filesystem.
213
2143. *Develop and Test your Application:* At this point, you have the
215 tools to develop your application. If you need to separately install
216 and use the QEMU emulator, you can go to `QEMU Home
217 Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
218 the emulator. See the ":doc:`../dev-manual/dev-manual-qemu`" chapter in the
219 Yocto Project Development Tasks Manual for information on using QEMU
220 within the Yocto Project.
221
222The remainder of this manual describes how to use the extensible and
223standard SDKs. Information also exists in appendix form that describes
224how you can build, install, and modify an SDK.