appendix-obtain.rst 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306
  1. .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
  2. *****************
  3. Obtaining the SDK
  4. *****************
  5. Working with the SDK components directly in a Yocto build
  6. =========================================================
  7. Please refer to section
  8. ":ref:`sdk-manual/extensible:Setting up the Extensible SDK environment directly in a Yocto build`"
  9. Note that to use this feature effectively either a powerful build
  10. machine, or a well-functioning sstate cache infrastructure is required:
  11. otherwise significant time could be spent waiting for components to be built
  12. by BitBake from source code.
  13. Working with standalone SDK Installers
  14. ======================================
  15. Locating Pre-Built SDK Installers
  16. ---------------------------------
  17. You can use existing, pre-built toolchains by locating and running an
  18. SDK installer script that ships with the Yocto Project. Using this
  19. method, you select and download an architecture-specific SDK installer
  20. and then run the script to hand-install the toolchain.
  21. Follow these steps to locate and hand-install the toolchain:
  22. #. *Go to the Installers Directory:* Go to
  23. :yocto_dl:`/releases/yocto/&DISTRO_REL_LATEST_TAG;/toolchain/`
  24. #. *Open the Folder for Your Build Host:* Open the folder that matches
  25. your :term:`Build Host` (i.e.
  26. ``i686`` for 32-bit machines or ``x86_64`` for 64-bit machines).
  27. #. *Locate and Download the SDK Installer:* You need to find and
  28. download the installer appropriate for your build host, target
  29. hardware, and image type.
  30. The installer files (``*.sh``) follow this naming convention:
  31. ``poky-glibc-host_system-core-image-type-arch-toolchain[-ext]-release.sh``:
  32. - ``host_system``: string representing your development system: ``i686`` or ``x86_64``
  33. - ``type``: string representing the image: ``sato`` or ``minimal``
  34. - ``arch``: string representing the target architecture such as ``cortexa57-qemuarm64``
  35. - ``release``: version of the Yocto Project.
  36. .. note::
  37. The standard SDK installer does not have the ``-ext`` string as
  38. part of the filename.
  39. The toolchains provided by the Yocto
  40. Project are based off of the ``core-image-sato`` and
  41. ``core-image-minimal`` images and contain libraries appropriate for
  42. developing against those images.
  43. For example, if your build host is a 64-bit x86 system and you need
  44. an extended SDK for a 64-bit core2 QEMU target, go into the ``x86_64``
  45. folder and download the following installer::
  46. poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh
  47. #. *Run the Installer:* Be sure you have execution privileges and run
  48. the installer. Here is an example from the ``Downloads``
  49. directory::
  50. $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh
  51. During execution of the script, you choose the root location for the
  52. toolchain. See the
  53. ":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`"
  54. section and the
  55. ":ref:`sdk-manual/appendix-obtain:installed extensible sdk directory structure`"
  56. section for more information.
  57. Building an SDK Installer
  58. -------------------------
  59. As an alternative to locating and downloading an SDK installer, you can
  60. build the SDK installer. Follow these steps:
  61. #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
  62. in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
  63. in the Yocto Project Development Tasks Manual for information on how
  64. to get a build host ready that is either a native Linux machine or a
  65. machine that uses CROPS.
  66. #. *Clone the ``poky`` Repository:* You need to have a local copy of the
  67. Yocto Project :term:`Source Directory`
  68. (i.e. a local
  69. ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
  70. possibly the ":ref:`dev-manual/start:checking out by branch in poky`" and
  71. ":ref:`dev-manual/start:checking out by tag in poky`" sections
  72. all in the Yocto Project Development Tasks Manual for information on
  73. how to clone the ``poky`` repository and check out the appropriate
  74. branch for your work.
  75. #. *Initialize the Build Environment:* While in the root directory of
  76. the Source Directory (i.e. ``poky``), run the
  77. :ref:`structure-core-script` environment
  78. setup script to define the OpenEmbedded build environment on your
  79. build host::
  80. $ source oe-init-build-env
  81. Among other things, the script creates the :term:`Build Directory`, which
  82. is ``build`` in this case and is located in the Source Directory. After
  83. the script runs, your current working directory is set to the ``build``
  84. directory.
  85. #. *Make Sure You Are Building an Installer for the Correct Machine:*
  86. Check to be sure that your :term:`MACHINE` variable in the ``local.conf``
  87. file in your :term:`Build Directory` matches the architecture
  88. for which you are building.
  89. #. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
  90. toolchain designed to run on an architecture that differs from your
  91. current development host machine (i.e. the build host), be sure that
  92. the :term:`SDKMACHINE` variable in the ``local.conf`` file in your
  93. :term:`Build Directory` is correctly set.
  94. .. note::
  95. If you are building an SDK installer for the Extensible SDK, the
  96. :term:`SDKMACHINE` value must be set for the architecture of the
  97. machine you are using to build the installer. If :term:`SDKMACHINE`
  98. is not set appropriately, the build fails and provides an error
  99. message similar to the following::
  100. The extensible SDK can currently only be built for the same
  101. architecture as the machine being built on - SDK_ARCH
  102. is set to i686 (likely via setting SDKMACHINE) which is
  103. different from the architecture of the build machine (x86_64).
  104. Unable to continue.
  105. #. *Build the SDK Installer:* To build the SDK installer for a standard
  106. SDK and populate the SDK image, use the following command form. Be
  107. sure to replace ``image`` with an image (e.g. "core-image-sato")::
  108. $ bitbake image -c populate_sdk
  109. You can do the same for the extensible SDK using this command form::
  110. $ bitbake image -c populate_sdk_ext
  111. These commands produce an SDK installer that contains the sysroot
  112. that matches your target root filesystem.
  113. When the ``bitbake`` command completes, the SDK installer will be in
  114. ``tmp/deploy/sdk`` in the :term:`Build Directory`.
  115. .. note::
  116. - By default, the previous BitBake command does not build static
  117. binaries. If you want to use the toolchain to build these types
  118. of libraries, you need to be sure your SDK has the appropriate
  119. static development libraries. Use the
  120. :term:`TOOLCHAIN_TARGET_TASK`
  121. variable inside your ``local.conf`` file before building the
  122. SDK installer. Doing so ensures that the eventual SDK
  123. installation process installs the appropriate library packages
  124. as part of the SDK. Here is an example using ``libc``
  125. static development libraries: TOOLCHAIN_TARGET_TASK:append = "
  126. libc-staticdev"
  127. #. *Run the Installer:* You can now run the SDK installer from
  128. ``tmp/deploy/sdk`` in the :term:`Build Directory`. Here is an example::
  129. $ cd poky/build/tmp/deploy/sdk
  130. $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
  131. During execution of the script, you choose the root location for the
  132. toolchain. See the
  133. ":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`"
  134. section and the
  135. ":ref:`sdk-manual/appendix-obtain:installed extensible sdk directory structure`"
  136. section for more information.
  137. Extracting the Root Filesystem
  138. ==============================
  139. After installing the toolchain, for some use cases you might need to
  140. separately extract a root filesystem:
  141. - You want to boot the image using NFS.
  142. - You want to use the root filesystem as the target sysroot.
  143. - You want to develop your target application using the root filesystem
  144. as the target sysroot.
  145. Follow these steps to extract the root filesystem:
  146. #. *Locate and Download the Tarball for the Pre-Built Root Filesystem
  147. Image File:* You need to find and download the root filesystem image
  148. file that is appropriate for your target system. These files are kept
  149. in machine-specific folders in the
  150. :yocto_dl:`Index of Releases </releases/yocto/&DISTRO_REL_LATEST_TAG;/machines/>`
  151. in the "machines" directory.
  152. The machine-specific folders of the "machines" directory contain
  153. tarballs (``*.tar.bz2``) for supported machines. These directories
  154. also contain flattened root filesystem image files (``*.ext4``),
  155. which you can use with QEMU directly.
  156. The pre-built root filesystem image files follow the
  157. ``core-image-profile-machine.tar.bz2`` naming convention:
  158. - ``profile``: filesystem image's profile, such as ``minimal``,
  159. ``minimal-dev`` or ``sato``. For information on these types of image
  160. profiles, see the "Images" chapter in the Yocto Project Reference Manual.
  161. - ``machine``: same string as the name of the parent download directory.
  162. The root filesystems
  163. provided by the Yocto Project are based off of the
  164. ``core-image-sato`` and ``core-image-minimal`` images.
  165. For example, if you plan on using a BeagleBone device as your target
  166. hardware and your image is a ``core-image-sato-sdk`` image, you can
  167. download the following file::
  168. core-image-sato-sdk-beaglebone-yocto.tar.bz2
  169. #. *Initialize the Cross-Development Environment:* You must ``source``
  170. the cross-development environment setup script to establish necessary
  171. environment variables.
  172. This script is located in the top-level directory in which you
  173. installed the toolchain (e.g. ``poky_sdk``).
  174. Here is an example based on the toolchain installed in the
  175. ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section::
  176. $ source poky_sdk/environment-setup-core2-64-poky-linux
  177. #. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
  178. command and provide the root filesystem image.
  179. Here is an example command that extracts the root filesystem
  180. from a previously built root filesystem image that was downloaded
  181. from the :yocto_dl:`Index of Releases </releases/yocto/&DISTRO_REL_LATEST_TAG;/machines/>`.
  182. This command extracts the root filesystem into the ``core2-64-sato``
  183. directory::
  184. $ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato
  185. You could now point to the target sysroot at ``beaglebone-sato``.
  186. Installed Standard SDK Directory Structure
  187. ==========================================
  188. The following figure shows the resulting directory structure after you
  189. install the Standard SDK by running the ``*.sh`` SDK installation
  190. script:
  191. .. image:: figures/sdk-installed-standard-sdk-directory.png
  192. :scale: 100%
  193. The installed SDK consists of an environment setup script for the SDK, a
  194. configuration file for the target, a version file for the target, and
  195. the root filesystem (``sysroots``) needed to develop objects for the
  196. target system.
  197. Within the figure, italicized text is used to indicate replaceable
  198. portions of the file or directory name. For example, install_dir/version
  199. is the directory where the SDK is installed. By default, this directory
  200. is ``/opt/poky/``. And, version represents the specific snapshot of the
  201. SDK (e.g. &DISTRO;). Furthermore, target represents the target architecture
  202. (e.g. ``i586``) and host represents the development system's
  203. architecture (e.g. ``x86_64``). Thus, the complete names of the two
  204. directories within the ``sysroots`` could be ``i586-poky-linux`` and
  205. ``x86_64-pokysdk-linux`` for the target and host, respectively.
  206. Installed Extensible SDK Directory Structure
  207. ============================================
  208. The following figure shows the resulting directory structure after you
  209. install the Extensible SDK by running the ``*.sh`` SDK installation
  210. script:
  211. .. image:: figures/sdk-installed-extensible-sdk-directory.png
  212. :scale: 80%
  213. :align: center
  214. The installed directory structure for the extensible SDK is quite
  215. different than the installed structure for the standard SDK. The
  216. extensible SDK does not separate host and target parts in the same
  217. manner as does the standard SDK. The extensible SDK uses an embedded
  218. copy of the OpenEmbedded build system, which has its own sysroots.
  219. Of note in the directory structure are an environment setup script for
  220. the SDK, a configuration file for the target, a version file for the
  221. target, and log files for the OpenEmbedded build system preparation
  222. script run by the installer and BitBake.
  223. Within the figure, italicized text is used to indicate replaceable
  224. portions of the file or directory name. For example, install_dir is the
  225. directory where the SDK is installed, which is ``poky_sdk`` by default,
  226. and target represents the target architecture (e.g. ``i586``).