Application Development Workflow Content files

I have added new files for content for the "Application Development
Workflow" section that is temporarily in the "Getting Started"
section of the doc website.

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>

10 files changed, 451 insertions, 0 deletions

diff --git a/docs/getting-started/app-workflow-boot.md b/docs/getting-started/app-workflow-boot.md
new file mode 100644
index 0000000..2000518
--- /dev/null
+++ b/docs/getting-started/app-workflow-boot.md
@@ -0,0 +1,22 @@
+# 4. Boot the Image on the Board #
+
+You must have your image booted and running on your target device at some
+point before deploying your application for testing.
+
+Steps exist for booting the following devices:
+
+1. **Intel Devices:** See the
+   "[Boot the image on the target device](./machines/intel.html#boot-the-image-on-the-target-device)"
+   section.
+
+2. **QEMU:** See the
+   "[Boot an image](./machines/qemu.html#boot-an-image)"
+   section.
+
+3. **R Car Starter Kit:** See the
+   "[Booting AGL Image on R-Car Starter Kit Gen3 boards using a microSD card](./machines/R-Car-Starter-Kit-gen3.html#booting-agl-image-on-r-car-starter-kit-gen3-boards-using-a-microsd-card)"
+   section.
+
+4. **Raspberry PI:** See the
+   "[Booting AGL Demo Platform on Raspberry Pi](./machines/raspberrypi.html#booting-agl-demo-platform-on-raspberry-pi)"
+   section.
diff --git a/docs/getting-started/app-workflow-bootables.md b/docs/getting-started/app-workflow-bootables.md
new file mode 100644
index 0000000..4e6211a
--- /dev/null
+++ b/docs/getting-started/app-workflow-bootables.md
@@ -0,0 +1,17 @@
+# 3. Create Bootable Media #
+
+In order to test an application, your device must be running the image and, of course,
+the application.
+To run the image, you need to create a bootable image that can be launched
+from an external device such as an SD card or USB stick.
+
+The following list overviews the process.
+You find a more detailed description of the process in the
+"[Create a bootable media](./machines/intel.html#create-a-bootable-media)"
+section.
+
+1. Insert your media into the appropriate build host interface (e.g. USB port).
+2. Determine the device name of your portable media (e.g. ``sdb``).
+3. Download the ``mkefi-agl.sh`` script.
+4. Check your available script options.
+5. Use ``mkefi-agl.sh`` to create your media.
diff --git a/docs/getting-started/app-workflow-build-app.md b/docs/getting-started/app-workflow-build-app.md
new file mode 100644
index 0000000..bb4a687
--- /dev/null
+++ b/docs/getting-started/app-workflow-build-app.md
@@ -0,0 +1,23 @@
+# 6. Create and Build the Application #
+
+In general, you can create and build an application many different ways.
+Tools and Integrated Development Environments (IDEs) exist in various scenarios to allow you to
+pick from whatever methodology or workflow with which you are comfortable.
+
+This section uses XDS and the standard “hello world” application.
+
+1. **Setup and Clone the Hello World Repository:**
+   For information on how to get set up and then clone the Git repository for the
+   "Hello World" application, see the
+   "[Setup](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/4-1_build-first-app-setup.html)"
+   section.
+
+2. **Build the Application:**
+   For information on how to build the "Hello World" application using the XDS
+   command line, see the
+   "[Build using command line tool](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/4-2_build-first-app-cmd.html)"
+   section.
+
+   For information on how to build the application using the XDS Dashboard, see the
+   "[Build using XDS Dashboard](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/4-3_build-first-app-dashboard.html)"
+   section.
diff --git a/docs/getting-started/app-workflow-debug-app.md b/docs/getting-started/app-workflow-debug-app.md
new file mode 100644
index 0000000..6b6687c
--- /dev/null
+++ b/docs/getting-started/app-workflow-debug-app.md
@@ -0,0 +1,48 @@
+# Debug the Application #
+
+You can debug your application many ways.
+The method depends on factors such as the component you are debugging,
+whether or not you are doing a post-mortem analysis, your debugging
+skills and productivity (i.e. do you know how to use the
+[GNU Project Debugger](https://www.gnu.org/software/gdb/) (`gdb`) from a
+console or is it better for you to use a remote UI that is integrated
+with an IDE?).
+
+For general information on debugging an application, see the
+"[Debug your first AGL application](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/5_debug-first-app.html)"
+section.
+
+Here are three methods:
+
+   * Use `gdb` on the target.
+
+     **NOTE:** How to use `gdb` and other debugging tools such as `valgrind`, `strace`,
+     and so forth is beyond the scope of the AGL Documentation.
+     See the appropriate documentation for third-party debugging tools.
+
+   * Use Core Dumps if you have set the `agl-devel` feature.
+     Core Dumps are obviously more suited for post-mortem analysis.
+     For features, see the
+     "[Features supported by `aglsetup`](http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/source-code.html#features-supported-by-aglsetup)"
+     section.
+
+     **NOTE:** Core Dumps are available only with the "Flunky Flounder" release (i.e. 6.x).
+
+   * Use XDS remotely, which is based on `gdb` and
+     `[gdbserver](https://en.wikipedia.org/wiki/Gdbserver)`.
+     See the
+     "[XDS remote debugging mode](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/5-2_debug-first-app-cmd.html#xds-remote-debugging-mode)"
+     section for more information.
+
+     For information on how to remotely debug the application using XDS from within an IDE, see the
+     "[Debug using `xds-gdb` within an IDE](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/5-3_debug-first-app-ide.html)"
+     section.
+
+   **NOTE:** How to use `gdb` and other debugging tools such as `valgrind`, `strace`, and so forth is beyond the scope of the AGL Documentation.
+   See the appropriate documentation for third-party debugging tools.
+
+   In order to use third-party debugging tools, you need to include the tools in the target image.
+   You gain access to the tools by enabling the `agl-devel` feature when you run the
+   `aglsetup.sh` script as described in the
+   "[Setup Build Environment Info](http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/source-code.html#set-up-build-environment-info)"
+   section.
diff --git a/docs/getting-started/app-workflow-deploy-app.md b/docs/getting-started/app-workflow-deploy-app.md
new file mode 100644
index 0000000..43727b3
--- /dev/null
+++ b/docs/getting-started/app-workflow-deploy-app.md
@@ -0,0 +1,16 @@
+# Deploy the Application to the Board #
+
+You can set up your build environment to leverage a procedure's
+[application template](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/sdk-devkit/docs/part-2/2_4-Use-app-templates.html)
+(app-template).
+An app-template is a application framework that contains
+[CMake](https://cmake.org/) macros that abstract deploying the application.
+For example, with a proper build environment, you can run the following
+to deploy your application:
+
+```
+$ make widget-target-install
+```
+
+The previous command uses secure copy (`scp`) to copy and install the widget to a
+pre-defined target board.
diff --git a/docs/getting-started/app-workflow-image.md b/docs/getting-started/app-workflow-image.md
new file mode 100644
index 0000000..960f4f0
--- /dev/null
+++ b/docs/getting-started/app-workflow-image.md
@@ -0,0 +1,173 @@
+# 1. Download or Build Your Image #
+
+You need to have an image that you can run on your hardware device.
+You can either build that image from scratch or, if you are going to use
+hardware supported by AGL, you can download a ready-made image from the
+[AGL Download Website](https://download.automotivelinux.org/AGL/release/) site.
+
+## Downloading an image ##
+
+For a look at the supported images, go to the
+[AGL Download Website](https://download.automotivelinux.org/AGL/release/).
+You can explore that hierarchy and locate images based on the AGL release and the supported hardware.
+
+The following list summarizes the pre-built image support:
+
+* **[Quick EMUlator (QEMU)](https://www.qemu.org/):**
+QEMU is a generic, open source machine emulator and virtualizer.
+You can use QEMU as your "hardware" when you run an image built for
+the emulator.
+AGL supports QEMU images for 32 and 64-bit architectures for ARM and Intel
+devices.
+
+* **[DRA7xx Evaluation Module Platform](http://www.ti.com/tool/J6EVM5777):**
+Texas Instruments Jacinto™ DRA7xx evaluation module platform helps speed up
+development efforts and reduces time-to-market for applications
+such as infotainment, reconfigurable digital cluster, or integrated digital
+cockpit.
+
+* **[DragonBoard 410C Development Board](https://developer.qualcomm.com/hardware/dragonboard-410c):**
+QualComm's DragonBoard™ 410c is its first development board based
+on a Qualcomm® Snapdragon™ 400 series processor.
+The credit-card sized board has advanced processing power, Wi-Fi, Bluetooth
+connectivity, and GPS.
+The board is based on the 64-bit Snapdragon 410E processor,
+
+* **[Intel Core i7 Boards](https://www.intel.com/content/www/us/en/nuc/nuc-kit-nuc7i7bnh-brief.html?wapkw=core+i7+boards):**
+Intel offers a wide array of devices and boards.
+One such device that uses the Intel Core i7 board supported by AGL
+is the Intel® NUC Kit NUC7i7BNH.
+The board in this device uses a dual-core 7th Generation Intel Core i7
+processor and Intel Turbo Boost Technology 2.0.
+
+* **[M3 Ultra Low-Cost Board](https://www.elinux.org/R-Car/Boards/M3SK):**
+The MC3ULC is a Renesas R-Car Gen3 SOC development board.
+Depending on the SOC specialization, Renesas provides several classes
+of these boards.
+The "M" classification is for the "middle-end" version as compared to the
+"H" classification, which is a "high-end" version.
+
+* **[Raspberry Pi 3](https://www.raspberrypi.org/products/):**
+The Raspberry Pi 3 uses a 1.4GHz 64-bit quad-core processor.
+The board features dual-band wireless LAN, Bluetooth 4.2/BLE,
+faster Ethernet, and Power-over-Ethernet support with separate PoE HAT.
+
+If you want to use QEMU or you are developing an application for one the
+supported hardware board types, you might consider skipping the build
+step, which is described below, and just download your image.
+
+As an example, suppose you want to download the 64-bit ARM-based image
+that you can emulate using QEMU.
+Furthermore, you are using the "Flounder" 6.0.0 AGL release.
+Go to the [AGL Download Website](https://download.automotivelinux.org/AGL/release/)
+site and follow these links:
+
+```
+flounder -> 6.0.0 -> qemuarm64 -> deploy -> images -> qemuarm64
+```
+
+From the list, you could download the ``Image-qemuarm64.bin`` image file.
+
+## Building an image ##
+
+Building the image from scratch requires system preparation, build configuration, and then the build itself.
+Building an image for the first time can take many hours.
+
+The following procedure describes how to build your image:
+
+1. **Prepare Your System:**  Your system, known as a "build host" needs to meet some requirements
+   in order to build images in the AGL environment.
+   The "[Setting up your operating system](./source-code.html#setting-up-your-operating-system)"
+   section describes in detail how to make sure your system meets
+   these requirements.
+
+   In summary, do the following to prepare your system:
+
+   * Be sure that your build system runs a modern version of a supported Linux Distribution.
+     For a list of supported distributions, see the
+     "[Supported Linux Distributions](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#detailed-supported-distros)"
+     section in the Yocto Project Reference Manual.
+
+     **NOTE:** Building images using AGL software leverages off the
+     [Yocto Project](https://www.yoctoproject.org/), which is an Open Source project used to create small, embedded distributions.
+
+   * Be sure that you have updated versions of Tar, Git, Python, and the GNU Compiler Collection (GCC).
+
+   * Install required packages on the build host.
+     This list of packages depends on the particular Linux Distribution your build host uses.
+     See the
+     "[Setting up your operating system](./source-code.html#setting-up-your-operating-system)"
+     section for the packages you need to install for your specific
+     distribution.
+
+     **NOTE:** The definitive package requirements are documented in the
+     "[Required Packages for the Host Development System](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#required-packages-for-the-host-development-system)"
+     section of the Yocto Project Reference Manual.
+
+2. **Download the AGL source code:** Getting the AGL source code involves creating an
+   isolated work directory, securing the "repo" tool, and finally
+   using Git to download the source code into a cloned local repository.
+
+   Be sure to consider the source code version before downloading the source.
+   If you want the cutting edge version of the AGL source code, download the "master" branch.
+   Otherwise, download the latest stable AGL release.
+
+   You can see example steps in the
+   "[Download AGL source code](./source-code.html#download-agl-source-code)"
+   section.
+
+3. **Initialize the build environment:** The build process assumes many environment
+   variable settings, tools, tool locations, and file hierarchies.
+   Once the AGL software is on your local system, you need to run the build
+   setup script (i.e. ``aglsetup.sh``) to establish environment variables
+   and paths used during the build process.
+
+   Because the script accepts options that define the features used in your
+   build environment, you need to understand what features you want
+   before running the script.
+   For information on running the script and on the features you can choose,
+   see the
+   "[Set up Build Environment info](./source-code.html#set-up-build-environment-info)"
+   and
+   "[Features supported by aglsetup](./source-code.html#features-supported-by-aglsetup)"
+   sections.
+
+4. **Customize your build configuration:** Aside from environment variables
+   and parameters, build parameters and variables need to be defined before
+   you start the build process.
+   These parameters (configurations) are defined in the ``local.conf``
+   configuration file.
+   In general, the defaults in that file are good enough.
+   However, you can customize aspects by editing the ``local.conf`` file.
+   See the
+   "[Customize AGL build](./customize_bitbake_conf.html)"
+   section for the location of the file and a list of common customizations.
+
+   **NOTE:** For detailed explanations of the configurations you can make
+   in the ``local.conf`` file, consult the
+   [Yocto Project Documentation](https://www.yoctoproject.org/docs/).
+
+5. **Building the image:** You use
+   [BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html)
+   to build the image.
+   BitBake is the engine used by the Yocto Project when building images.
+   The command used to build the image is ``bitbake``.
+
+   For example, the following command builds the image for the AGL demo platform,
+   which is an image you can emulate using QEMU:
+
+   ```
+   $ bitbake agl-demo-platform
+   ```
+
+   As previously mentioned, building a new image can take a long time.
+   An initial build could take hours.
+   Once the image has been initially built, re-builds are much quicker as
+   BitBake takes advantage of cached artifacts.
+
+   The build image resides in the deployment area of the build directory.
+   For example, Assuming your top-level AGL directory is ``~/workspace_agl``, you find the image here:
+
+   ```
+   ~/workspace_agl/build/tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz
+   ```
diff --git a/docs/getting-started/app-workflow-intro.md b/docs/getting-started/app-workflow-intro.md
new file mode 100644
index 0000000..073496c
--- /dev/null
+++ b/docs/getting-started/app-workflow-intro.md
@@ -0,0 +1,35 @@
+# Overview #
+
+The application development workflow begins with securing the image
+that runs on your hardware and finishes with debugging the application
+as it runs on that hardware.
+
+The following figure and list overview the application development
+process.
+You can learn about the steps in the process by reading through the
+remaining sections.
+
+**NOTE:** This procedure uses information from many other procedures
+in the AGL Documentation set.
+Links are provided when a set of steps is required that is documented
+elsewhere.
+
+![Failed at Displaying My Image](images/app-developer-workflow.png)
+
+1. Download or build the image you are going to run on the hardware device.
+
+2. Download or build the Software Development Kit (SDK) you use to create your application.
+
+3. Create bootable media using your image.
+
+4. Boot your hardware device with the media.
+
+5. Prepare your environment so that you can develop an application.
+You can develop the application using XDS or using a stand-alone SDK.
+
+6. Create your application.
+
+7. Deploy the application to your hardware.
+
+8. Debug the application.
+
diff --git a/docs/getting-started/app-workflow-prep-app.md b/docs/getting-started/app-workflow-prep-app.md
new file mode 100644
index 0000000..4c017d2
--- /dev/null
+++ b/docs/getting-started/app-workflow-prep-app.md
@@ -0,0 +1,53 @@
+# 5. Get Ready to Create Your Application #
+
+Multiple methods exist that allow you to create your application.
+You can use the X(cross) Development System (XDS), or you can use
+a stand-alone Software Development Kit (SDK).
+The preferred method is to use XDS.
+
+## Using XDS ##
+
+It is recommended that you develop your application using XDS,
+which allows you to build, deploy, and execute personal projects on a target
+either through the XDS dashboard or the XDS command line.
+
+To use XDS, you need to install server and client parts
+and then use XDS to install the SDK:
+
+1. **Install the XDS Server:**  You might not have to install the XDS Server.
+   If, for example, you are using an existing XDS server running on your local network
+   or in the Cloud, you can use that server.
+
+   If you do not have an existing XDS server, you need to install one.
+   Three install types exist: container, virtual machine, or native.
+   Follow the steps from the appropriate section to install and start an XDS server:
+
+   * **Container:** [Installation based on Docker container](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/1-1_install-xds-server-docker.html)
+
+   * **Virtual Machine:** [Installation based on Virtual Machine appliance](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/1-2_install-xds-server-vm.html)
+
+   * **Native:** [Native installation](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/1-3_install-xds-server-native.html)
+
+2. **Install the XDS Client Tools**  The XDS Agent (``xds-agent``) needs to run on your build host.
+   The agent interfaces with a Command-line Interpretor (CLI) tool (``xds-cli``) and an
+   XDS Dashboard through a browser.
+   Installation involves making sure you have the correct packages installed on the
+   build host.
+   Follow the steps in the
+   "[Installing XDS Client Tools](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/1_install-client.html)"
+   section to install the XDS client tools and learn how to start the agent.
+
+3. **Install the SDK:** Once you have XDS up, you need to install the
+   SDK using either the command line or the Dashboard.
+   See the
+   "[Installing AGL SDKs](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/3_install-sdks.html)"
+   section for information on using both.
+
+## Installing a stand-alone SDK ##
+
+   * **Using only the SDK:** If you do not want to use XDS, you can install the SDK by itself.
+   For information, see the
+     "[App development SDK for Intel Minnowboard](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps)"
+     Wiki article and the
+     "[AGL SDK Quick Setup](http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/setup-sdk-environment.html)"
+     section for steps on how to work with a stand-alone SDK.
diff --git a/docs/getting-started/app-workflow-sdk.md b/docs/getting-started/app-workflow-sdk.md
new file mode 100644
index 0000000..fba4c7a
--- /dev/null
+++ b/docs/getting-started/app-workflow-sdk.md
@@ -0,0 +1,64 @@
+# 2. Download or Build Your SDK Installer #
+
+The Software Development Kit (SDK) allows you to use your build host
+to develop an application specific to your target hardware.
+SDKs are installed onto your build host by running an SDK installer
+file (``*.sh``).
+
+You must either download a pre-built installer file for your SDK or
+build an installer file.
+If you are developing an application for a board supported by the AGL software, you might
+want to just download a pre-built SDK installer file.
+If your hardware is not supported by AGL, you need to build the SDK installer file.
+
+## Downloading a pre-built SDK Installer ##
+
+For a look at the SDK installers for supported boards, go to the
+[AGL Download Website](https://download.automotivelinux.org/AGL/release/).
+From there, you can explore to find the SDK installer you want to download.
+As an example, consider using a pre-built SDK to develop applications suited for a 64-bit
+ARM-based board that you want to emulate using QEMU.
+Furthermore, you are using the 6.0.0 "Flounder" release of the AGL software.
+Follow these links:
+
+```
+flounder -> 6.0.0 -> qemuarm64 -> deploy -> sdk
+```
+
+From the list, you download the ``*.sh`` file, which is an installation script for the SDK.
+Running the SDK installer script installs the SDK onto your build host.
+
+SDK installation scripts have long names that reflect the platform specifics.
+For example, the following file installs the SDK given the specifics earlier:
+
+``poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-armv7vehf-neon-vfpv4-toolchain-6.0.0.sh``
+
+**NOTE:** If you want to know more about SDK installer file naming, which is a result of
+BitBake and the Yocto Project, see the
+"[Locating Pre-Built SDK Installers](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html#sdk-locating-pre-built-sdk-installers)"
+section in the Yocto Project documentation.
+
+## Building an SDK Installer ##
+
+If you cannot find a pre-built SDK installer for your hardware, you need to build one.
+In this case, use BitBake in a similar manner used to build the image.
+See the
+"[Building an image](./app-workflow-image.html#building-an-image)"
+section for information on building an image with BitBake.
+
+The only difference between building the image and the SDK installer
+is the target you give BitBake on the command line and the final location of
+the ``*.sh`` file.
+Following is the command that you use to build the SDK installer for ``agl-demo-platform``:
+
+```
+$ bitbake agl-demo-platform-crosssdk
+```
+
+The SDK installer file (``*.sh``) is placed in the build directory.
+Assuming your top-level workspace is ``~/workspace_agl``, here is an example location
+and SDK installer file:
+
+```
+~/workspace_agl/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-core-image-minimal-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh
+```
diff --git a/docs/getting-started/images/app-developer-workflow.png b/docs/getting-started/images/app-developer-workflow.png
new file mode 100644
index 0000000..3b14272
--- /dev/null
+++ b/docs/getting-started/images/app-developer-workflow.png