docs/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md

   1 ---
   2 edit_link: ''
   3 title: Download or Build Your Image
   4 origin_url: >-
   5   https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-image.md
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml -->
   9
  10 # 1. Download or Build Your Image #
  11
  12 You need to have an image that you can run on your hardware device.
  13 You can either build that image from scratch or, if you are going to use
  14 hardware supported by AGL, you can download a ready-made image from the
  15 [AGL Download Website](https://download.automotivelinux.org/AGL/release/) site.
  16
  17 ## Downloading an image ##
  18
  19 For a look at the supported images, go to the
  20 [AGL Download Website](https://download.automotivelinux.org/AGL/release/).
  21 You can explore that hierarchy and locate images based on the AGL release and the supported hardware.
  22
  23 The following list summarizes the pre-built image support:
  24
  25 * **[Quick EMUlator (QEMU)](https://www.qemu.org/):**
  26 QEMU is a generic, open source machine emulator and virtualizer.
  27 You can use QEMU as your "hardware" when you run an image built for
  28 the emulator.
  29 AGL supports QEMU images for ARM 32/64bit and Intel 64bit
  30 devices.
  31
  32 * **[R-Car Gen3 Ultra Low-Cost Board](https://www.elinux.org/R-Car/Boards/M3SK , https://www.elinux.org/R-Car/Boards/H3SK):**
  33 The M3ULCB/H3ULCB is a Renesas R-Car Gen3 SOC development board.
  34 Depending on the SOC specialization, Renesas provides several classes
  35 of these boards.
  36 The "M" classification is for the "middle-end" version as compared to the
  37 "H" classification, which is a "high-end" version.
  38
  39 * **[Raspberry Pi 4](https://www.raspberrypi.org/products/):**
  40 The Raspberry Pi 4 uses a 64-bit quad-core processor.
  41 The board features dual-band wireless LAN, Bluetooth 4.2/BLE,
  42 faster Ethernet, and Power-over-Ethernet support with separate PoE HAT.
  43
  44 * **[x86-64]:**
  45 Any x86-64 hardware is supported. We recommend e.g. the Up² board.
  46
  47 * **[DRA7xx Evaluation Module Platform](http://www.ti.com/tool/J6EVM5777):**
  48 Texas Instruments Jacinto™ DRA7xx evaluation module platform helps speed up
  49 development efforts and reduces time-to-market for applications
  50 such as infotainment, reconfigurable digital cluster, or integrated digital
  51 cockpit.
  52
  53
  54
  55 If you want to use QEMU or you are developing an application for one the
  56 supported hardware board types, you might consider skipping the build
  57 step, which is described below, and just download your image.
  58
  59 As an example, suppose you want to download the 64-bit ARM-based image
  60 that you can emulate using QEMU.
  61 Go to the [AGL Download Website](https://download.automotivelinux.org/AGL/release/)
  62 site and follow these links:
  63
  64 ```
  65 icefish -> 9.0.0 -> qemuarm64 -> deploy -> images -> qemuarm64
  66 ```
  67
  68 From the list, you could download the ``Image-qemuarm64.bin`` Kernel and the
  69 ``agl-demo-platform-crosssdk-qemuarm64.ext4.xz``Image file.
  70
  71
  72 ## Building an image ##
  73
  74 Building the image from scratch requires system preparation, build configuration, and then the build itself.
  75 Building an image for the first time can take many hours.
  76
  77 The following procedure describes how to build your image:
  78
  79 1. **Prepare Your System:**  Your system, known as a "build host" needs to meet some requirements
  80    in order to build images in the AGL environment.
  81    The "[Preparing Your Build Host](./image-workflow-prep-host.html)"
  82    section describes in detail how to make sure your system meets
  83    these requirements.
  84
  85    In summary, do the following to prepare your system:
  86
  87    * Be sure that your build system runs a modern version of a supported Linux Distribution.
  88      For a list of supported distributions, see the
  89      "[Supported Linux Distributions](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#detailed-supported-distros)"
  90      section in the Yocto Project Reference Manual.
  91
  92      **NOTE:** Building images using AGL software leverages off the
  93      [Yocto Project](https://www.yoctoproject.org/), which is an Open Source project used to create small, embedded distributions.
  94
  95    * Be sure that you have updated versions of Tar, Git, Python, and the GNU Compiler Collection (GCC).
  96
  97    * Install required packages on the build host.
  98      This list of packages depends on the particular Linux Distribution your build host uses.
  99      See the
 100      "[Preparing Your Build Host](./image-workflow-prep-host.html)"
 101      section for the packages you need to install for your specific
 102      distribution.
 103
 104      **NOTE:** The definitive package requirements are documented in the
 105      "[Required Packages for the Host Development System](https://yoctoproject.org/docs/latest/ref-manual/ref-manual.html#required-packages-for-the-host-development-system)"
 106      section of the Yocto Project Reference Manual.
 107
 108 2. **Download the AGL source code:** Getting the AGL source code involves creating an
 109    isolated work directory, securing the "repo" tool, and finally
 110    using Git to download the source code into a cloned local repository.
 111
 112    Be sure to consider the source code version before downloading the source.
 113    If you want the cutting edge version of the AGL source code, download the "master" branch.
 114    Otherwise, download the latest stable AGL release.
 115
 116    You can see example steps in the
 117    "[Download AGL source code](./image-workflow-download-sw.html)"
 118    section.
 119
 120 3. **Initialize the build environment:** The build process assumes many environment
 121    variable settings, tools, tool locations, and file hierarchies.
 122    Once the AGL software is on your local system, you need to run the build
 123    setup script (i.e. ``aglsetup.sh``) to establish environment variables
 124    and paths used during the build process.
 125
 126    Because the script accepts options that define the features used in your
 127    build environment, you need to understand what features you want
 128    before running the script.
 129    For information on running the script and on the features you can choose,
 130    see the
 131    "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html)"
 132    section.
 133
 134 4. **Customize your build configuration:** Aside from environment variables
 135    and parameters, build parameters and variables need to be defined before
 136    you start the build process.
 137    These parameters (configurations) are defined in the ``local.conf``
 138    configuration file.
 139    In general, the defaults in that file are good enough.
 140    However, you can customize aspects by editing the ``local.conf`` file.
 141    See the
 142    "[Customizing Your Build](./image-workflow-cust-build.html)"
 143    section for the location of the file and a list of common customizations.
 144
 145    **NOTE:** For detailed explanations of the configurations you can make
 146    in the ``local.conf`` file, consult the
 147    [Yocto Project Documentation](https://www.yoctoproject.org/docs/).
 148
 149 5. **Building the image:** You use
 150    [BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html)
 151    to build the image.
 152    BitBake is the engine used by the Yocto Project when building images.
 153    The command used to build the image is ``bitbake``.
 154
 155    For example, the following command builds the image for the AGL demo platform,
 156    which is an image you can emulate using QEMU:
 157
 158    ```
 159    $ bitbake agl-demo-platform
 160    ```
 161
 162    As previously mentioned, building a new image can take a long time.
 163    An initial build could take hours.
 164    Once the image has been initially built, re-builds are much quicker as
 165    BitBake takes advantage of cached artifacts.
 166
 167    The build image resides in the deployment area of the build directory.
 168    For example, Assuming your top-level AGL directory is ``~/workspace_agl``, you find the image here:
 169
 170    ```
 171    ~/workspace_agl/build/tmp/deploy/images/qemux86-64/
 172    ```