diff options
Diffstat (limited to 'docs/0_Getting_Started/6_ Developing_an_Application ')
10 files changed, 625 insertions, 0 deletions
diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /0_Overview.md b/docs/0_Getting_Started/6_ Developing_an_Application /0_Overview.md new file mode 100644 index 0000000..d085937 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /0_Overview.md @@ -0,0 +1,43 @@ +--- +edit_link: '' +title: Overview +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-intro.md +--- + +<!-- 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 --> + +# 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. + +![](images/app-developer-workflow.png){:: style="margin:auto; display:flex"} + +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/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md b/docs/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md new file mode 100644 index 0000000..a4d4303 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md @@ -0,0 +1,172 @@ +--- +edit_link: '' +title: Download or Build Your Image +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-image.md +--- + +<!-- 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 --> + +# 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 ARM 32/64bit and Intel 64bit +devices. + +* **[R-Car Gen3 Ultra Low-Cost Board](https://www.elinux.org/R-Car/Boards/M3SK , https://www.elinux.org/R-Car/Boards/H3SK):** +The M3ULCB/H3ULCB 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 4](https://www.raspberrypi.org/products/):** +The Raspberry Pi 4 uses a 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. + +* **[x86-64]:** +Any x86-64 hardware is supported. We recommend e.g. the Up² board. + +* **[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. + + + +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. +Go to the [AGL Download Website](https://download.automotivelinux.org/AGL/release/) +site and follow these links: + +``` +icefish -> 9.0.0 -> qemuarm64 -> deploy -> images -> qemuarm64 +``` + +From the list, you could download the ``Image-qemuarm64.bin`` Kernel and the +``agl-demo-platform-crosssdk-qemuarm64.ext4.xz``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 "[Preparing Your Build Host](./image-workflow-prep-host.html)" + 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 + "[Preparing Your Build Host](./image-workflow-prep-host.html)" + 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/latest/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](./image-workflow-download-sw.html)" + 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 + "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html)" + section. + +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 + "[Customizing Your Build](./image-workflow-cust-build.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/ + ``` diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /2_Download_or_Build_Your_SDK_Installer.md b/docs/0_Getting_Started/6_ Developing_an_Application /2_Download_or_Build_Your_SDK_Installer.md new file mode 100644 index 0000000..ef29bf2 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /2_Download_or_Build_Your_SDK_Installer.md @@ -0,0 +1,73 @@ +--- +edit_link: '' +title: Download or Build Your SDK Installer +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-sdk.md +--- + +<!-- 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 --> + +# 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 8.0.0 "Halibut" release of the AGL software. +Follow these links: + +``` +halibut -> 8.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-aarch64-toolchain-8.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-agl-demo-platform-crosssdk-aarch64-toolchain-8.0.0.sh +``` diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /3_Create_Bootable_Media.md b/docs/0_Getting_Started/6_ Developing_an_Application /3_Create_Bootable_Media.md new file mode 100644 index 0000000..c801253 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /3_Create_Bootable_Media.md @@ -0,0 +1,28 @@ +--- +edit_link: '' +title: Create Bootable Media +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-bootables.md +--- + +<!-- 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 --> + +# 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. + +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. Write out the image using e.g. ``etcher`` , ``bmaptool`` or ``dd``. + +You can detailed steps for creating bootable images for several types of images +in the following sections: + +* "[Deploying the AGL Demo Image](./machines/qemu.html#3-deploying-the-agl-demo-image)" for emulation images +* "[Booting the Image Using a MicroSD Card](./machines/renesas.html#7-booting-the-image-using-a-microsd-card) for supported Renesas boards +* "[Booting the Image on Raspberry Pi](./machines/raspberrypi.html#2-booting-the-image-on-raspberrypi) for Raspberry Pi 4 board diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /4_Boot_the_Image_on_the_Board.md b/docs/0_Getting_Started/6_ Developing_an_Application /4_Boot_the_Image_on_the_Board.md new file mode 100644 index 0000000..0e0b744 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /4_Boot_the_Image_on_the_Board.md @@ -0,0 +1,31 @@ +--- +edit_link: '' +title: Boot the Image on the Board +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-boot.md +--- + +<!-- 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 --> + +# 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 + "[Booting the Image on the Target Device](./machines/intel.html#4-booting-the-image-on-the-target-device)" + section. + +2. **QEMU:** See the + "[Deploying the AGL Demo Image](./machines/qemu.html#3-deploying-the-agl-demo-image)" + section. + +3. **R Car Starter Kit:** See the + "[Booting the Image Using a MicroSD Card](./machines/renesas.html#7-booting-the-image-using-a-microsd-card)" + section. + +4. **Raspberry PI:** See the + "[Booting the Image on Raspberry Pi](./machines/raspberrypi.html#2-booting-the-image-on-raspberry-pi)" + section. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /5_Get_Ready_to_Create_Your_Application.md b/docs/0_Getting_Started/6_ Developing_an_Application /5_Get_Ready_to_Create_Your_Application.md new file mode 100644 index 0000000..38e6b36 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /5_Get_Ready_to_Create_Your_Application.md @@ -0,0 +1,66 @@ +--- +edit_link: '' +title: Get Ready to Create Your Application +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-prep-app.md +--- + +<!-- 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 --> + +# 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:** [Docker Container](../../../devguides/reference/xds/part-1/server-part.html#docker-container) + + * **Virtual Machine:** [VirtualBox Appliance](../../../devguides/reference/xds/part-1/server-part.html#virtualbox-appliance) + + * **Native:** [Native](../../../devguides/reference/xds/part-1/server-part.html#native) + +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 + "[Client Part](../../../devguides/reference/xds/part-1/client-part.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 + "[AGL SDKs](../../../devguides/reference/xds/part-1/install-sdk.html)" + section for information on using both. + +## Installing a Stand-Alone 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. +You can also visit the +[Yocto Project Application Development and the Extensible Software Development Kit (eSDK)](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html) +Manual. + +**NOTE:** The AGL Project is not compatible with the eSDK. +You must use the Standard SDK. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /6_Create_and_Build_the_Application.md b/docs/0_Getting_Started/6_ Developing_an_Application /6_Create_and_Build_the_Application.md new file mode 100644 index 0000000..27d861d --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /6_Create_and_Build_the_Application.md @@ -0,0 +1,90 @@ +--- +edit_link: '' +title: Create and Build the Application +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-build-app.md +--- + +<!-- 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 --> + +# 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 that allow you to pick from whatever methodology or workflow +with which you are comfortable. + +A simple application you can experiment with is the standard +"hello world" application. +For information on how to get set up and then clone the Git repository +for the "Hello World" application, see the +"[Get the Source Files](../../../devguides/reference/xds/part-1/create-app-get-source-files.html)" +section. + +Key to developing an application suited for your target hardware is the +Standard Software Development Kit (SDK) mentioned in the +"[Get Ready to Create Your Application](./app-workflow-prep-app.html)" +section. +For information on the Standard SDK used with the Yocto Project and with +the AGL Project, see the +"[Yocto Project Application Development and Extensible Software Development Kit (eSDK)](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html) Manual". + +You can develop your application a number of ways. +The following list describes several: + +* **Build the Application Using XDS:** + You can use the AGL X(cross) Development System (XDS) + to build your application: + + * Use the XDS command line tool. + For information on how to build the "Hello World" application using the XDS + command line, see the + "[Build Using the Command Line](../../../devguides/reference/xds/part-1/create-app-build-cmd-line.html)" + section. + + * Use the XDS Dashboard. + For information on how to build the application using the XDS Dashboard, see the + "[Build Using the XDS Dashboard](../../../devguides/reference/xds/part-1/create-app-build-dashboard.html)" + section. + +* **Build the Application Using a Stand-Alone SDK:** + Nothing prevents you from using a Standard SDK completely outside of the + AGL Project development environment to build your application. + Here are a couple of methods: + + * Install Docker and create a container that has your SDK installed. + The container is a stable environment where you can build applications. + See the + "[Setting Up a Docker Container](./docker-container-setup.html)" + section for information on how to install Docker and create a container + that has your SDK installed. + + * Use the popular Eclipse IDE configured to work with the Yocto Project. + See the + "[Developing Applications Using Eclipse](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html#sdk-eclipse-project)" + section in the Yocto Project Application Development and Extensible + Software Development Kit (eSDK) Manual. + + * Using Qt Creator / qmake and want to use the same .pro / .pri file to build for desktop or AGL? Put AGL-specific definitions inside a `linux-oe-*` block in your .pro and .pri files, e.g.: + ``` + linux-oe-* { + PKGCONFIG += qlibwindowmanager qtappfw + DEFINES += AGL + QMAKE_LFLAGS += "-Wl,--hash-style=gnu -Wl,--as-needed" + load(configure) + qtCompileTest(libhomescreen) + + config_libhomescreen { + CONFIG += link_pkgconfig + PKGCONFIG += homescreen + DEFINES += HAVE_LIBHOMESCREEN + } + + DESTDIR = $${OUT_PWD}/../package/root/bin + } + ``` + +* **Build the Application Using Your Own Methodology:** + Use any method you are familiar with to create your application. + Many development tools and workflows exist that allow you to + create applications. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /7_Deploy_the_Application_to_the_Board.md b/docs/0_Getting_Started/6_ Developing_an_Application /7_Deploy_the_Application_to_the_Board.md new file mode 100644 index 0000000..ee9d6f8 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /7_Deploy_the_Application_to_the_Board.md @@ -0,0 +1,58 @@ +--- +edit_link: '' +title: Deploy the Application to the Board +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-deploy-app.md +--- + +<!-- 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 --> + +# Deploy the Application to the Board # + + +Many options exist for controlling your target and copying your compiled application to the target. +Details are target-specific and cannot be explained in detail here. + +Suffice it to say that if you compile your application on your build host and you have +an image running on your target hardware, you must employ some method to copy the application +to the target. +Several general methods exist: + + * Write the application to a storage device that both the build host and + the target hardware support. + This could be an SD card or a flash drive. + Be sure to format the drive as FAT32 to eliminate file ownership and permission issues. + + * Remotely mount the target's file system on the build host with the Network File System + (NFS) or Samba. + + * Commit compiled code from the build host to a shared repository and update the + target from that repository. + + * Use remote commands from a host over a network, such as `scp` (i.e. secure copy). + + * You can set up your build environment to leverage a procedure's + [application template](../../../devguides/reference/cmakeafbtemplates/dev_guide/using-cmake.html) + (app-template). + An app-template is an 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 + ``` + + **NOTE:** + The previous command uses `scp` to copy and install the widget to a pre-defined target board. + +Once you have the application copied to the target, it must provide a way to +initiate operating system commands. +To initiate operating system commands, you can do one of the following: + + * Connect a keyboard and display directly to the target. + + * Use ``ssh`` from a network-connected host to run commands on the target remotely. + + * Use a network for communication between the build host and the target. + This method works nicely when the build host and the target hardware are geographically apart. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /8_Debug_the_Application.md b/docs/0_Getting_Started/6_ Developing_an_Application /8_Debug_the_Application.md new file mode 100644 index 0000000..04d79e6 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /8_Debug_the_Application.md @@ -0,0 +1,64 @@ +--- +edit_link: '' +title: Debug the Application +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-debug-app.md +--- + +<!-- 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 --> + +# 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, and your debugging +skills and productivity. +For example, 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 user interface that is part of +an Integrated Development Environment (IDE) such as Eclipse? + +For general information on debugging an application, see the +"[Overview](../../../devguides/reference/xds/part-1/debug-overview.html)" +topic under "Debugging Your First AGL Application". + +Three methods exist: + + * Use `gdb` on the target. + + <!--section-note--> + **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. + <!--end-section-note--> + + * 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 + "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment)" + topic. + + <!--section-note--> + **NOTE:** + + Core Dumps are available only with the "Flunky Flounder" release (i.e. 6.x). + <!--end-section-note--> + + * Use XDS remotely, which is based on `gdb` and + [`gdbserver`](https://en.wikipedia.org/wiki/Gdbserver). + See the + "[Using the XDS Command Line](../../../devguides/reference/xds/part-1/debug-cmd-line.html#xds-remote-debugging-mode)" + topic for more information. + + For information on how to remotely debug the application using XDS from within an IDE, see the + "[Using an IDE](../../../devguides/reference/xds/part-1/debug-ide.html)" + section. + + 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 + "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment)" + section. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /images/app-developer-workflow.png b/docs/0_Getting_Started/6_ Developing_an_Application /images/app-developer-workflow.png Binary files differnew file mode 100644 index 0000000..3b14272 --- /dev/null +++ b/docs/0_Getting_Started/6_ Developing_an_Application /images/app-developer-workflow.png |