From 83bd353da3cebb7cd8d31f9a6f79ee9b7f90b82f Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 25 Oct 2018 15:17:23 -0700 Subject: 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 --- docs/getting-started/app-workflow-boot.md | 22 +++ docs/getting-started/app-workflow-bootables.md | 17 ++ docs/getting-started/app-workflow-build-app.md | 23 +++ docs/getting-started/app-workflow-debug-app.md | 48 ++++++ docs/getting-started/app-workflow-deploy-app.md | 16 ++ docs/getting-started/app-workflow-image.md | 173 +++++++++++++++++++++ docs/getting-started/app-workflow-intro.md | 35 +++++ docs/getting-started/app-workflow-prep-app.md | 53 +++++++ docs/getting-started/app-workflow-sdk.md | 64 ++++++++ .../images/app-developer-workflow.png | Bin 0 -> 53065 bytes 10 files changed, 451 insertions(+) create mode 100644 docs/getting-started/app-workflow-boot.md create mode 100644 docs/getting-started/app-workflow-bootables.md create mode 100644 docs/getting-started/app-workflow-build-app.md create mode 100644 docs/getting-started/app-workflow-debug-app.md create mode 100644 docs/getting-started/app-workflow-deploy-app.md create mode 100644 docs/getting-started/app-workflow-image.md create mode 100644 docs/getting-started/app-workflow-intro.md create mode 100644 docs/getting-started/app-workflow-prep-app.md create mode 100644 docs/getting-started/app-workflow-sdk.md create mode 100644 docs/getting-started/images/app-developer-workflow.png (limited to 'docs') 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 Binary files /dev/null and b/docs/getting-started/images/app-developer-workflow.png differ -- cgit 1.2.3-korg From 8e5063847abe9f5ab2bf37d118a292cec3e8bb61 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 29 Oct 2018 12:57:30 -0700 Subject: Application Development Workflow Links: Converted existing links in the application development workflow MD files to use relative paths rather than hard-coded https:// paths. Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-build-app.md | 6 +++--- docs/getting-started/app-workflow-deploy-app.md | 4 ++-- docs/getting-started/app-workflow-prep-app.md | 12 ++++++------ 3 files changed, 11 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-build-app.md b/docs/getting-started/app-workflow-build-app.md index bb4a687..dc478b1 100644 --- a/docs/getting-started/app-workflow-build-app.md +++ b/docs/getting-started/app-workflow-build-app.md @@ -9,15 +9,15 @@ 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)" + "[Setup](../../../../../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)" + "[Build using command line tool](../../../../../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)" + "[Build using XDS Dashboard](../../../../../docs/devguides/en/dev/reference/xds/part-1/4-3_build-first-app-dashboard.html)" section. diff --git a/docs/getting-started/app-workflow-deploy-app.md b/docs/getting-started/app-workflow-deploy-app.md index 43727b3..f40c3aa 100644 --- a/docs/getting-started/app-workflow-deploy-app.md +++ b/docs/getting-started/app-workflow-deploy-app.md @@ -1,9 +1,9 @@ # 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) +[application template](../../../../../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 +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: diff --git a/docs/getting-started/app-workflow-prep-app.md b/docs/getting-started/app-workflow-prep-app.md index 4c017d2..7985a6a 100644 --- a/docs/getting-started/app-workflow-prep-app.md +++ b/docs/getting-started/app-workflow-prep-app.md @@ -22,11 +22,11 @@ and then use XDS to install the SDK: 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) + * **Container:** [Installation based on Docker container](../../../../../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) + * **Virtual Machine:** [Installation based on Virtual Machine appliance](../../../../../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) + * **Native:** [Native installation](../../../../../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 @@ -34,13 +34,13 @@ and then use XDS to install the SDK: 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)" + "[Installing XDS Client Tools](../../../../../docs/devguides/en/dev/reference/xds/part-1/2_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)" + "[Installing AGL SDKs](../../../../../docs/devguides/en/dev/reference/xds/part-1/3_install-sdks.html)" section for information on using both. ## Installing a stand-alone SDK ## @@ -49,5 +49,5 @@ and then use XDS to install the SDK: 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)" + "[AGL SDK Quick Setup](../../../../../docs/getting_started/en/dev/reference/setup-sdk-environment.html)" section for steps on how to work with a stand-alone SDK. -- cgit 1.2.3-korg From cf52268b9ab813a4c11e30b70aef8e8c1d6172c9 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 29 Oct 2018 13:20:04 -0700 Subject: Deploy Application flow: Added general instructions on how to deploy an application to a target device. Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-deploy-app.md | 61 +++++++++++++++++++------ 1 file changed, 47 insertions(+), 14 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-deploy-app.md b/docs/getting-started/app-workflow-deploy-app.md index f40c3aa..b79a06a 100644 --- a/docs/getting-started/app-workflow-deploy-app.md +++ b/docs/getting-started/app-workflow-deploy-app.md @@ -1,16 +1,49 @@ # Deploy the Application to the Board # -You can set up your build environment to leverage a procedure's -[application template](../../../../../docs/devguides/en/dev/reference/sdk-devkit/docs/part-2/2_4-Use-app-templates.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 -``` - -The previous command uses secure copy (`scp`) to copy and install the widget to a -pre-defined target 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](../../../../../docs/devguides/en/dev/reference/sdk-devkit/docs/part-2/2_4-Use-app-templates.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. -- cgit 1.2.3-korg From 68c8923ad5b03f57de3898b81cdc916ac0500e72 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 29 Oct 2018 13:36:18 -0700 Subject: Application development workflow debug: Updated this content with general information on how to debug the application once it is part of the target (has been deployed). Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-debug-app.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-debug-app.md b/docs/getting-started/app-workflow-debug-app.md index 6b6687c..91ef905 100644 --- a/docs/getting-started/app-workflow-debug-app.md +++ b/docs/getting-started/app-workflow-debug-app.md @@ -2,14 +2,16 @@ 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 +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 UI that is integrated -with an IDE?). +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 -"[Debug your first AGL application](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/xds/part-1/5_debug-first-app.html)" +"[Debug your first AGL application](../../../../../docs/devguides/en/dev/reference/xds/part-1/5_debug-first-app.html)" section. Here are three methods: @@ -23,26 +25,23 @@ Here are three methods: * 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)" + "[Features supported by `aglsetup`](../../../../../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)`. + [`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)" + "[XDS remote debugging mode](../../../../../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)" + "[Debug using `xds-gdb` within an IDE](../../../../../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)" + "[Setup Build Environment Info](../../../../../docs/getting_started/en/dev/reference/source-code.html#set-up-build-environment-info)" section. -- cgit 1.2.3-korg From d4493345395c1fcff2efbb7c2b98939469e6c73b Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 13 Nov 2018 15:40:14 -0800 Subject: Getting Started Image Workflow Created new workflow to build out an AGL image. This commit goes through the Intel-specific build. Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-intro.md | 2 +- docs/getting-started/customize_bitbake_conf.md | 53 ----- docs/getting-started/image-workflow-build.md | 17 ++ docs/getting-started/image-workflow-cust-build.md | 119 ++++++++++ docs/getting-started/image-workflow-download-sw.md | 108 +++++++++ .../image-workflow-initialize-build-environment.md | 255 +++++++++++++++++++++ docs/getting-started/image-workflow-intro.md | 31 +++ docs/getting-started/image-workflow-prep-host.md | 76 ++++++ .../images/image-developer-workflow.png | Bin 0 -> 48502 bytes docs/getting-started/machines/intel.md | 231 ++++++++----------- docs/getting-started/source-code.md | 201 ---------------- 11 files changed, 706 insertions(+), 387 deletions(-) delete mode 100644 docs/getting-started/customize_bitbake_conf.md create mode 100644 docs/getting-started/image-workflow-build.md create mode 100644 docs/getting-started/image-workflow-cust-build.md create mode 100644 docs/getting-started/image-workflow-download-sw.md create mode 100644 docs/getting-started/image-workflow-initialize-build-environment.md create mode 100644 docs/getting-started/image-workflow-intro.md create mode 100644 docs/getting-started/image-workflow-prep-host.md create mode 100644 docs/getting-started/images/image-developer-workflow.png delete mode 100644 docs/getting-started/source-code.md (limited to 'docs') diff --git a/docs/getting-started/app-workflow-intro.md b/docs/getting-started/app-workflow-intro.md index 073496c..256e91f 100644 --- a/docs/getting-started/app-workflow-intro.md +++ b/docs/getting-started/app-workflow-intro.md @@ -14,7 +14,7 @@ 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. diff --git a/docs/getting-started/customize_bitbake_conf.md b/docs/getting-started/customize_bitbake_conf.md deleted file mode 100644 index fa466ca..0000000 --- a/docs/getting-started/customize_bitbake_conf.md +++ /dev/null @@ -1,53 +0,0 @@ -# Customize AGL build - -To customize the AGL build, you edit local.conf file, located in the build/conf directory. - -```bash -edit $AGL_TOP/build/conf/local.conf -``` - -## Buildhistory - -The OpenEmbedded build system creates this directory when you enable the build history feature. - -```bash -INHERIT += "buildhistory" -BUILDHISTORY_COMMIT = "1" -``` - -For more information please check [Here][buildhistory] - -## Deletion of temporary workspace - -Removes work files after the OpenEmbedded build system has finished with them. - -```bash -INHERIT += "rm_work" -``` - -For more information please check [Here][rm_work] - -## Share sstate cache - -The directory for the shared state cache. - -```bash -SSTATE_DIR = "${HOME}/workspace_agl/sstate-cache" -``` - -For more information please check [Here][share_sstatecache] - -## Share Download directory - -The central download directory used by the build process to store downloads. - -```bash -DL_DIR = "${HOME}/workspace_agl/downloads" -``` - -For more information please check [Here][share_download] - -[buildhistory]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-build-output-quality -[rm_work]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-tasks-rm_work -[share_sstatecache]: https://wiki.yoctoproject.org/wiki/Enable_sstate_cache -[share_download]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DL_DIR diff --git a/docs/getting-started/image-workflow-build.md b/docs/getting-started/image-workflow-build.md new file mode 100644 index 0000000..bb2056e --- /dev/null +++ b/docs/getting-started/image-workflow-build.md @@ -0,0 +1,17 @@ +# 5. Building the AGL Image + +Building the AGL image involves running BitBake with a specified target. +Depending on whether you are building the image for the first time or if this +is a subsequent build, the time needed for the build could be significant. + +It is critical that you specify the correct options and configurations for the +build before executing the `bitbake` command. +The previous sections in the "Image Development Workflow" have treated this setup +in a generic fashion. +This section, provides links to topics with instructions needed to create images for four +supported platforms: + +* [Most Intel-based 64-Bit Boards](./machines/intel.html/overview) +* The Quick EMUlator (QEMU) +* R Car Starter Kit Gen3 Board +* Raspberry PI 2 or 3 diff --git a/docs/getting-started/image-workflow-cust-build.md b/docs/getting-started/image-workflow-cust-build.md new file mode 100644 index 0000000..2e712a5 --- /dev/null +++ b/docs/getting-started/image-workflow-cust-build.md @@ -0,0 +1,119 @@ +# 4. Customizing Your Build + +Because the build process is based on BitBake and the Yocto Project, +build customizations are driven through configuration files used during +the build. + +Lots of configuration files exist that define a build. +However, the primary one that acts as a global configuration mechanism is the +`local.conf` file, which is found in the Build Directory in a folder named "conf". + +Before you start your build process, you should open up the `local.conf` file +and look through it to be sure the general configurations are correct. +The file is well commented so you should be able to understand what the +various variables accomplish. + +To view and customize the `local.conf` file, use any text editor: + +```bash +$ vi $AGL_TOP/build/conf/local.conf +``` + +As mentioned in the "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment.html)" section, +the `local.conf` file gets augmented with AGL configuration fragments based on +how you execute the `aglsetup.sh` script. +You can see those fragments at the end the configuration file. + +Even though your build should work fine after running the `aglsetup.sh` script, +you might consider editing your `local.conf` file to use one or more of the +following configurations. + +## Capturing Build History + +You can enable build history to help maintain the quality of your build output. +You can use it to highlight unexpected and possibly unwanted changes in the build output. +Basically, with build history enabled, you get a record of information about the contents +of each package and image. +That information is committed to a local Git repository where you can examine it. + +To enable build history, make sure the following two lines are in your +`local.conf` file: + +```bash +INHERIT += "buildhistory" +BUILDHISTORY_COMMIT = "1" +``` + +See the +"[Maintaining Build Output Quality](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#maintaining-build-output-quality)" +section in the Yocto Project Reference Manual for a complete discussion on +build history. + +## Deleting Temporary Workspace + +During a build, the build system uses a lot of disk space to store temporary files. +You can ease the burden on your system and speed up the build by configuring the build +to remove temporary workspace. + +You need to inherit the `rm_work` class by using this statement in the `local.conf` file: + +```bash +INHERIT += "rm_work" +``` + +You can read about the class in the +"[rm_work.bbclass](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#ref-classes-rm-work)" +section of the Yocto Project Reference Manual for more information. + +## Pointing at Shared State Cache Locations + +The build system creates everything from scratch unless BitBake can determine that parts do not need to be rebuilt. Fundamentally, building from scratch is attractive as it means all parts are built fresh and there is no possibility of stale data causing problems. +When developers hit problems, they typically default back to building from scratch so they know the state +of things from the start. + +The build process uses Shared State Cache (sstate) to speed up subsequent builds. +This cache retains artifacts that can be re-used once it is determined that they +would not be different as compared to a re-built module. + +For the AGL build, you can specify the location for sstate files by including the +following in the `local.conf` file: + +```bash +SSTATE_DIR = "${HOME}/workspace_agl/sstate-cache" +``` + +also, in the `local.conf` file, you can specify additional directories in which the build +system can look for shared state information. +Use the following form in your file to list out the directories you want the build +process to look at for sstate information: + + +```bash +SSTATE_MIRRORS ?= "\ + file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ + file://.* file:///some/local/dir/sstate/PATH" +``` + +If you want to know more about the Yocto Project sstate mechanism, see the +"[Shared State Cache](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#shared-state-cache)" +section in the Yocto Project Reference Manual. + +## Preserving the Download Directory + +During the initial build, the system downloads many different source code tarballs +from various upstream projects. +Downloading these files can take a while, particularly if your network +connection is slow. +The process downloads files into a +"[download directory](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#var-DL_DIR)". +The `DL_DIR` variable defines the download directory. +For subsequent builds, you can preserve this directory to speed up the download +part of a build. + +The default download directory is in a folder named "downloads". +For the AGL build you can set the download directory by adding the following to your +`local.conf` file: + +```bash +DL_DIR = "${HOME}/workspace_agl/downloads" +``` diff --git a/docs/getting-started/image-workflow-download-sw.md b/docs/getting-started/image-workflow-download-sw.md new file mode 100644 index 0000000..ae41a34 --- /dev/null +++ b/docs/getting-started/image-workflow-download-sw.md @@ -0,0 +1,108 @@ +# 2 Downloading AGL Software + +Once you have determined the build host can build an AGL image, +you need to download the AGL source files. +The AGL source files, which includes the Yocto Project layers, are +maintained on the AGL Gerrit server. +For information on how to create accounts for Gerrit, see the +[Getting Started with AGL](https://wiki.automotivelinux.org/start/getting-started) +wiki page. + +The remainder of this section provides steps on how to download the AGL source files: + +1. **Define Your Top-Level Directory:** + You can define an environment variable as your top-level AGL workspace folder. + Following is an example that defines the `$HOME/workspace_agl` folder using + an environment variable named "AGL_TOP": + + ```bash + $ export AGL_TOP=$HOME/workspace_agl + $ mkdir -p $AGL_TOP + ``` + +2. **Download the `repo` Tool and Set Permissions:** + AGL Uses the `repo` tool for managing repositories. + Use the following commands to download the tool and then set its + permissions to allow for execution: + + ```bash + $ mkdir -p ~/bin + $ export PATH=~/bin:$PATH + $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo + $ chmod a+x ~/bin/repo + ``` + + **NOTE:** See the + "[Repo Command Reference](https://source.android.com/setup/develop/repo)" + for more information on the `repo` tool. + +3. **Download the AGL Source Files:** + Depending on your development goals, you can either download the + latest stable AGL release branch, or the "cutting-edge" (i.e. "master" + branch) files. + + * **Stable Release:** + Using the latest stable release gives you a solid snapshot of the + latest know release. + The release is static, tested, and known to work. + To download the latest stable release branch (i.e. Flounder 6.0), use + the following commands: + + ```bash + $ cd $AGL_TOP + $ repo init -b flounder -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + $ repo sync + ``` + + * **Cutting-Edge Files:** + Using the "cutting-edge" AGL files gives you a snapshot of the + "master" directory. + The resulting local repository you download is dynamic and can become + out-of-date with the upstream repository depending on community contributions. + The advantage of using "cutting-edge" AGL files is that you have the + absolute latest features, which are often under development, for AGL. + + To download the "cutting-edge" AGL files, use the following commands: + + ```bash + $ cd $AGL_TOP + $ repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + $ repo sync + ``` + + Once you `sync` the repository, you have the AGL files in the form of + "layers" (e.g. `meta-*` folders). + You also have the `poky` repository in your AGL workspace. + + Listing out the resulting directory structure appears as follows: + + ``` + $ tree -L 1 + . + ├── build + ├── meta-agl + ├── meta-agl-demo + ├── meta-agl-devel + ├── meta-agl-extra + ├── meta-altera + ├── meta-boundary + ├── meta-freescale + ├── meta-freescale-3rdparty + ├── meta-freescale-distro + ├── meta-intel + ├── meta-intel-iot-security + ├── meta-oic + ├── meta-openembedded + ├── meta-qcom + ├── meta-qt5 + ├── meta-raspberrypi + ├── meta-renesas + ├── meta-renesas-rcar-gen3 + ├── meta-rust + ├── meta-sdl + ├── meta-security-isafw + ├── meta-ti + ├── meta-updater + ├── meta-virtualization + └── poky + ``` diff --git a/docs/getting-started/image-workflow-initialize-build-environment.md b/docs/getting-started/image-workflow-initialize-build-environment.md new file mode 100644 index 0000000..eed41e7 --- /dev/null +++ b/docs/getting-started/image-workflow-initialize-build-environment.md @@ -0,0 +1,255 @@ +# 3. Initializing Your Build Environment + +Part of the downloaded AGL software is a setup script that you must +run to initialize the build environment. + +## `aglsetup.sh` Script + +You can find this script here: + +``` +$AGL_TOP/meta-agl/scripts/aglsetup.sh +``` + +The script accepts many options that allow you to define build parameters such +as the target hardware (i.e. the machine), build directory, and so forth. +Use the following commands to see the available options and script syntax: + +``` +$ bash +$ cd $AGL_TOP +$ source meta-agl/scripts/aglsetup.sh -h +``` + +## AGL Features + +Before running the `aglsetup.sh`, you should understand what AGL features you +want to include as part of your image. +The script's help output lists available features and shows you the layers in +which they reside. + +Following is a list of the available features: + +``` +Available features: + [meta-agl] + agl-all-features :( agl-demo agl-appfw-smack agl-devel agl-hmi-framework agl-netboot agl-sota agl-sdl ) + agl-appfw-smack + agl-archiver + agl-ci + agl-ci-change-features :( agl-demo agl-appfw-smack agl-devel agl-hmi-framework agl-devel agl-netboot agl-appfw-smack agl-sdl ) + agl-ci-change-features-nogfx :( agl-devel agl-netboot agl-appfw-smack ) + agl-ci-snapshot-features :( agl-demo agl-appfw-smack agl-devel agl-hmi-framework agl-devel agl-netboot agl-appfw-smack agl-archiver agl-sdl agl-ptest ) + agl-ci-snapshot-features-nogfx :( agl-devel agl-netboot agl-appfw-smack agl-isafw agl-archiver agl-ptest ) + agl-devel + agl-isafw + agl-netboot + agl-ptest + agl-sota + [meta-agl-demo] + agl-demo :( agl-appfw-smack agl-devel agl-hmi-framework ) + agl-iotivity + agl-sdl + [meta-agl-devel] + agl-audio-4a-framework + agl-audio-soundmanager-framework + agl-egvirt + agl-hmi-framework + agl-oem-extra-libs + agl-renesas-kernel + [meta-agl-extra] + agl-localdev + eas +``` + +To find out exactly what a feature provides, **WE NEED SOME GUIDANCE HERE. MAYBE SOME INDIVIDUAL README FILES LOCATED IN THE TEMPLATE AREAS FOR THE FEATURES**. + +An AGL feature is a configuration that accounts for specific settings +and dependencies needed for a particular build. +For example, specifying the "agl-demo" feature makes sure that the +`aglsetup.sh` script creates configuration files needed to build the +image for the AGL demo. + +Following are brief descriptions of the AGL features you can specify on the +`aglsetup.sh` command line: + +* **agl-all-features**: A set of AGL default features. + Do not think of this set of features as all the AGL features. + +* **agl-appfw-smack**: Enables IoT.bzh Application Framework plus SMACK and + Cynara. + +* **agl-archiver**: Enables the archiver class for releases. + +* **agl-ci**: Flags used for Continuous Integration (CI). + Using this feature changes the value of the + [`IMAGE_FSTYPES`](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#var-IMAGE_FSTYPES) + variable. + +* **agl-ci-change-features**: Enables features for CI builds for Gerrit changes. + +* **agl-ci-change-features-nogfx**: Enables features for CI builds for Gerrit changes + for targets that use binary graphics drivers (i.e. builds without graphics). + +* **agl-ci-snapshot-features**: Enables features for CI daily snapshot builds. + +* **agl-ci-snapshot-features-nogfx**: Enables features for CI daily snapshot builds for + targets that use binary graphics drivers (i.e. builds without graphics). + +* **agl-devel**: Activates development options such as an empty root password, + debuggers, strace, valgrind, and so forth. + +* **agl-isafw**: Enables an image security analysis framework. + **NOTE:** This feature is deprecated. + +* **agl-netboot**: Enables network boot support through Trivial File Transfer Protocol (TFTP) and Network Block Device (NBD) protocol. + Netboot is needed for CI and useful for development to avoid writing + sdcards. Needs additional setup. + + + +* **agl-ptest**: Enables + [Ptest](https://yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#testing-packages-with-ptest) + as part of the build. + +* **agl-sota**: Enables State of the Art (SOTA) components and dependencies. + Includes meta-sota, meta-file systems, meta-ruby, and meta-rust. + +* **agl-demo**: Enables the layers meta-agl-demo and meta-qt5. + You need agl-demo if you are going to build the agl-demo-platform. + +* **agl-iotivity**: Enables iotivity such as status unclear, needs check, and needs removal. + +* **agl-sdl**: Enables or adds SDL to the build. + +* **agl-audio-4a-framework**: Enables AGL advanced audio architecture, which is an exclusive switch for audio framework. + +* **agl-audio-soundmanager-framework**: Enables Soundmanager framework, which is an exclusive switch for audio framework. + +* **agl-egvirt**: Enables virtualization support for the R-Car. + +* **agl-hmi-framework**: Enables HMI framework. + HMI framework is enabled by default. + +* **agl-oem-extra-libs**: Pulls in additional libraries. + **NOTE:** This feature is under construction. + It needs further work and testing. + +* **agl-renesas-kernel**: Enables renesas-specific kernel options. + +* **agl-telemetry**: Enables the telemetry demo. To use this feature, + you must convert it into agl-profile-telematics. + **NOTE:** agl-telemetry is not in the layer. + +* **agl-localdev**: Adds a local layer named "meta-localdev" in the + meta directory and a local.dev.inc configuration file when that file + is present. + + This feature provides a shortcut for using the layer meta-localdev + in the top-level folder for easy modifications to your own recipes. + +* **eas**: I don't know what this does. + +## Example + +Following is an example that initializes the build environment, selects "beaglebone" +for the machine, and chooses the "agl-demo" feature, which also includes the +"agl-appfw-smack", "agl-devel", and "agl-hmi-framework" features: + +``` +$ source meta-agl/scripts/aglsetup.sh -m beaglebone agl-demo +aglsetup.sh: Starting +Generating configuration files: + Build dir: /home/scottrif/workspace_agl/build + Machine: beaglebone + Features: agl-appfw-smack agl-demo agl-devel agl-hmi-framework + Running /home/scottrif/workspace_agl/poky/oe-init-build-env + Templates dir: /home/scottrif/workspace_agl/meta-agl/templates/base + Config: /home/scottrif/workspace_agl/build/conf/bblayers.conf + Config: /home/scottrif/workspace_agl/build/conf/local.conf + Setup script: /home/scottrif/workspace_agl/build/conf/setup.sh + Executing setup script ... --- beginning of setup script + fragment /home/scottrif/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh + fragment /home/scottrif/workspace_agl/meta-agl/templates/base/99_setup_EULAconf.sh + end of setup script +OK +Generating setup file: /home/scottrif/workspace_agl/build/agl-init-build-env ... OK +aglsetup.sh: Done + + Shell environment set up for builds. + +You can now run 'bitbake target' + +Common targets are: + - meta-agl: (core system) + agl-image-minimal + agl-image-minimal-qa + + agl-image-ivi + agl-image-ivi-qa + agl-image-ivi-crosssdk + + agl-image-weston + + - meta-agl-demo: (demo with UI) + agl-demo-platform (* default demo target) + agl-demo-platform-qa + agl-demo-platform-crosssdk + + agl-demo-platform-html5 +$ +``` + +Running the script creates the Build Directory if it does not already exist. +For this example, the Build Directory is "$AGL_TOP/workspace_agl/build". + +The script's output also indicates the machine and AGL features selected for the build. + +The script creates two primary configuration files used for the build: `local.conf` and `bblayers.conf`. +Both these configuration files are located in the Build Directory in the `conf` folder. +If you were to examine these files, you would find standard Yocto Project +configurations along with AGL configuration fragments, which are driven by the +machine (i.e. beaglebone) and the AGL features specified as part of the +script's command line. + +The end result is configuration files specific for your build in the AGL development environment. + +Finally, part of the `aglsetup.sh` script makes sure that any End User License Agreements (EULA) +are considered. +You can see that processing in the script's output as well. + +**NOTE:** Use of the `local.conf` and `bblayers.conf` configuration files is fundamental +in the Yocto Project build environment. +Consequently, it is fundamental in the AGL build environment. +You can find lots of information on configuring builds in the Yocto Project +documentation set. +Here are some references if you want to dig into configuration further: + +* [Customizing Images Using local.conf](https://yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconf) +* [Local](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#ref-varlocality-config-local) +* [build/conf/local.conf](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#structure-build-conf-local.conf) +* [build/conf/bblayers.conf](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf) +* [BBLAYERS](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#var-BBLAYERS) +* [User Configuration](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#user-configuration) +* [Enabling Your Layer](https://yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#enabling-your-layer) diff --git a/docs/getting-started/image-workflow-intro.md b/docs/getting-started/image-workflow-intro.md new file mode 100644 index 0000000..ad36d01 --- /dev/null +++ b/docs/getting-started/image-workflow-intro.md @@ -0,0 +1,31 @@ +# Overview # + +The AGL image development workflow consists of setting up +the system (i.e. the build host) that builds the image and finishes with +using the +[Yocto Project](https://yoctoproject.org) to create an image +targeted towards specific hardware. + +The following figure and list overview the AGL image 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. + +
+ +1. Prepare your build host to use use the tools needed to build your image. + +2. Download the AGL software into a local Git repository on your build host. + +3. Run the build environment script to initialize variables and paths needed for the build. + +4. Make sure your build configuration is defined exactly how you want it for your build. + +5. Use + [BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html) + to build your image. diff --git a/docs/getting-started/image-workflow-prep-host.md b/docs/getting-started/image-workflow-prep-host.md new file mode 100644 index 0000000..1205ac0 --- /dev/null +++ b/docs/getting-started/image-workflow-prep-host.md @@ -0,0 +1,76 @@ +# 1. Preparing Your Build Host + +Preparing your build host so that it can build an AGL image means +making sure your system is set up to use the +[Yocto Project](https://yoctoproject.org) OpenEmbedded build system, +which is based on +[BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html). + +This section presents minimal information so you can prepare the build host +to use the "Rocko" version of the Yocto Project (i.e. version 2.4.4). +If you want more details on how the Yocto Project works, you can reference +the Yocto Project documentation +[here](https://www.yoctoproject.org/docs/). + +**NOTE:** This entire section presumes you want to build an image. +You can skip the entire build process if you want to use a ready-made +development image. +The +[supported images][AGL snapshots master latest] exist for several boards as +well as for the Quick EMUlator (QEMU). +See the +"[Downloading an Image](./app-workflow-image.html#downloading-an-image)" +section for more information on the ready-made images. + +1. **Use a Supported Linux Distribution:** To use the AGL software, it is + recommended that your build host is a native Linux machine that runs a + Yocto Project supported distribution as described by the + "[Supported Linux Distributions](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#detailed-supported-distros)" + section in the Yocto Project Reference Manual. + Basically, you should be running a recent version of Ubuntu, Fedora, openSUSE, + CentOS, or Debian. + + If you must use a build host that is not a native Linux machine, you can + install and use a Docker container. + The container contains the same development environment (i.e. distros, packages, + and so forth) as would a properly prepared build host running a supported + Linux distribution. + For information on how to install and set up this Docker container, see the + "[AGL SDK Quick Setup](./setup-sdk-environment.html#step-1-install-docker)" + section. + +2. **Be Sure Your Build Host Has Enough Free Disk Space:** + Your build host should have at least 50 Gbytes. + +3. **Be Sure Tools are Recent:** You need to have recent versions for + the following tools: + + * Git 1.8.3.1 or greater + * Tar 1.27 or greater + * Python 3.4.0 or greater + + If your distribution does not meet these minimal requirements, see the + "[Required Git, tar, and Python Versions](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#required-git-tar-and-python-versions)" + section in the Yocto Project Reference Manual for steps that you can + take to be sure you have these tools. + +4. **Install Essential, Graphical, and Eclipse Plug-in Build Host Packages:** + Your build host needs certain host packages. + Depending on the Linux distribution you are using, the list of + host packages differ. + See + "[The Build Host Packages](https://www.yoctoproject.org/docs/2.4.4/yocto-project-qs/yocto-project-qs.html#packages)" + section of the Yocto Project Quick Start for information on the packages you need. + + **NOTE:** If you are using the CentOS distribution, you need to + separately install the epel-release package and run the `makecache` command as + described in + "[The Build Host Packages](https://www.yoctoproject.org/docs/2.4.4/yocto-project-qs/yocto-project-qs.html#packages)" + section of the Yocto Project Quick Start. + + Aside from the packages listed in the previous section, you need the following: + + * **Ubuntu and Debian:** curl + * **Fedora:** curl + * **OpenSUSE:** glibc-locale curl + * **CentOS:** curl diff --git a/docs/getting-started/images/image-developer-workflow.png b/docs/getting-started/images/image-developer-workflow.png new file mode 100644 index 0000000..daaeda0 Binary files /dev/null and b/docs/getting-started/images/image-developer-workflow.png differ diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md index 34957a8..74988a1 100644 --- a/docs/getting-started/machines/intel.md +++ b/docs/getting-started/machines/intel.md @@ -1,186 +1,153 @@ -# Running AGL on Intel MinnowBoard (and most Intel 64 bits HW) - -## Scope - -This documentation is aiming at people who want to run Automotive Grade -Linux (AGL) on Intel Hardware (HW). -While the reference HW used by AGL project is the Open Source MinnowBoard, this documentation [MinnowBoard wiki](https://minnowboard.org/) can be used to enable most of 64-bit Intel Architecture (IA) platforms using UEFI as boot loader. -In addition to the MinnowBoard, support for the [upCore & UpSquared boards](http://www.up-board.org/upsquared/) has been added. -You need to run the 64-bit version of the UEFI bootloader. +# Building for Most Intel 64-Bit Hardware Platforms + +Although the reference hardware used by the AGL Project is the 64-bit Open Source MinnowBoard, +you can use the information found on the "[MinnowBoard wiki](https://minnowboard.org/)" +to enable most 64-bit Intel Architecture (IA) platforms that use the 64-bit +UEFI as the boot loader. +In addition to the MinnowBoard, support for the +[upCore & UpSquared boards](http://www.up-board.org/upsquared/) exists. MinnowBoard Max and Turbot as well as Joule are both 64-bit capable. -**Note**: This page is more focused on those who want to create bespoke AGL images and BSPs. - -If you are interested in creating ***applications*** to run on AGL, please visit the [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) documentation. - -UEFI has evolved a lot recently and you likely want to check that your HW firmware is up-to-date, this is mandatory for both the MinnowBoard-Max and the Joule. Not required on Minnowboard-Turbo and Up boards. - -[`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max) -[`https://software.intel.com/en-us/flashing-the-bios-on-joule`](https://software.intel.com/en-us/flashing-the-bios-on-joule) - -## Where to find an AGL bootable image +If you are interested in creating ***applications*** to run on hardware booted +using an image built with the AGL Project, see the following: -### Download a ready made image - -AGL provides ready made images for developers. -You will find them on [AGL Download web site](https://download.automotivelinux.org/AGL/release) -image are located in YourPreferedRelease/intel-corei7-64/deploy/images/intel-corei7-64/ -Create a bootable SD card with the script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) -check the available options with the -v option. mkefi-agl.sh -v - -### Building an AGL image from scratch using Yocto - -**Note**: an alternative method for building an image is to use the AGL SDK delivered in a Docker container. - -There is currently no SDK dedicated to IA but the SDK provided for the Porter Board can build an IA image without changes (just `aglsetup.sh` needs to call for Intel). +* [Application Development Workflow](../../../app-workflow-intro.html/overview) +* [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) -See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf "wikilink"). +UEFI has significantly evolved and you will likely want to check that your hardware's +firmware is up-to-date. +You should make this check for both the MinnowBoard-Max and the Joule platforms. +You do not need to make this check for the MinnowBoard-Turbo and Up platforms: -#### Download AGL source code +* [`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max) +* [`https://software.intel.com/en-us/flashing-the-bios-on-joule`](https://software.intel.com/en-us/flashing-the-bios-on-joule) -Downloading the AGL sources from the various Git repositories is automated with the `repo` tool. Basic steps to download the AGL source code is described below and for more advanced topics involving the `repo` tool, please refer to the [`repo` documentation](https://source.android.com/source/using-repo.html "wikilink"). +## 1. Making Sure Your Build Environment is Correct -To install the `repo` tool: +The +"[Initializing Your Build Environment](../../../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +section presented generic information for setting up your build environment +using the `aglsetup.sh` script. +If you are building for an Intel 64-bit platform, you need to specify some +specific options when you run the script: ```bash - mkdir -p ~/bin; - export PATH=~/bin:$PATH; - curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo; - chmod a+x ~/bin/repo; +$ source meta-agl/scripts/aglsetup.sh \ + -m intel-corei7-64 \ + agl-devel agl-demo agl-appfw-smack agl-netboot agl-audio-4a-framework ``` -#### Configuring for the current *(older)* stable (Electric Eel 5.0.x) - -```bash - cd AGL-5.0.x; - repo init -b eel -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -``` +The "-m" option specifies the "intel-corei7-64" machine. +If you were building for a Joule developer kit, you would use the +"-m joule" option. -#### Configuring for master (DD) +The list of AGL features used with script are appropriate for the AGL demo image suited +for the Intel 64-bit target. +The "agl-netboot" option creates the correct Initial RAM Filesystem (initramfs) +image even if you do not boot from a network. -```bash - cd AGL-master; - repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo; -``` +## 2. Using BitBake -Once that you repo is initialised either with the stable or WIP, you need to sync the repo to fetch the various git trees. +This section shows the `bitbake` command used to build the AGL image. +Before running BitBake to start your build, it is good to be reminded that AGL +does provide pre-built images for developers that work with supported hardware. +You can find these pre-built images on the +[AGL Download web site](https://download.automotivelinux.org/AGL/release). -#### Downloading the configured AGL source code +For supported Intel images, the filenames have the following form: -```bash - repo sync; ``` - -#### Building the AGL distro - -You are now ready to initialise your Yocto build. -When running the command: - -```bash - source meta-agl/scripts/aglsetup.sh -h +//intel-core17-64/deploy/images/intel-core17-64/bzImage-intel-corei7-64.bin ``` -You will notice the Intel entries +Start the build using the `bitbake` command. +**NOTE:** An initial build can take many hours depending on your +CPU and and Internet connection speeds. +The build also takes approximately 100G-bytes of free disk space. -```bash - intel-corei7-64 - joule -``` - -Simply select that entry to replace porter in the -m option. -**Note:** agl-netboot option is required to create the right initramfs even if you do not boot from a network - -```bash - source meta-agl/scripts/aglsetup.sh \ - -m intel-corei7-64 \ - -b build \ - agl-devel agl-demo agl-appfw-smack agl-netboot agl-audio-4a-framework -``` - -**Note:** use the option "-m joule" when building for a Joule developer Kit target. - -Start the build **This can take several hours depending of your CPU and -internet connection and will required several GB on /tmp as well as on your build directory** +For this example, the target is "agl-demo-platform": ```bash bitbake agl-demo-platform ``` -**Your newly baked disk image (.wic.xz) will be located at**: - `tmp/deploy/images/intel-corei7-64/` - -##### Alternative: Download a *ready made* image from AGL web site - -The Continuous Integration (CI) process from AGL creates and publish daily and stable builds. -Pointers to both can be found in [AGL supported HW](https://wiki.automotivelinux.org/agl-distro) (see Reference BSP/Intel). +The build process puts the resulting image in the Build Directory: -Once you have validated your process you can start to play/work with the snapshot pointer. - -Note that snapshot build may not work. +``` +/tmp/deploy/images/intel-corei7-64/ +``` -Follow the directory: +**WRITER NOTE:** I am not sure what to do with the following information: -`intel-corei7-64/deploy/images/intel-corei7-64/` +An alternative method for building an image is to use the AGL SDK delivered in a Docker container. -and download the file: +There is currently no SDK dedicated to IA but the SDK provided for the Porter Board can build an IA image without changes (just `aglsetup.sh` needs to call for Intel). -`agl-demo-platform-intel-corei7-64.hddimg` +See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf "wikilink"). -## Create a bootable media +## 3. Creating Bootable Media -Depending your target HW you will use an USB stick, an SD card or a HDD/SDD. +Depending your target hardware you will use an USB stick, an SD card or a HDD/SDD. The creation process remains the same independently of the selected support. It does require to have access to a Linux machine with `sudo` or root password. -### Insert you removable media in the corresponding interface - -### Check the device name where the media can be accessed with the command - -```bash - lsblk - # Note that you want the name of the raw device not of a partition on the media - #(eg. /dev/sdc or /dev/mmcblk0) -``` +Create a bootable SD card with the script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) +check the available options with the -v option. mkefi-agl.sh -v -### Download the script `mkefi-agl.sh` +1. **Insert Media Device:** + Insert your removable media into the corresponding interface. -This script is present in the directory meta-agl/scripts from blowfish 2.0.4 : [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) +2. **Determine the Name of Your Media Device:** + Use the `lsblk` command to make sure you know the name of the device to which you will be writing. -Alternatively you can download it from the following Git repo: + ```bash + lsblk + # You want the name of the raw device and not the name of a partition on the media. + #(e.g. /dev/sdc or /dev/mmcblk0) + ``` -[https://github.com/dominig/mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh) +3. **Download the `mkefi-agl.sh` Script:** + You can find the script in the "meta-agl/scripts" folder of your AGL source files. -### check the available options + Alternatively, you can download the script from the following Git repository: -```bash - sh mkefi-agl.sh -v; -``` + [https://github.com/dominig/mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh) -### create your media with the command adjusted to your configuration +4. **Create Your Bootable Media:** + Run the following to see `mkefi-agl.sh` usage information: -```bash - sudo sh mkefi-agl.sh MyAglImage.hdd /dev/sdX - #/dev/sdX is common for USB stick, /dev/mmcblk0 for laptop integrated SD card reader -``` + ```bash + ./mkefi-agl.sh -v + ``` -## Boot the image on the target device + Supply the name of your actual image and device name and run the script. + The following example assumes a USB device (e.g. `/dev/sdb`) and the image + `intel-corei7-64.hdd`: -1. Insert the created media with the AGL image in the target device + ```bash + $ sudo ./mkefi-agl.sh intel-corei7-64.hdd /dev/sdb + # /dev/sdX is common for USB stick where "X" is "b". + # /dev/mmcblk0 is common for an integrated SD card reader in a notebook computer. + ``` -1. Power on the device +## 4. Booting the Image on the Target Device -1. Select Change one off boot option (generally F12 key during power up) +Follow these steps to boot your image on the target device: -1. Select your removable device +1. Insert the bootable media that contains the AGL image into the target device. -1. Let AGL boot +2. Power on the device. -**Note:**: depending on the speed of the removable media, the first boot may not complete, in that case simply reboot the device. +3. As the device boots, access the boot option screen. + You generally accomplish this with the F12 key during the power up operation. -This is quite common with USB2 sticks. +4. From the boot option screen, select your bootable media device. -By default the serial console is configured and activated at the rate of 115200 bps. +5. Save and exit the screen and let the device boot from your media. -## How to create your 1st AGL application + **NOTE:**: Depending on the speed of your removable media, the first boot might + not complete. + If this is the case, reboot the device a second time. + It is common with USB sticks that you need to boot a couple of times. -[Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) + For Intel devices, the serial console is configured and activated at the rate of 115200 bps. diff --git a/docs/getting-started/source-code.md b/docs/getting-started/source-code.md deleted file mode 100644 index 3c5d6f4..0000000 --- a/docs/getting-started/source-code.md +++ /dev/null @@ -1,201 +0,0 @@ -# Introduction: Building target AGL image with Yocto project - -The standard Yocto process is made of the following steps: - -* Setting up your operating system. -* Setting up the build environment for R-Car BSP. -* Downloading the proprietary drivers and installing them in the build environment (if needed). -* Build the image. -* Boot using SD-CARD. - * Create an SD-CARD. - * Configure to boot on SD-CARD. - * Copy the image to the SD-CARD. - * Boot the board on it. - -For convenience, the resulting development images are made available [Here][AGL snapshots master latest] - -If you want to bypass the build phase and quick boot the board, you can download the image tarball and the kernel then follow the installation procedure. - -## Setting up your operating system - -The very first step is to ensure that your system can run the build system of the Yocto Project. - -**Important**: it only runs on Linux - -* if your system is Windows© or iOS© you should use a virtualization solution (Virtualbox, VMWare ...) to run a Linux VM on your system. - -For AGL 6.0, Yocto Project 2.4, known as rocko, has been selected for the BSP and build system. - -Reference data for configuring your system can be found in the Yocto documentation [Here][yocto ref Manual] - -Here after an extract of this documentation for most common Linux distributions: - -* The build system should be able to run on any modern distributions that has the following versions for: - * Python - * Git 1.7.8 or greater - * tar 1.24 or greater - * GCC, … - -**Note**: - -* Python 2.7.3 or greater excluding Python 3.x, which is not supported. - -### Ubuntu and Debian - -The essential and graphical support packages you need for a supported Ubuntu or Debian distribution are shown in the following command: - -```bash -sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ - build-essential chrpath socat libsdl1.2-dev xterm cpio curl -``` - -**Note**: - -* Also note that for this tutorial, the utility 'curl' has been added to the list of packages to install. - -### Fedora - -The essential and graphical packages you need for a supported Fedora distribution are shown in the following command: - -```bash -sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ - diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ - ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \ - SDL-devel xterm curl -``` - -### OpenSUSE - -The essential and graphical packages you need for a supported OpenSUSE distribution are shown in the following command: - -```bash -sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \ - diffstat texinfo python-curses patch socat libSDL-devel xterm curl \ - python3 python3-curses glibc-locale -``` - -### CentOS - -The essential and graphical packages you need for a supported CentOS distribution are shown in the following command: - -```bash -sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ - diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ - socat SDL-devel xterm curl -``` - -## Download AGL Source Code - -The AGL source code and Yocto layers are maintained on the AGL Gerrit server. -For information on how to create accounts for gerrit see [Getting Started with AGL][Getting Started with AGL]. - -### Setting up the build environment - -In the following, your top level directory is noted as “AGL_TOP”. -For example, we will set AGL_TOP to point to a directory “$HOME/workspace_agl”: - -```bash -export AGL_TOP=$HOME/workspace_agl -mkdir -p $AGL_TOP -``` - -### Prepare Repo Tool - -AGL Uses the 'repo' tool for managing repositories. -You need to setup layers of AGL. -You can use the commands below to prepare Repo: - -```bash -mkdir -p ~/bin -export PATH=~/bin:$PATH -curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo -chmod a+x ~/bin/repo -``` - -**Note**: - -* More information about the tool 'repo' [Here][repo info] - -### Download source - -You can choose your source release - -### Download Latest Stable Release - -To download all layers for the for the latest stable release, eel 5.0.3: - -```bash -cd $AGL_TOP -repo init -b eel -m eel_5.1.0.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -repo sync -``` - -### Download Master Branch - -To download all code from master: - -```bash -cd $AGL_TOP -repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -repo sync -``` - -## Set up Build Environment Info - -AGL has created a set up script for defining the target build and desired optional features. - -To get a complete list of the options available run. - -```bash -cd $AGL_TOP -source meta-agl/scripts/aglsetup.sh -h -``` - -Once you run aglsetup.sh with your desired parameters, you can build any target desired. - -## Features supported by aglsetup - -Here is the list of features for AGL 2.1 that can be specified in the aglsetup.sh command line: - -* in **meta-agl** - * agl-all-features - * agl-appfw-smack: enables IoT.bzh Application Framework + SMACK + Cynara - * agl-archiver - * agl-ci - * agl-ci-change-features - * agl-ci-change-features-nogfx - * agl-ci-snapshot-features - * agl-ci-snapshot-features-nogfx - * agl-devel: activate development options (empty root password, debugger, strace, valgrind …) - * agl-gplv2 - * agl-isafw - * agl-netboot: enable network boot support through TFTP and NBD (see meta-netboot layer) - * agl-profile-graphical - * agl-profile-graphical-html5 - * agl-profile-graphical-qt5 - * agl-profile-hud - * agl-profile-telematics - * agl-ptest - * agl-sota: enable SOTA components and dependencies (meta-sota, meta-filesystems, meta-ruby, meta-rust are added) -* in **meta-agl-demo** - * agl-demo: enable layer meta-agl-demo and meta-qt5 - required to build * agl-demo-platform - * agl-iotivity - * agl-sdl -* in **meta-agl-devel** - * agl-audio-4a-framework - * agl-audio-soundmanager-framework - * agl-egvirt - * agl-hmi-framework - * agl-oem-extra-libs - * agl-renesas-kernel - * agl-telemetry -* in **meta-agl-extra** - * agl-localdev: add a local layer named “meta-localdev” in meta directory and a local.dev.inc conf file if present - * blsched - -For newer features or to get more details on a given feature, take a look at the configuration files stored for each feature and/or each machine in meta-agl/templates and meta-agl-extra/templates. - -[AGL snapshots master latest]: https://download.automotivelinux.org/AGL/snapshots/master/latest/ -[yocto ref Manual]: http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#detailed-supported-distros -[Getting Started with AGL]: https://wiki.automotivelinux.org/start/getting-started -[repo info]: https://source.android.com/source/using-repo.html -- cgit 1.2.3-korg From 8751376ebaaec9aa14a49c6b2a16c5655940610b Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 16 Nov 2018 14:22:17 -0800 Subject: intel.md: Minor corrections. Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/intel.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md index 74988a1..4f2756b 100644 --- a/docs/getting-started/machines/intel.md +++ b/docs/getting-started/machines/intel.md @@ -11,7 +11,7 @@ MinnowBoard Max and Turbot as well as Joule are both 64-bit capable. If you are interested in creating ***applications*** to run on hardware booted using an image built with the AGL Project, see the following: -* [Application Development Workflow](../../../app-workflow-intro.html/overview) +* [Application Development Workflow](../app-workflow-intro.html/overview) * [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) UEFI has significantly evolved and you will likely want to check that your hardware's @@ -25,7 +25,7 @@ You do not need to make this check for the MinnowBoard-Turbo and Up platforms: ## 1. Making Sure Your Build Environment is Correct The -"[Initializing Your Build Environment](../../../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" section presented generic information for setting up your build environment using the `aglsetup.sh` script. If you are building for an Intel 64-bit platform, you need to specify some @@ -61,6 +61,7 @@ For supported Intel images, the filenames have the following form: ``` Start the build using the `bitbake` command. + **NOTE:** An initial build can take many hours depending on your CPU and and Internet connection speeds. The build also takes approximately 100G-bytes of free disk space. @@ -87,7 +88,7 @@ See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL ## 3. Creating Bootable Media -Depending your target hardware you will use an USB stick, an SD card or a HDD/SDD. +Depending on your target hardware you will use an USB stick, an SD card or a HDD/SDD. The creation process remains the same independently of the selected support. It does require to have access to a Linux machine with `sudo` or root password. -- cgit 1.2.3-korg From 18030400bc7a7874e1695307297651d59b98aa55 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 16 Nov 2018 14:22:53 -0800 Subject: Image Workflow Graphic: Updated possible build file. Replaced "QEMU" file with more generic "Emulation" type. Signed-off-by: Scott Rifenbark --- .../images/image-developer-workflow.png | Bin 48502 -> 54703 bytes 1 file changed, 0 insertions(+), 0 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/images/image-developer-workflow.png b/docs/getting-started/images/image-developer-workflow.png index daaeda0..c4f6853 100644 Binary files a/docs/getting-started/images/image-developer-workflow.png and b/docs/getting-started/images/image-developer-workflow.png differ -- cgit 1.2.3-korg From a8abe98912559160948addd62b16538259446298 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 16 Nov 2018 14:23:51 -0800 Subject: Building for Emulation: Re-write for creating build to emulate. Removed the VMWare Player option as it is unstable and flakey. Re-write for general emulation as there are really two ways to use the image: 1) QEMU or 2) VirtualBox. Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/qemu.md | 154 +++++++++++++++++++--------------- 1 file changed, 88 insertions(+), 66 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/qemu.md b/docs/getting-started/machines/qemu.md index 7bd14c0..f7e837d 100644 --- a/docs/getting-started/machines/qemu.md +++ b/docs/getting-started/machines/qemu.md @@ -1,60 +1,115 @@ -# Building the AGL Demo Platform for QEMU +# Building for Emulation -To build the QEMU version of the AGL demo platform use machine **qemux86-64** along with features **agl-demo** and **agl-devel**: +Building an image for emulation allows you to simulate your +image without actual target hardware. + +This section describes the steps you need to take to build the +AGL demo image for emulation using either Quick EMUlator (QEMU) or +VirtualBox. + +## 1. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +section presented generic information for setting up your build environment +using the `aglsetup.sh` script. +If you are building the AGL demo image for emulation, you need to specify some +specific options when you run the script: ```bash source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 agl-demo agl-devel -bitbake agl-demo-platform ``` -By default, the build will produce a compressed *vmdk* image in **tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz** +The "-m" option specifies the "qemux86-64" machine. +The list of AGL features used with script are appropriate for development of +the AGL demo image suited for either QEMU or VirtualBox. + +## 2. Using BitBake + +This section shows the `bitbake` command used to build the AGL image. +Before running BitBake to start your build, it is good to be reminded that AGL +does provide pre-built images for developers that can be emulated +using QEMU and VirtualBox. +You can find these pre-built images on the +[AGL Download web site](https://download.automotivelinux.org/AGL/release). + +For supported images, the filenames have the following forms: + +``` +//qemuarm/* +//qemuarm64/* +//qemux86-64/* +``` + +Start the build using the `bitbake` command. + +**NOTE:** An initial build can take many hours depending on your +CPU and and Internet connection speeds. +The build also takes approximately 100G-bytes of free disk space. + +For this example, the target is "agl-demo-platform": + +```bash + bitbake agl-demo-platform +``` + +By default, the build process puts the resulting image in the Build Directory: -## Deploying the AGL Demo Platform for QEMU +``` +/tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz +``` -### Prepare an image for boot +## 3. Deploying the AGL Demo Image -Decompress the **agl-demo-platform-qemux86-64.vmdk.xz** image to prepare it for boot. +Deploying the image consists of decompressing the image and then +booting it using either QEMU or VirtualBox. -#### Linux +### Decompress the image: + +For Linux, use the following commands to decompress the image and prepare it for boot: ```bash cd tmp/deploy/images/qemux86-64 xz -d agl-demo-platform-qemux86-64.vmdk.xz ``` -#### Windows +For Windows, download [7-Zip](http://www.7-zip.org/) and then +select **agl-demo-platform-qemux86-64.vmdk.xz** to decompress +the image and prepare it for boot. -Download [7-Zip](http://www.7-zip.org/) and select **agl-demo-platform-qemux86-64.vmdk.xz** to be decompressed. +### Boot the Image: -## Boot an image +The following steps show you how to boot the image with QEMU or VirtualBox. -### QEMU +#### QEMU -#### Install QEMU +Depending on your Linux distribution, use these commands to install QEMU: -**Note**: if an AGL crosssdk has been created, it will contain a qemu binary for the host system. This SDK qemu binary has no graphics support and cannot currently be used to boot an AGL image. +**NOTE:** if you have created an AGL crosssdk, it will contain a +QEMU binary for the build host. +This SDK QEMU binary does not support graphics. +Consequently, you cannot use it to boot the AGL image. -*Arch*: +If your build host is running +[Arch Linux](https://www.archlinux.org/), use the following commands: ```bash sudo pacman -S qemu ``` -*Debian/Ubuntu*: +If your build host is running Debian or Ubuntu, use the following commands: ```bash sudo apt-get install qemu-system-x86 ``` -*Fedora*: +If you build host is running Fedora, use the following commands: ```bash sudo yum install qemu-kvm ``` -#### Boot QEMU - -Boot the **agl-demo-platform-qemux86-64.vmdk** image in qemu with kvm support: +Once QEMU is installed, boot the image with KVM support: ```bash qemu-system-x86_64 -enable-kvm -m 2048 \ @@ -68,52 +123,19 @@ qemu-system-x86_64 -enable-kvm -m 2048 \ -net user,hostfwd=tcp::2222-:22 ``` -### VirtualBox - -#### Install VirtualBox - -Download and install [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 5.2.0 or later. - -#### Boot VirtualBox - -Boot the **agl-demo-platform-qemux86-64.vmdk** image in VirtualBox: - -* Start VirtualBox -* Click **New** to create a new machine - * Enter **AGL QEMU** as the *Name* - * Select **Linux** as the *Type* - * Select **Other Linux (64-bit)** as the *Version* - * Set *Memory size* to **2 GB** - * Click **Use an existing virtual hard disk file** under *Hard disk* - * Navigate to and select the **agl-demo-platform-qemux86-64.vmdk** image -* Ensure that the newly created **AGL QEMU** machine is highlighted and click **Start** - -### VMWare Player - -#### Install VMWare Player - -Download and install [VMWare Player](https://www.vmware.com/products/player/playerpro-evaluation.html) +#### VirtualBox -#### Boot VMWare Player +Start by downloading and installing [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 5.2.0 or later. -Boot the **agl-demo-platform-qemux86-64.vmdk** image in VMWare Player: +Once VirtualBox is installed, follow these steps to boot the image: -* Start VMWare Player -* Select **File** and **Create a New Virtual Machine** - * Select **I will install the operating system later** and click **Next** - * Select **Linux** as the *Guest Operating System*, **Other Linux 3.x kernel 64-bit** as the *Version*, and click **Next** - * Enter **AGL QEMU** as the *Name* and click **Next** - * Leave *disk capacity settings* unchanged and click **Next** - * Click **Finish** -* Select/highlight **AGL QEMU** and click **Edit virtual machine settings** - * Select/highlight **Memory** and click **2 GB** - * Select/highlight **Hard Disk (SCSI)** and click **Remove** - * Click **Add** - * Select **Hard Disk** and click **Next** - * Select **SCSI (Recommended)** and click **Next** - * Select **Use an existing virtual disk** and click **Next** - * Browse and select the **agl-demo-platform-qemux86-64.vmdk** image - * Click **Finish** - * Click **Keep Existing Format** - * Click **Save** -* Ensure that the newly created **AGL QEMU** machine is highlighted and click **Power On** +1. Start VirtualBox +2. Click **New** to create a new machine +3. Enter **AGL QEMU** as the *Name* +4. Select **Linux** as the *Type* +5. Select **Other Linux (64-bit)** as the *Version* +6. Set *Memory size* to **2 GB** +7. Click **Use an existing virtual hard disk file** under *Hard disk* +8. Navigate to and select the **agl-demo-platform-qemux86-64.vmdk** image +9. Ensure that the newly created **AGL QEMU** machine is highlighted. +10. Click **Start** -- cgit 1.2.3-korg From 771d8c770251f4a3e51529e6b310c617b25d37bc Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 16 Nov 2018 14:34:30 -0800 Subject: Building the AGL Image: Added link for "Emulation" Option: Signed-off-by: Scott Rifenbark --- docs/getting-started/image-workflow-build.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/image-workflow-build.md b/docs/getting-started/image-workflow-build.md index bb2056e..4ea9018 100644 --- a/docs/getting-started/image-workflow-build.md +++ b/docs/getting-started/image-workflow-build.md @@ -8,10 +8,11 @@ It is critical that you specify the correct options and configurations for the build before executing the `bitbake` command. The previous sections in the "Image Development Workflow" have treated this setup in a generic fashion. -This section, provides links to topics with instructions needed to create images for four -supported platforms: +This section, provides links to topics with instructions needed to create images for +three types of supported platforms and for emulation using Quick EMUlator (QEMU) +or VirtualBox: -* [Most Intel-based 64-Bit Boards](./machines/intel.html/overview) -* The Quick EMUlator (QEMU) +* [Most Intel-based 64-Bit Boards](./machines/intel.html/) +* [Emulation](./machines/qemu.html/) * R Car Starter Kit Gen3 Board * Raspberry PI 2 or 3 -- cgit 1.2.3-korg From 6592251c6907fac8c6fd5a25edba977cf039eaba Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Wed, 24 Oct 2018 16:55:20 +0200 Subject: book.yml: test file for getting started MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: Icff993dad2c49d46ea4038f3d9c6b1605fc4b558 Signed-off-by: Clément Bénier --- docs/getting-started-book.yml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 docs/getting-started-book.yml (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml new file mode 100644 index 0000000..61fb9c8 --- /dev/null +++ b/docs/getting-started-book.yml @@ -0,0 +1,15 @@ +type: books +books: + - id: main + - language: en + title: Getting Started + description: Getting Started Description + keywords: Start + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - name: Download AGL Source Code + url: getting-started/source-code.md + + -- cgit 1.2.3-korg From 93bac0348d6e3cda77d17ae6a937deb33ed9401f Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Wed, 7 Nov 2018 14:56:44 +0100 Subject: update book.yml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: I8e82a71d19ee7f074bdf186c70aabb763918d754 Signed-off-by: Clément Bénier --- docs/getting-started-book.yml | 71 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 66 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index 61fb9c8..dc87f10 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -1,15 +1,76 @@ type: books books: - - id: main +- + id: getting_started + languages: - language: en title: Getting Started description: Getting Started Description - keywords: Start + keywords: author: "IotBzh" website: http:docs.iot.bzh version: master chapters: - - name: Download AGL Source Code - url: getting-started/source-code.md - + - name: Download AGL source Code + url: getting-started/source-code.md + - name: Customize the AGL build + url: getting-started/customize_bitbake_conf.md + - name: Build for Intel + url: getting-started/machines/intel.md + - url: getting-started/machines/qemu.md + name: Build for Qemu + - url: getting-started/machines/R-Car-Starter-Kit-gen3.md + name: Build for R Car Starter Kit gen3 board + - url: getting-started/machines/raspberrypi.md + name: Build for Raspberry PI 2/3 + - language: fr + title: Pour commencer + description: Pour commencer description + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - name: Télécharger le code source d'AGL + url: getting-started/source-code.md + - name: Customiser le build AGL + url: getting-started/customize_bitbake_conf.md + - name: Compiler pour intel + url: getting-started/machines/intel.md + - url: getting-started/machines/qemu.md + name: Compiler pour Qemu + - url: getting-started/machines/R-Car-Starter-Kit-gen3.md + name: Compiler pour R Car Starter Kit gen3 board + - url: getting-started/machines/raspberrypi.md + name: Compiler pour Raspberry PI 2/3 +- + id: troubleshooting + languages: + - language: en + title: Troubleshooting + description: Troubleshooting Description + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: getting-started/troubleshooting.md + name: Generic issues + - url: getting-started/footers/intel-footer.md + name: Intel Boards + - url: getting-started/footers/raspberrypi-footer.md + name: Raspberry PI +- + id: sdk + languages: + - language: en + title: SDK + description: SDK Quick Setup + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: getting-started/setup-sdk-environment.md + name: SDK Quick Setup -- cgit 1.2.3-korg From b0ccdaf7d1e716df535cace9662c2d401c636964 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Sun, 11 Nov 2018 13:29:54 +0100 Subject: images: move image into footers to respect soft links MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: I82b42181e89ba7291e93fa530546210ff70e62ca Signed-off-by: Clément Bénier --- .../images/RaspberryPi2-ModelB-debug-serial-cable.jpg | Bin 0 -> 96123 bytes .../images/RaspberryPi2-ModelB-debug-serial-cable.jpg | Bin 96123 -> 0 bytes 2 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg delete mode 100644 docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg (limited to 'docs') diff --git a/docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg b/docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg new file mode 100644 index 0000000..e8026d6 Binary files /dev/null and b/docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg differ diff --git a/docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg b/docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg deleted file mode 100644 index e8026d6..0000000 Binary files a/docs/getting-started/images/RaspberryPi2-ModelB-debug-serial-cable.jpg and /dev/null differ -- cgit 1.2.3-korg From 0afb0abb20cbf75fd325aaaf819f63eb3ebd8c59 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Wed, 14 Nov 2018 14:37:29 +0100 Subject: add signaling-book.yml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit handle signaling part Change-Id: I8a39dd70d57d409c18e66e9fe570b19ce77096bb Signed-off-by: Clément Bénier --- docs/signaling-book.yml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 docs/signaling-book.yml (limited to 'docs') diff --git a/docs/signaling-book.yml b/docs/signaling-book.yml new file mode 100644 index 0000000..1ac6d5c --- /dev/null +++ b/docs/signaling-book.yml @@ -0,0 +1,15 @@ +type: books +books: +- + id: signaling + languages: + - language: en + title: Message Signaling + description: Message Signaling Description + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - name: Message Signaling + url: signaling/architecture.md -- cgit 1.2.3-korg From 6c56273ce111369cb43e53c61c118458eafb06e5 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Sun, 18 Nov 2018 16:13:52 +0100 Subject: book.yml: add order entry MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit order entry is use to order the chapter is agl documentation Change-Id: I9c4f9beb37ae0159f40bb161cfac1433ee5d1ae8 Signed-off-by: Clément Bénier --- docs/getting-started-book.yml | 3 +++ 1 file changed, 3 insertions(+) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index dc87f10..418c58b 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -2,6 +2,7 @@ type: books books: - id: getting_started + order: 10 languages: - language: en title: Getting Started @@ -45,6 +46,7 @@ books: name: Compiler pour Raspberry PI 2/3 - id: troubleshooting + order: 51 languages: - language: en title: Troubleshooting @@ -62,6 +64,7 @@ books: name: Raspberry PI - id: sdk + order: 51 languages: - language: en title: SDK -- cgit 1.2.3-korg From abc42d00c0b30fc3f28b8e35aed728be5f026e97 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 21 Nov 2018 09:25:02 -0800 Subject: R-Car Build: WIP of the steps to build for R-Car Boards Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/renesas.md | 720 +++++++++++++++++++++++++++++++ 1 file changed, 720 insertions(+) create mode 100644 docs/getting-started/machines/renesas.md (limited to 'docs') diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md new file mode 100644 index 0000000..f2e14c5 --- /dev/null +++ b/docs/getting-started/machines/renesas.md @@ -0,0 +1,720 @@ +# Building for Supported Renesas Boards + +AGL supports building for several automotive +[Renesas](https://www.renesas.com/us/en/solutions/automotive.html) board kits. +Renesas is the number one supplier of vehicle control microcontrollers and +System on a Chip (SoC) products for the automotive industry. + +This section provides the build and deploy steps you need to create an +image for the following Renesas platforms: + +* [Renesas R-Car Starter Kit Pro Board](https://www.elinux.org/R-Car/Boards/M3SK) +* [Renesas R-Car Starter Kit Premier Board](https://www.elinux.org/R-Car/Boards/H3SK) +* [Renesas Salvator-X Board](https://www.elinux.org/R-Car/Boards/Salvator-X) +* [Renesas Kingfisher Infotainment Board](https://elinux.org/R-Car/Boards/Kingfisher) + +**NOTE:** You can find similar information for the Pro and Premier board kits on the +[R-Car/Boards/Yocto-Gen3](https://elinux.org/R-Car/Boards/Yocto-Gen3) page. +The information on this page describes setup and build procedures for both these +Renesas development kits. + + +## 1. Downloading Prioprietory Drivers + +Before setting up the build environment, you need to download proprietary drivers from the +[R-Car H3/M3 Software library and Technical document](https://www.renesas.com/us/en/solutions/automotive/rcar-download/rcar-demoboard-2.html) +site. +This download site supports the Pro and Premier board starter kits. + +**NOTE:** Not sure what you do if you are using the Salvator-X or Kingfisher Infotainment boards. + +Follow these steps to download the drivers you need: + +1. **Determine the Files You Need:** + + Run the ``setup_mm_packages.sh`` script as follows to + display the list of ZIP files containing the drivers you need. + Following is an example: + + ```bash + grep -rn ZIP_.= $AGL_TOP/meta-agl/meta-agl-bsp/meta-rcar-gen3/scripts/setup_mm_packages.sh + 3:ZIP_1="R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip" + 4:ZIP_2="R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip" + ``` + + The script's output identifies the files you need to download from the page. + +2. **Find the Download Links:** + + Find the appropriate download links on the + [R-Car H3/M3 Software library and Technical document](https://www.renesas.com/us/en/solutions/automotive/rcar-download/rcar-demoboard-2.html) + site. + The file pairs are grouped according to the Yocto Project version you are + using with the AGL software. + The Flounder release of AGL uses the 2.4 version of the Yocto Project (i.e. "Rocko"). + +3. **Download the Files:** + + Start the download process by clicking the download link. + If you do not have an account with Renesas, you will be asked to register a free account. + You must register and follow the "Click Through" licensing process + in order to download these proprietary files. + + If needed, follow the instructions to create the free account by providing the required + account information. + Once the account is registered and you are logged in, you can download the files. + + **NOTE:** + You might have to re-access the + [original page](https://www.renesas.com/us/en/solutions/automotive/rcar-download/rcar-demoboard-2.html) + that contains the download links you need after creating the account and logging in. + +4. **Create an Environment Variable to Point to Your Download Area:** + + Create and export an environment variable named `XDG_DOWNLOAD_DIR` that points to + your download directory. + Here is an example: + + ```bash + $ export XDG_DOWNLOAD_DIR=$HOME/Downloads + ``` + +5. **Be Sure the Files Have Rights:** + + Be sure you have the necessary rights for the files you downloaded. + You can use the following command: + + ```bash + chmod a+4 $XDG_DOWNLOAD_DIR/*.zip + ``` + +6. **Check to be Sure the Files are Downloaded and Have the Correct Rights:** + + Do a quick listing of the files to ensure they are in the download directory and + they have the correct access rights. + Here is an example: + + ```bash + $ ls -l $XDG_DOWNLOAD_DIR/*.zip + -rw-rw-r-- 1 scottrif scottrif 4662080 Nov 19 14:48 /home/scottrif/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip + -rw-rw-r-- 1 scottrif scottrif 3137626 Nov 19 14:49 /home/scottrif/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip + ``` + +## 2. Getting More Software + +1. **Get the `bmaptool`:** + + Download this tool from the + [bmap-tools](https://build.opensuse.org/package/show/isv:LinuxAutomotive:AGL_Master/bmap-tools) + repository. + The site has pre-built packages (DEB or RPM) for the supported host + operating systems. + +2. **Get Your Board Support Package (BSP) Version:** + + Be sure to have the correct BSP version of the R-Car Starter Kit + based on the version of the AGL software you are using. + Use the following table to map the Renesas version to your AGL software: + + | AGL Version| Renesas version | + |:-:|:-:| + | AGL master | 3.9.0 | + | AGL 6.0.0 | 3.7.0 | + | AGL 5.0.x, 5.1.0| 2.23.1 | + | AGL 4.0.x |2.19.0 | + + **NOTE:** + I don't know how the user uses this information. + I need more information. + +## 3. Getting Your Hardware Together + + Gather together this list of hardware items, which is not exhaustive. + Having these items ahead of time saves you from having to try and + collect hardware during development: + + * Supported Starter Kit Gen3 board with its 5V power supply. + * Micro USB-A cable for serial console. + This cable is optional if you are using ethernet and an SSH connection. + * USB 2.0 Hub. The hub is optional but makes it easy to connect multiple USB devices. + * Ethernet cable. The cable is optional if you are using a serial console. + * HDMI type D (Micro connector) cable and an associated display. + * 4Gbyte minimum micro-SD Card. It is recommended that you use a class 10 type. + * USB touch screen device such as the GeChic 1502i/1503i. A touch screen device is optional. + + **NOTE:** The Salvator-X Board has NDA restrictions. + Consequently, less documentation is available for this board both here and across the + Internet. + + +## 4. Making Sure Your Build Environment is Correct + + The + "[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" + section presented generic information for setting up your build environment + using the `aglsetup.sh` script. + If you are building an image for a supported Renesas board, + you need to take steps to make sure your build host is set up correctly. + +1. **Define Your Board:** + + Depending on your Renesas board, define and export a `MACHINE` variable as follows: + + | Board| `MACHINE` Setting | + |:-:|:-:| + | Starter Kit Pro/M3 | `MACHINE`=m3ulcb | + | Starter Kit Premier/H3 | `MACHINE`=h3ulcb | + | Salvator-X | `MACHINE`=h3-salvator-x | + + For example, the following command defines and exports the `MACHINE` variable + for the Starter Kit Pro/M3 Board: + + ```bash + $ export MACHINE=m3ulcb + ``` + +2. **Run the `aglsetup.sh` Script:** + + Use the following commands to run the AGL Setup script: + + ```bash + $ cd $AGL_TOP + $ source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo agl-netboot agl-appfw-smack agl-localdev + ``` + + **NOTE:** + Running the `aglsetup.sh` script automatically places you in the + working directory (i.e. `$AGL_TOP/build`). + You can change this default behavior by adding the "-f" option to the + script's command line. + + In the previous command, the "-m" option sets your machine to the previously + defined `MACHINE` variable. + The "-b" option defines your Build Directory, which is the + default `$AGL_TOP/build`. + Finally, the AGL features are provided to support building the AGL Demo image + for the Renesas board. + + You can learn more about the AGL Features in the + "[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html)" + section. + +3. **Examine the Script's Log:** + + Read the script's log to be sure no errors occurred during your setup. + For example, suppose the graphics drivers were missing or could not be extracted. + In case of missing graphics drivers, you could notice an error message + similar to the following: + + ```bash + [snip] + --- fragment /home/working/workspace_agl_master/meta-agl/templates/machine/h3ulcb/50_setup.sh + /home/working/workspace_agl_master /home/working/workspace_agl_master/build_gen3 + The graphics and multimedia acceleration packages for + the R-Car Gen3 board can be downloaded from: + https://www.renesas.com/en-us/solutions/automotive/rcar-demoboard-2.html + + These 2 files from there should be store in your'/home/devel/Downloads' directory. + R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip + R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip + /home/working/workspace_agl_master/build_gen3 + --- fragment /home/working/workspace_agl_master/meta-agl/templates/base/99_setup_EULAconf.sh + --- end of setup script + OK + Generating setup file: /home/working/workspace_agl_master/build_gen3/agl-init-build-env ... OK + ------------ aglsetup.sh: Done + [snip] + ``` + + If you encounter this issue, or any other unwanted behavior, you can fix the error + mentioned, remove the `$AGL_TOP/build` directory, and then re-launch the + `aglsetup.sh` again. + + You can find out more about any error by examining the `setup.log` file, which is in + the `build/conf` folder. + Here is an example that indicates the driver files could not be extracted from + the downloads directory: + + ```bash + [snip] + + ~/workspace_agl/build/conf $ cat setup.log + --- beginning of setup script + --- fragment /home/thierry/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh + --- fragment /home/thierry/workspace_agl/meta-agl/templates/machine/m3ulcb/50_setup.sh + ~/workspace_agl ~/workspace_agl/build + ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip+" NOT EXTRACTING CORRECTLY + ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip+" NOT EXTRACTING CORRECTLY + The graphics and multimedia acceleration packages for + the R-Car Gen3 board BSP can be downloaded from: + + + These 2 files from there should be stored in your + '/home/thierry/Downloads' directory. + R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip + R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip + ERROR: Script /home/thierry/workspace_agl/build/conf/setup.sh failed + [snip] + ``` + +## 5. Checking Your Configuration + +Users may want to check that the board is correctly selected in the environment: + +```bash +grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf + MACHINE = "h3ulcb" +or + MACHINE = "m3ulcb" +or + MACHINE = "h3-salvator-x" +``` + +Configure for Release or Development: + +* development images contain extra tools for developer convenience, in particular: + * a debugger (gdb) + * some tweaks, including a disabled root password + * a SFTP server + * the TCF Agent for easier application deployment and remote debugging + * some extra system tools (usb, bluetooth ...) + * ... + +We explicitely activate these debug facilities by specifying the “agl-devel agl-netboot” feature. + +## Building the AGL Demo Platform for R-Car Starter Kit Gen3 + +### Build your image + +The process to build an image is simple: + +```bash +bitbake agl-demo-platform +``` + +You may need to install rpcgen to run this command. + +When finished (it may take few hours), you should get the final result: + +```bash +ls -l $AGL_TOP/build/tmp/deploy/images/$MACHINE +``` + +**Note**: + +In case of failure of the build it is safe to first check that the Linux distribution chosen for your host has been validated for the current version of Yocto used by AGL. + +## Booting AGL Image on R-Car Starter Kit Gen3 boards using a microSD card + +To boot the board using a micro-SD card, there are two operations that must be done prior to first initial boot: + +* Update all firmware on the device. +* Set up the board to boot on the SD-card. + +For each subsequent build you only need to rewrite the SD-card with the new image. + +### Firmware Update + +This proceedure is done in two steps. The 'Sample Loader and MiniMonitor update' step only needs to be done once per device. The 'Firmware stack update' step is mandatory only if you use AGl Eel (version 5.0) or later. + +#### Sample Loader and MiniMonitor update + +Follow the documentation on the [eLinux.org wiki][R-car loader update] to update to at least version 3.02. This is mandatory to run AGL. + +#### Firmware stack update + +As an AArch64 platform, both **h3ulcb** and **m3ulcb** have a firmware stack divided in : **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. + +If you use AGl Eel (version 5.0) or later, you must update the firmware using the following links to eLinux.org wiki: **[h3ulcb][R-car h3ulcb firmware update]** or **[m3ulcb][R-car m3ulcb firmware update]**. + +The files listed in the eLinux.org wiki table will be found in the directory: + +```bash +*\$AGL_TOP/build/tmp/deploy/images/$MACHINE* +``` + +The Salvator-X firmware update process is not documented on eLinux. + +### Prepare the SD-card on the host + +Plug the microSD card and get its associated device by either running *`dmesg | tail -15`* or *`lsblk`*, for example: + +```bash +dmesg | tail -15 + + [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 + [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found + [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through + [ 1971.463870] sdc: sdc1 sdc2 +``` + +Here, the SD-card is attached to the device /dev/sdc. + +```bash +lsblk + + NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT + sda 8:0 0 167,7G 0 disk + ├─sda1 8:1 0 512M 0 part /boot/efi + ├─sda2 8:2 0 159,3G 0 part / + └─sda3 8:3 0 7,9G 0 part [SWAP] + sdb 8:16 0 931,5G 0 disk + └─sdb1 8:17 0 931,5G 0 part /media/storage + sdc 8:32 1 14,9G 0 disk + ├─sdc1 8:33 1 40M 0 part + └─sdc2 8:34 1 788M 0 part +``` + +**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time: +so you should repeat this operation each time you insert the microSD card to confirm the device name. + +In the example above, we see: + +* the first SATA drive as 'sda'. +* 'sdc' corresponds to the microSD card, and is also marked as removable device by *lsblk* which is a good confirmation. +* Your desktop system probably offers a choice to mount the SD-card automatically in some directory. +* In the next sample code, we'll suppose that the SD-card mount directory is stored in the variable $SDCARD. +* For example, if the microSD card is associated with device *sdc*: + +Go to your build directory: + +```bash +cd $AGL_TOP/build/tmp/deploy/images/$MACHINE +``` + +You can use bmaptool to copy the **.wic.xz** file to the storage device, discovered in the previous step: + +```bash +bmaptool copy ./agl-demo-platform-$MACHINE.wic.xz $SDCARD +``` + +Or you can be uncompressed and written to the device: + +```bash + sudo umount /dev/sdc + xzcat ./agl-demo-platform-$MACHINE.wic.xz | sudo dd of=$SDCARD bs=4M + sync +``` + +### Booting the board + +* Turn the board off using the power switch. +* Insert the microSD-card. +* Verify that you have plugged in, at least : + * An external monitor on HDMI port + * An input device (keyboard, mouse, touchscreen...) on USB port. + +* Turn the board on using the power switch. + After a few seconds, you'll see the AGL splash screen on the display and you'll be able to log in on the console terminal or in the graphic screen. + +## Serial Console Setup + +### Install a serial client on your computer + +This can be “screen”, “picocom”, “minicom”. +The lighter of the 3 is “picocom” (it has less dependencies). + +### Plug a USB cable from your computer to the serial CP2102 USB port (micro USB-A) + +With “dmesg” you can check the device created for the serial link. +Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host. +To get it, you must switch the board on. +For example: + +```bash +dmesg | tail +[2097783.287091] usb 2-1.5.3: new full-speed USB device number 24 using ehci-pci +[2097783.385857] usb 2-1.5.3: New USB device found, idVendor=0403, idProduct=6001 +[2097783.385862] usb 2-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[2097783.385864] usb 2-1.5.3: Product: FT232R USB UART +[2097783.385866] usb 2-1.5.3: Manufacturer: FTDI +[2097783.385867] usb 2-1.5.3: SerialNumber: AK04WWCE +[2097783.388288] ftdi_sio 2-1.5.3:1.0: FTDI USB Serial Device converter detected +[2097783.388330] usb 2-1.5.3: Detected FT232RL +[2097783.388658] usb 2-1.5.3: FTDI USB Serial Device converter now attached to ttyUSB0 +``` + +The link is attached to the device /dev/ttyUSB0. +It is time to launch your serial client. +Example: + +```bash +picocom -b 115200 /dev/ttyUSB0 +``` + +or + +```bash +minicom -b 115200 -D /dev/ttyUSB0 +``` + +or + +```bash +screen /dev/ttyUSB0 115200 +``` + +### Power on the board to see a shell on the console + +* For machine h3ulcb: + +```bash +NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 +NOTICE: BL2: PRR is R-Car H3 ES1.1 +NOTICE: BL2: LCM state is CM +NOTICE: BL2: DDR1600(rev.0.15) +NOTICE: BL2: DRAM Split is 4ch +NOTICE: BL2: QoS is Gfx Oriented(rev.0.30) +NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 +NOTICE: BL2: Lossy Decomp areas +NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 +NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 +NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 +NOTICE: BL2: v1.1(release):41099f4 +NOTICE: BL2: Built : 19:20:52, Jun 9 2016 +NOTICE: BL2: Normal boot +NOTICE: BL2: dst=0xe63150c8 src=0x8180000 len=36(0x24) +NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=3072(0xc00) +NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) +NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) +NOTICE: BL2: dst=0x49000000 src=0x8640000 len=1048576(0x100000) + + +U-Boot 2015.04 (Jun 09 2016 - 19:21:52) + +CPU: Renesas Electronics R8A7795 rev 1.1 +Board: H3ULCB +I2C: ready +DRAM: 3.9 GiB +MMC: sh-sdhi: 0, sh-sdhi: 1 +In: serial +Out: serial +Err: serial +Net: Board Net Initialization Failed +No ethernet found. +Hit any key to stop autoboot: 0 +=> +``` + +* For machine m3ulcb: + +``` +NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 +NOTICE: BL2: PRR is R-Car M3 Ver1.0 +NOTICE: BL2: Board is Starter Kit Rev1.0 +NOTICE: BL2: Boot device is HyperFlash(80MHz) +NOTICE: BL2: LCM state is CM +NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 +NOTICE: BL2: DDR1600(rev.0.22)NOTICE: [COLD_BOOT]NOTICE: ..0 +NOTICE: BL2: DRAM Split is 2ch +NOTICE: BL2: QoS is default setting(rev.0.17) +NOTICE: BL2: Lossy Decomp areas +NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 +NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 +NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 +NOTICE: BL2: v1.3(release):4eef9a2 +NOTICE: BL2: Built : 00:25:19, Aug 25 2017 +NOTICE: BL2: Normal boot +NOTICE: BL2: dst=0xe631e188 src=0x8180000 len=512(0x200) +NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) +NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) +NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) +NOTICE: BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000) + + +U-Boot 2015.04-dirty (Aug 25 2017 - 10:55:49) + +CPU: Renesas Electronics R8A7796 rev 1.0 +Board: M3ULCB +I2C: ready +DRAM: 1.9 GiB +MMC: sh-sdhi: 0, sh-sdhi: 1 +In: serial +Out: serial +Err: serial +Net: ravb +Hit any key to stop autoboot: 0 +=> +``` + +### Configure U-boot parameters + +Follow the steps below to configure the boot from microSD card and to set screen resolution: + +* Turn the board on using the power switch. +* Hit any key to stop autoboot (warning you have only few seconds). +* Type **printenv** to check if you have correct parameters for booting your board: + * Example for a h3ulcb: + + ``` + => printenv + baudrate=115200 + bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 + bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 + bootdelay=3 + fdt_high=0xffffffffffffffff + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb + load_ker=ext4load mmc 0:1 0x48080000 /boot/Image + stderr=serial + stdin=serial + stdout=serial + ver=U-Boot 2015.04 (Jun 09 2016 - 19:21:52) + + Environment size: 648/131068 bytes + ``` + + * Example for a m3ulcb: + + ``` + => printenv + baudrate=115200 + bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 + bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 + bootdelay=3 + fdt_high=0xffffffffffffffff + filesize=cdeb + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb + load_ker=ext4load mmc 0:1 0x48080000 /boot/Image + stderr=serial + stdin=serial + stdout=serial + ver=U-Boot 2015.04 (Nov 30 2016 - 18:25:18) + + Environment size: 557/131068 bytes + ``` + + * To boot on a sd card, it is recommended to set your environment using these commands : + + ``` + setenv bootargs console=ttySC0,115200 ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2 + setenv bootcmd run load_ker\; run load_dtb\; booti 0x48080000 - 0x48000000 + setenv load_ker ext4load mmc 0:1 0x48080000 /boot/Image + ``` + + * For machine h3ulcb (BSP >= 2.19): + + ``` + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb.dtb + ``` + + * For machine h3ulcb (BSP < 2.19): + + ``` + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb + ``` + + * For machine m3ulcb: + + ```bash + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb + ``` + + * For machine m3ulcb with a kingfisher board: + + ```bash + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb-kf.dtb + ``` + + * For machine h3ulcb with a kingfisher board: + + ```bash + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb-kf.dtb + ``` + + * Finally save boot environment: + + ```bash + saveenv + ``` + +* Now you can boot: + +``` +run bootcmd +``` + +### Console boot + +After booting, you should see the wayland display on the external monitor and a login prompt on the console, such as: + +* For machine h3ulcb: + +```bash +Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 + +h3ulcb login: root +``` + +* For machine m3ulcb: + +```bash +Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0 + +m3ulcb login: root +``` + +Logging in on the console is easy: + +* login is 'root' +* password is empty (not asked) + +### Network access + +If the board is connected to a local network using ethernet and if a DHCP server is able to distribute IP addresses, +you can then determine the Gen3 board IP address and log in using ssh: + +```bash +m3ulcb login: root +Last login: Tue Dec 6 09:55:15 UTC 2016 on tty2 +root@m3ulcb:~# ip -4 a +1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever +3: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 + inet 10.0.0.27/24 brd 10.0.0.255 scope global eth0 + valid_lft forever preferred_lft forever +root@m3ulcb:~# +``` + +Here, IP address is 10.0.0.27. Logging in using SSH is easy: + +```bash +$ ssh root@10.0.0.27 +Last login: Tue Dec 6 10:01:11 2016 from 10.0.0.13 +root@m3ulcb:~# cat /etc/os-release +ID="poky-agl" +NAME="Automotive Grade Linux" +VERSION="3.0.0+snapshot-20161202 (chinook)" +VERSION_ID="3.0.0-snapshot-20161202" +PRETTY_NAME="Automotive Grade Linux 3.0.0+snapshot-20161202 (chinook)" +``` + +## More Documentation + +Detailed guides on how to build AGL for Renesas boards and using AGL SDK inside a ready-to-use Docker container: + +* [AGL-Devkit-Build-your-1st-AGL-Application.pdf][Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application] + Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. +* [AGL-Devkit-HowTo_bake_a_service.pdf][Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service] + Generic guide on how to add a new service in the BSP. +* [AGL-Kickstart-on-Renesas-Porter-Board.pdf][Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board] +* [AGL-Devkit-Image-and-SDK-for-Porter.pdf][Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter] +* [AGL Developer Website](http://docs.automotivelinux.org) + +[R-car m3ulcb]: http://elinux.org/R-Car/Boards/M3SK +[R-car m3ulcb firmware update]: https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware +[R-car h3ulcb]: http://elinux.org/R-Car/Boards/H3SK +[R-car h3ulcb firmware update]: https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware +[R-car salvator-x]: https://elinux.org/R-Car/Boards/Salvator-X +[R-car loader update]: http://elinux.org/R-Car/Boards/Kingfisher#How_to_update_of_Sample_Loader_and_MiniMonitor +[R-car Kingfisher]: https://elinux.org/R-Car/Boards/Kingfisher +[R-car yocto]: http://elinux.org/R-Car/Boards/Yocto-Gen3 +[rcar Linux Drivers]: https://www.renesas.com/solutions/automotive/rcar-download/rcar-demoboard.html +[rcar Linux Drivers 2]: https://www.renesas.com/en-us/solutions/automotive/rcar-download/rcar-demoboard-2.html +[Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf +[Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf +[Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf +[Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf + -- cgit 1.2.3-korg From ad29664f02af5996242623efd7dc95f689e4bdd1 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Wed, 21 Nov 2018 22:18:58 +0100 Subject: getting-started-book: new yaml book MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: Iac9ed9e7c3e5db15024a19180d7ed5aa3cc119ba Signed-off-by: Clément Bénier --- docs/getting-started-book.yml | 78 ++++++++++++++++++++++++++----------------- 1 file changed, 48 insertions(+), 30 deletions(-) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index 418c58b..5fef636 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -1,49 +1,37 @@ type: books books: - - id: getting_started + id: image-development-workflow order: 10 languages: - language: en - title: Getting Started - description: Getting Started Description + title: Image Development Workflow + description: keywords: author: "IotBzh" website: http:docs.iot.bzh version: master chapters: - - name: Download AGL source Code - url: getting-started/source-code.md - - name: Customize the AGL build - url: getting-started/customize_bitbake_conf.md - - name: Build for Intel - url: getting-started/machines/intel.md + - url: getting-started/app-workflow-intro.md + name: Overview + - url: getting-started/image-workflow-prep-host.md + name: Preparing Your Build Host + - url: getting-started/image-workflow-download-sw.md + name: Downloading AGL Software + - url: getting-started/image-workflow-initialize-build-environment.md + name: Initializing Your Build Environment + - url: getting-started/image-workflow-cust-build.md + name: Customizing Your Build + - url: getting-started/image-workflow-build.md + name: Building the AGL Image + - url: getting-started/machines/intel.md + name: Building for Most Intel 64-Bit Hardware Platforms - url: getting-started/machines/qemu.md - name: Build for Qemu + name: Building for Emulation - url: getting-started/machines/R-Car-Starter-Kit-gen3.md name: Build for R Car Starter Kit gen3 board - url: getting-started/machines/raspberrypi.md name: Build for Raspberry PI 2/3 - - language: fr - title: Pour commencer - description: Pour commencer description - keywords: - author: "IotBzh" - website: http:docs.iot.bzh - version: master - chapters: - - name: Télécharger le code source d'AGL - url: getting-started/source-code.md - - name: Customiser le build AGL - url: getting-started/customize_bitbake_conf.md - - name: Compiler pour intel - url: getting-started/machines/intel.md - - url: getting-started/machines/qemu.md - name: Compiler pour Qemu - - url: getting-started/machines/R-Car-Starter-Kit-gen3.md - name: Compiler pour R Car Starter Kit gen3 board - - url: getting-started/machines/raspberrypi.md - name: Compiler pour Raspberry PI 2/3 - id: troubleshooting order: 51 @@ -76,4 +64,34 @@ books: chapters: - url: getting-started/setup-sdk-environment.md name: SDK Quick Setup +- + id: app-development-workflow + order: 60 + languages: + - language: en + title: Application Development Workflow + description: + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: getting-started/image-workflow-intro.md + name: Overview + - url: getting-started/app-workflow-image.md + name: Download or Build Your Image + - url: getting-started/app-workflow-sdk.md + name: Download or Build Your SDK Installer + - url: getting-started/app-workflow-bootables.md + name: Create Bootable Media + - url: getting-started/app-workflow-boot.md + name: Boot the Image on the Board + - url: getting-started/app-workflow-prep-app.md + name: Get Ready to Create Your Application + - url: getting-started/app-workflow-build-app.md + name: Create and Build the Application + - url: getting-started/app-workflow-deploy-app.md + name: Deploy the Application to the Board + - url: getting-started/app-workflow-debug-app.md + name: Debug the Application -- cgit 1.2.3-korg From 91cb74fb3fe3143ada1de961ec1964930c3ece9e Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 21 Nov 2018 13:45:32 -0800 Subject: Getting Started: Fixed a bunch of links to various sections. Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-boot.md | 8 +++---- docs/getting-started/app-workflow-bootables.md | 11 ++++++--- docs/getting-started/app-workflow-debug-app.md | 4 ++-- docs/getting-started/app-workflow-image.md | 14 +++++------ docs/getting-started/machines/raspberrypi.md | 2 +- docs/getting-started/machines/renesas.md | 33 +++++++++++++++++++++----- 6 files changed, 48 insertions(+), 24 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-boot.md b/docs/getting-started/app-workflow-boot.md index 2000518..c893d6b 100644 --- a/docs/getting-started/app-workflow-boot.md +++ b/docs/getting-started/app-workflow-boot.md @@ -6,17 +6,17 @@ 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)" + "[Booting the Image on the Target Device](./machines/intel.html#4-booting-the-image-on-the-target-device)" section. 2. **QEMU:** See the - "[Boot an image](./machines/qemu.html#boot-an-image)" + "[Deploying the AGL Demo Image](./machines/qemu.html#3-deploying-the-agl-demo-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)" + "[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 AGL Demo Platform on Raspberry Pi](./machines/raspberrypi.html#booting-agl-demo-platform-on-raspberry-pi)" + "[Booting the Image on Raspberry Pi](./machines/raspberrypi.html#2-booting-the-image-on-raspberry-pi)" section. diff --git a/docs/getting-started/app-workflow-bootables.md b/docs/getting-started/app-workflow-bootables.md index 4e6211a..508ff7a 100644 --- a/docs/getting-started/app-workflow-bootables.md +++ b/docs/getting-started/app-workflow-bootables.md @@ -6,12 +6,17 @@ 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. + +You can detailed steps for creating bootable images for several types of images +in the following sections: + +* "[Create a bootable media](./machines/intel.html#3-creating-bootable-media)" for most Intel boards +* "[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 2 and 3 boards diff --git a/docs/getting-started/app-workflow-debug-app.md b/docs/getting-started/app-workflow-debug-app.md index 91ef905..c0899de 100644 --- a/docs/getting-started/app-workflow-debug-app.md +++ b/docs/getting-started/app-workflow-debug-app.md @@ -25,7 +25,7 @@ Here are three methods: * 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`](../../../../../docs/getting_started/en/dev/reference/source-code.html#features-supported-by-aglsetup)" + "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment)" section. **NOTE:** Core Dumps are available only with the "Flunky Flounder" release (i.e. 6.x). @@ -43,5 +43,5 @@ Here are three methods: 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](../../../../../docs/getting_started/en/dev/reference/source-code.html#set-up-build-environment-info)" + "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment)" section. diff --git a/docs/getting-started/app-workflow-image.md b/docs/getting-started/app-workflow-image.md index 960f4f0..e64fd5f 100644 --- a/docs/getting-started/app-workflow-image.md +++ b/docs/getting-started/app-workflow-image.md @@ -77,7 +77,7 @@ 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)" + The "[Preparing Your Build Host](./image-workflow-prep-host.html)" section describes in detail how to make sure your system meets these requirements. @@ -96,7 +96,7 @@ The following procedure describes how to build your image: * 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)" + "[Preparing Your Build Host](./image-workflow-prep-host.html)" section for the packages you need to install for your specific distribution. @@ -113,7 +113,7 @@ The following procedure describes how to build your image: 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)" + "[Download AGL source code](./image-workflow-download-sw.html)" section. 3. **Initialize the build environment:** The build process assumes many environment @@ -127,10 +127,8 @@ The following procedure describes how to build your image: 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. + "[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 @@ -140,7 +138,7 @@ The following procedure describes how to build your image: 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)" + "[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 diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md index e016584..f963e0b 100644 --- a/docs/getting-started/machines/raspberrypi.md +++ b/docs/getting-started/machines/raspberrypi.md @@ -18,7 +18,7 @@ source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-app bitbake agl-demo-platform ``` -## Booting AGL Demo Platform on Raspberry Pi +## 2. Booting the Image on Raspberry Pi Follow the steps below to copy the image to microSD card and to boot it on Raspberry Pi 2 or 3: diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index f2e14c5..e8d9825 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -201,8 +201,11 @@ Follow these steps to download the drivers you need: 3. **Examine the Script's Log:** - Read the script's log to be sure no errors occurred during your setup. - For example, suppose the graphics drivers were missing or could not be extracted. + Running the `aglsetup.sh` script creates the `setup.log` file, which is in + the `build/conf` folder. + You can examine this log to see the results of the script. + For example, suppose the graphics drivers were missing or could not be extracted + when you ran the script. In case of missing graphics drivers, you could notice an error message similar to the following: @@ -230,9 +233,7 @@ Follow these steps to download the drivers you need: mentioned, remove the `$AGL_TOP/build` directory, and then re-launch the `aglsetup.sh` again. - You can find out more about any error by examining the `setup.log` file, which is in - the `build/conf` folder. - Here is an example that indicates the driver files could not be extracted from + Here is another example that indicates the driver files could not be extracted from the downloads directory: ```bash @@ -259,6 +260,26 @@ Follow these steps to download the drivers you need: ## 5. Checking Your Configuration + +4. **Customize your build configuration:** Aside from environment variables + and parameters you establish through running the `aglsetup.sh` script, + you can ensure your build's configuration is just how you want it by + examining the `local.conf` configuration file. + In general, the defaults along with the configuration fragments the + `aglsetup.sh` script applies 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/). + + + + + Users may want to check that the board is correctly selected in the environment: ```bash @@ -304,7 +325,7 @@ ls -l $AGL_TOP/build/tmp/deploy/images/$MACHINE In case of failure of the build it is safe to first check that the Linux distribution chosen for your host has been validated for the current version of Yocto used by AGL. -## Booting AGL Image on R-Car Starter Kit Gen3 boards using a microSD card +## 7. Booting the Image Using a MicroSD Card To boot the board using a micro-SD card, there are two operations that must be done prior to first initial boot: -- cgit 1.2.3-korg From a845733ac47f460df361ce18251126704c7f4fbf Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 23 Nov 2018 11:35:27 -0800 Subject: renesas builds: Created new file to document building for renesas Renamed this file "renesas.md" and completely went through the file. Signed-off-by: Scott Rifenbark --- .../machines/R-Car-Starter-Kit-gen3.md | 633 --------------------- docs/getting-started/machines/renesas.md | 490 +++++++++------- 2 files changed, 292 insertions(+), 831 deletions(-) delete mode 100644 docs/getting-started/machines/R-Car-Starter-Kit-gen3.md (limited to 'docs') diff --git a/docs/getting-started/machines/R-Car-Starter-Kit-gen3.md b/docs/getting-started/machines/R-Car-Starter-Kit-gen3.md deleted file mode 100644 index 68a3798..0000000 --- a/docs/getting-started/machines/R-Car-Starter-Kit-gen3.md +++ /dev/null @@ -1,633 +0,0 @@ -# AGL Kickstart on Renesas R-Car Starter Kit Gen3 (h3ulcb, m3ulcb, salvator-x(optional)) - -## Prerequisites - -* At this step, you are assumed to have downloaded the [AGL source code](/docs/getting_started/en/dev/reference/source-code.html). - -See the related paragraph if not done yet. - -* For creating the microSD card, you will need **bmaptool** - -There are pre-built packages (.deb or .rpm) for the supported host OSes, available at [this location]( -https://build.opensuse.org/package/show/isv:LinuxAutomotive:AGL_Master/bmap-tools) - -## Hardware - -Here is a non exhaustive list of hardware parts that could be used to setup the R-Car Starter Kit Gen3 board development environment: - -* Starter Kit Gen3 board with its 5V power supply -* micro USB-A cable for serial console (optional if using ethernet and ssh connection) -* USB 2.0 Hub (optional) -* Ethernet cable (optional if using serial console) -* HDMI type D (Micro connector) cable and associated display -* micro-SD Card (at least 4GB) and recommend to use class 10 type. -* USB touch screen device like the GeChic 1502i/1503i (optional) - -For more information and latest news, please check : - -* [elinux page for h3ulcb][R-car h3ulcb] -* [elinux page for m3ulcb][R-car m3ulcb] -* [elinux page for salvator-x][R-car salvator-x] - -Infotainment Carrier Board : - -* [elinux page for Kingfisher][R-car Kingfisher] - -**Note**:That the Salvator-X has NDA restrictions, so less documentation is available both here and elsewhere. - -The following documents may also be helpful: - -* [Yocto-Gen3 on elinux][R-car yocto] - -## BSP Version of R-Car Starter Kit Gen3 - -| AGL Version| Renesas version | -|:-:|:-:| -| AGL master | 3.9.0 | -| AGL 6.0.0 | 3.7.0 | -| AGL 5.0.x, 5.1.0| 2.23.1 | -| AGL 4.0.x |2.19.0 | - -## Building the AGL Demo Platform for R-Car Starter Kit Gen3 - -Before setting up the build environment, you need to download the proprietary drivers. - -* The version of the drivers you need can be displayed this way: - -```bash -grep -rn ZIP_.= $AGL_TOP/meta-agl/meta-agl-bsp/meta-rcar-gen3/scripts/setup_mm_packages.sh -``` - -* Download Renesas graphics drivers with a "click through" license from [Renesas website][rcar Linux Drivers 2] - * Under the Target hardware: **R-Car H3/M3** section. - -**Note**: - -* You have to register with a free account on MyRenesas and accept the license conditions before downloading the drivers. - The operation is fast and simple nevertheless mandatory to access evaluation of non open-source drivers for free. - Once you registered, you can download two zip files. -* It is recommended to store these drivers into your download directory (usually $HOME/Downloads, pointed by $XDG_DOWNLOAD_DIR in some OS). - * To avoid any errors, check that $XDG_DOWNLOAD_DIR is set to the directory where the drivers are stored, if not, set it using 'export' command -* Be sure to have the need rights for these files using : - -```bash -chmod a+r $XDG_DOWNLOAD_DIR/*.zip -``` - -* Check that the needed drivers files are found using : - -```bash -ls -1 $XDG_DOWNLOAD_DIR -[master] --rw-r--r--. 1 1664 agl-sdk 5.0M Jun 28 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180627.zip --rw-r--r--. 1 1664 agl-sdk 3,1M Jun 28 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180627.zip - -[Flounder] --rw-r--r--. 1 1664 agl-sdk 4.9M Apr 24 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip --rw-r--r--. 1 1664 agl-sdk 3,0M Apr 24 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip - -[Eel] --rw-r--r--. 1 1664 agl-sdk 4.5M Dec 8 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip --rw-r--r--. 1 1664 agl-sdk 3,0M Dec 8 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip -``` - -### Setting up the build environment - -Define the type of R-Car Starter Kit board as a variable: - -* for machine **h3ulcb** (Starter Kit Premier/H3) : - -```bash -export MACHINE=h3ulcb -``` - -* for machine **m3ulcb** (Starter Kit Pro/M3): - -```bash -export MACHINE=m3ulcb -``` - -* for machine **h3-salvator-x**: - -```bash -export MACHINE=h3-salvator-x -``` - -Now, init your build environment: - -```bash -cd $AGL_TOP -source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo agl-netboot agl-appfw-smack agl-localdev -``` - -**IMPORTANT NOTE**: Read the log to be sure you had no error during your setup. - -In case of missing graphics drivers, you could notice an error message as follow: - -```bash -[snip] ---- fragment /home/working/workspace_agl_master/meta-agl/templates/machine/h3ulcb/50_setup.sh -/home/working/workspace_agl_master /home/working/workspace_agl_master/build_gen3 -The graphics and multimedia acceleration packages for -the R-Car Gen3 board can be downloaded from: - https://www.renesas.com/en-us/solutions/automotive/rcar-demoboard-2.html - -These 2 files from there should be store in your'/home/devel/Downloads' directory. - R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston2-20170904.zip - R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip -/home/working/workspace_agl_master/build_gen3 ---- fragment /home/working/workspace_agl_master/meta-agl/templates/base/99_setup_EULAconf.sh ---- end of setup script -OK -Generating setup file: /home/working/workspace_agl_master/build_gen3/agl-init-build-env ... OK ------------- aglsetup.sh: Done -[snip] -``` - -If you encounter this issue, or any other unwanted behavior, you can fix the error mentioned and then clean up by removing the “$AGL_TOP/build” directory then re-launch the procedure again. - -In any case, you can find out more information for the reason of the error in this file: - -```bash -[snip] - -~/workspace_agl/build/conf $ cat setup.log ---- beginning of setup script ---- fragment /home/thierry/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh ---- fragment /home/thierry/workspace_agl/meta-agl/templates/machine/m3ulcb/50_setup.sh -~/workspace_agl ~/workspace_agl/build -ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip+" NOT EXTRACTING CORRECTLY -ERROR: FILES "+/home/thierry/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip+" NOT EXTRACTING CORRECTLY -The graphics and multimedia acceleration packages for -the R-Car Gen3 board BSP can be downloaded from: - - -These 2 files from there should be stored in your -'/home/thierry/Downloads' directory. - R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20180423.zip - R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20180423.zip -ERROR: Script /home/thierry/workspace_agl/build/conf/setup.sh failed -[snip] -``` - -After this command, the working directory is changed to $AGL_TOP/build. - -If you do not want do this, another option is to add the '**-f**' option to agl_setup.sh. - -Users may want to check that the board is correctly selected in the environment: - -```bash -grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf - MACHINE = "h3ulcb" -or - MACHINE = "m3ulcb" -or - MACHINE = "h3-salvator-x" -``` - -Configure for Release or Development: - -* development images contain extra tools for developer convenience, in particular: - * a debugger (gdb) - * some tweaks, including a disabled root password - * a SFTP server - * the TCF Agent for easier application deployment and remote debugging - * some extra system tools (usb, bluetooth ...) - * ... - -We explicitely activate these debug facilities by specifying the “agl-devel agl-netboot” feature. - -### Build your image - -The process to build an image is simple: - -```bash -bitbake agl-demo-platform -``` - -You may need to install rpcgen to run this command. - -When finished (it may take few hours), you should get the final result: - -```bash -ls -l $AGL_TOP/build/tmp/deploy/images/$MACHINE -``` - -**Note**: - -In case of failure of the build it is safe to first check that the Linux distribution chosen for your host has been validated for the current version of Yocto used by AGL. - -## Booting AGL Image on R-Car Starter Kit Gen3 boards using a microSD card - -To boot the board using a micro-SD card, there are two operations that must be done prior to first initial boot: - -* Update all firmware on the device. -* Set up the board to boot on the SD-card. - -For each subsequent build you only need to rewrite the SD-card with the new image. - -### Firmware Update - -This proceedure is done in two steps. The 'Sample Loader and MiniMonitor update' step only needs to be done once per device. The 'Firmware stack update' step is mandatory only if you use AGl Eel (version 5.0) or later. - -#### Sample Loader and MiniMonitor update - -Follow the documentation on the [eLinux.org wiki][R-car loader update] to update to at least version 3.02. This is mandatory to run AGL. - -#### Firmware stack update - -As an AArch64 platform, both **h3ulcb** and **m3ulcb** have a firmware stack divided in : **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. - -If you use AGl Eel (version 5.0) or later, you must update the firmware using the following links to eLinux.org wiki: **[h3ulcb][R-car h3ulcb firmware update]** or **[m3ulcb][R-car m3ulcb firmware update]**. - -The files listed in the eLinux.org wiki table will be found in the directory: - -```bash -*\$AGL_TOP/build/tmp/deploy/images/$MACHINE* -``` - -The Salvator-X firmware update process is not documented on eLinux. - -### Prepare the SD-card on the host - -Plug the microSD card and get its associated device by either running *`dmesg | tail -15`* or *`lsblk`*, for example: - -```bash -dmesg | tail -15 - - [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 - [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found - [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through - [ 1971.463870] sdc: sdc1 sdc2 -``` - -Here, the SD-card is attached to the device /dev/sdc. - -```bash -lsblk - - NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT - sda 8:0 0 167,7G 0 disk - ├─sda1 8:1 0 512M 0 part /boot/efi - ├─sda2 8:2 0 159,3G 0 part / - └─sda3 8:3 0 7,9G 0 part [SWAP] - sdb 8:16 0 931,5G 0 disk - └─sdb1 8:17 0 931,5G 0 part /media/storage - sdc 8:32 1 14,9G 0 disk - ├─sdc1 8:33 1 40M 0 part - └─sdc2 8:34 1 788M 0 part -``` - -**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time: -so you should repeat this operation each time you insert the microSD card to confirm the device name. - -In the example above, we see: - -* the first SATA drive as 'sda'. -* 'sdc' corresponds to the microSD card, and is also marked as removable device by *lsblk* which is a good confirmation. -* Your desktop system probably offers a choice to mount the SD-card automatically in some directory. -* In the next sample code, we'll suppose that the SD-card mount directory is stored in the variable $SDCARD. -* For example, if the microSD card is associated with device *sdc*: - -Go to your build directory: - -```bash -cd $AGL_TOP/build/tmp/deploy/images/$MACHINE -``` - -You can use bmaptool to copy the **.wic.xz** file to the storage device, discovered in the previous step: - -```bash -bmaptool copy ./agl-demo-platform-$MACHINE.wic.xz $SDCARD -``` - -Or you can be uncompressed and written to the device: - -```bash - sudo umount /dev/sdc - xzcat ./agl-demo-platform-$MACHINE.wic.xz | sudo dd of=$SDCARD bs=4M - sync -``` - -### Booting the board - -* Turn the board off using the power switch. -* Insert the microSD-card. -* Verify that you have plugged in, at least : - * An external monitor on HDMI port - * An input device (keyboard, mouse, touchscreen...) on USB port. - -* Turn the board on using the power switch. - After a few seconds, you'll see the AGL splash screen on the display and you'll be able to log in on the console terminal or in the graphic screen. - -## Serial Console Setup - -### Install a serial client on your computer - -This can be “screen”, “picocom”, “minicom”. -The lighter of the 3 is “picocom” (it has less dependencies). - -### Plug a USB cable from your computer to the serial CP2102 USB port (micro USB-A) - -With “dmesg” you can check the device created for the serial link. -Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host. -To get it, you must switch the board on. -For example: - -```bash -dmesg | tail -[2097783.287091] usb 2-1.5.3: new full-speed USB device number 24 using ehci-pci -[2097783.385857] usb 2-1.5.3: New USB device found, idVendor=0403, idProduct=6001 -[2097783.385862] usb 2-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 -[2097783.385864] usb 2-1.5.3: Product: FT232R USB UART -[2097783.385866] usb 2-1.5.3: Manufacturer: FTDI -[2097783.385867] usb 2-1.5.3: SerialNumber: AK04WWCE -[2097783.388288] ftdi_sio 2-1.5.3:1.0: FTDI USB Serial Device converter detected -[2097783.388330] usb 2-1.5.3: Detected FT232RL -[2097783.388658] usb 2-1.5.3: FTDI USB Serial Device converter now attached to ttyUSB0 -``` - -The link is attached to the device /dev/ttyUSB0. -It is time to launch your serial client. -Example: - -```bash -picocom -b 115200 /dev/ttyUSB0 -``` - -or - -```bash -minicom -b 115200 -D /dev/ttyUSB0 -``` - -or - -```bash -screen /dev/ttyUSB0 115200 -``` - -### Power on the board to see a shell on the console - -* For machine h3ulcb: - -```bash -NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 -NOTICE: BL2: PRR is R-Car H3 ES1.1 -NOTICE: BL2: LCM state is CM -NOTICE: BL2: DDR1600(rev.0.15) -NOTICE: BL2: DRAM Split is 4ch -NOTICE: BL2: QoS is Gfx Oriented(rev.0.30) -NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 -NOTICE: BL2: Lossy Decomp areas -NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 -NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 -NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 -NOTICE: BL2: v1.1(release):41099f4 -NOTICE: BL2: Built : 19:20:52, Jun 9 2016 -NOTICE: BL2: Normal boot -NOTICE: BL2: dst=0xe63150c8 src=0x8180000 len=36(0x24) -NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=3072(0xc00) -NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) -NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) -NOTICE: BL2: dst=0x49000000 src=0x8640000 len=1048576(0x100000) - - -U-Boot 2015.04 (Jun 09 2016 - 19:21:52) - -CPU: Renesas Electronics R8A7795 rev 1.1 -Board: H3ULCB -I2C: ready -DRAM: 3.9 GiB -MMC: sh-sdhi: 0, sh-sdhi: 1 -In: serial -Out: serial -Err: serial -Net: Board Net Initialization Failed -No ethernet found. -Hit any key to stop autoboot: 0 -=> -``` - -* For machine m3ulcb: - -``` -NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 -NOTICE: BL2: PRR is R-Car M3 Ver1.0 -NOTICE: BL2: Board is Starter Kit Rev1.0 -NOTICE: BL2: Boot device is HyperFlash(80MHz) -NOTICE: BL2: LCM state is CM -NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 -NOTICE: BL2: DDR1600(rev.0.22)NOTICE: [COLD_BOOT]NOTICE: ..0 -NOTICE: BL2: DRAM Split is 2ch -NOTICE: BL2: QoS is default setting(rev.0.17) -NOTICE: BL2: Lossy Decomp areas -NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 -NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0 -NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 -NOTICE: BL2: v1.3(release):4eef9a2 -NOTICE: BL2: Built : 00:25:19, Aug 25 2017 -NOTICE: BL2: Normal boot -NOTICE: BL2: dst=0xe631e188 src=0x8180000 len=512(0x200) -NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) -NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) -NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) -NOTICE: BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000) - - -U-Boot 2015.04-dirty (Aug 25 2017 - 10:55:49) - -CPU: Renesas Electronics R8A7796 rev 1.0 -Board: M3ULCB -I2C: ready -DRAM: 1.9 GiB -MMC: sh-sdhi: 0, sh-sdhi: 1 -In: serial -Out: serial -Err: serial -Net: ravb -Hit any key to stop autoboot: 0 -=> -``` - -### Configure U-boot parameters - -Follow the steps below to configure the boot from microSD card and to set screen resolution: - -* Turn the board on using the power switch. -* Hit any key to stop autoboot (warning you have only few seconds). -* Type **printenv** to check if you have correct parameters for booting your board: - * Example for a h3ulcb: - - ``` - => printenv - baudrate=115200 - bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 - bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 - bootdelay=3 - fdt_high=0xffffffffffffffff - initrd_high=0xffffffffffffffff - load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb - load_ker=ext4load mmc 0:1 0x48080000 /boot/Image - stderr=serial - stdin=serial - stdout=serial - ver=U-Boot 2015.04 (Jun 09 2016 - 19:21:52) - - Environment size: 648/131068 bytes - ``` - - * Example for a m3ulcb: - - ``` - => printenv - baudrate=115200 - bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 - bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 - bootdelay=3 - fdt_high=0xffffffffffffffff - filesize=cdeb - initrd_high=0xffffffffffffffff - load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb - load_ker=ext4load mmc 0:1 0x48080000 /boot/Image - stderr=serial - stdin=serial - stdout=serial - ver=U-Boot 2015.04 (Nov 30 2016 - 18:25:18) - - Environment size: 557/131068 bytes - ``` - - * To boot on a sd card, it is recommended to set your environment using these commands : - - ``` - setenv bootargs console=ttySC0,115200 ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2 - setenv bootcmd run load_ker\; run load_dtb\; booti 0x48080000 - 0x48000000 - setenv load_ker ext4load mmc 0:1 0x48080000 /boot/Image - ``` - - * For machine h3ulcb (BSP >= 2.19): - - ``` - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb.dtb - ``` - - * For machine h3ulcb (BSP < 2.19): - - ``` - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb - ``` - - * For machine m3ulcb: - - ```bash - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb - ``` - - * For machine m3ulcb with a kingfisher board: - - ```bash - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb-kf.dtb - ``` - - * For machine h3ulcb with a kingfisher board: - - ```bash - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb-kf.dtb - ``` - - * Finally save boot environment: - - ```bash - saveenv - ``` - -* Now you can boot: - -``` -run bootcmd -``` - -### Console boot - -After booting, you should see the wayland display on the external monitor and a login prompt on the console, such as: - -* For machine h3ulcb: - -```bash -Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 - -h3ulcb login: root -``` - -* For machine m3ulcb: - -```bash -Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0 - -m3ulcb login: root -``` - -Logging in on the console is easy: - -* login is 'root' -* password is empty (not asked) - -### Network access - -If the board is connected to a local network using ethernet and if a DHCP server is able to distribute IP addresses, -you can then determine the Gen3 board IP address and log in using ssh: - -```bash -m3ulcb login: root -Last login: Tue Dec 6 09:55:15 UTC 2016 on tty2 -root@m3ulcb:~# ip -4 a -1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default - inet 127.0.0.1/8 scope host lo - valid_lft forever preferred_lft forever -3: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 - inet 10.0.0.27/24 brd 10.0.0.255 scope global eth0 - valid_lft forever preferred_lft forever -root@m3ulcb:~# -``` - -Here, IP address is 10.0.0.27. Logging in using SSH is easy: - -```bash -$ ssh root@10.0.0.27 -Last login: Tue Dec 6 10:01:11 2016 from 10.0.0.13 -root@m3ulcb:~# cat /etc/os-release -ID="poky-agl" -NAME="Automotive Grade Linux" -VERSION="3.0.0+snapshot-20161202 (chinook)" -VERSION_ID="3.0.0-snapshot-20161202" -PRETTY_NAME="Automotive Grade Linux 3.0.0+snapshot-20161202 (chinook)" -``` - -## More Documentation - -Detailed guides on how to build AGL for Renesas boards and using AGL SDK inside a ready-to-use Docker container: - -* [AGL-Devkit-Build-your-1st-AGL-Application.pdf][Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application] - Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. -* [AGL-Devkit-HowTo_bake_a_service.pdf][Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service] - Generic guide on how to add a new service in the BSP. -* [AGL-Kickstart-on-Renesas-Porter-Board.pdf][Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board] -* [AGL-Devkit-Image-and-SDK-for-Porter.pdf][Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter] -* [AGL Developer Website](http://docs.automotivelinux.org) - -[R-car m3ulcb]: http://elinux.org/R-Car/Boards/M3SK -[R-car m3ulcb firmware update]: https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware -[R-car h3ulcb]: http://elinux.org/R-Car/Boards/H3SK -[R-car h3ulcb firmware update]: https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware -[R-car salvator-x]: https://elinux.org/R-Car/Boards/Salvator-X -[R-car loader update]: http://elinux.org/R-Car/Boards/Kingfisher#How_to_update_of_Sample_Loader_and_MiniMonitor -[R-car Kingfisher]: https://elinux.org/R-Car/Boards/Kingfisher -[R-car yocto]: http://elinux.org/R-Car/Boards/Yocto-Gen3 -[rcar Linux Drivers]: https://www.renesas.com/solutions/automotive/rcar-download/rcar-demoboard.html -[rcar Linux Drivers 2]: https://www.renesas.com/en-us/solutions/automotive/rcar-download/rcar-demoboard-2.html -[Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf -[Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf -[Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf -[Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf - diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index e8d9825..14c91e1 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -18,8 +18,27 @@ image for the following Renesas platforms: The information on this page describes setup and build procedures for both these Renesas development kits. +You can find more information on building images from these resources: -## 1. Downloading Prioprietory Drivers +**WRITER NOTE:** +This following list looks a bit dated. +Do we want to update these PDFs or are they still useful? + +* [AGL-Devkit-Build-your-1st-AGL-Application.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf) + Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. + This is really about building an application and not the AGL image. +* [AGL-Devkit-HowTo_bake_a_service.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf) + Generic guide on how to add a new service in the BSP. + Goes back to 2015 and uses Yocto 2.x. + Includes stuff on building an image but looks like the focus is really the service. +* [AGL-Kickstart-on-Renesas-Porter-Board.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf) + Guide on how to build an image for the Porter Board using AGL 2.0. +* [AGL-Devkit-Image-and-SDK-for-Porter.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf) + Guide on building an AGL image and SDK for the Porter board. + Uses Yocto 2.x. + + +## 1. Downloading Proprietary Drivers Before setting up the build environment, you need to download proprietary drivers from the [R-Car H3/M3 Software library and Technical document](https://www.renesas.com/us/en/solutions/automotive/rcar-download/rcar-demoboard-2.html) @@ -135,11 +154,11 @@ Follow these steps to download the drivers you need: * Supported Starter Kit Gen3 board with its 5V power supply. * Micro USB-A cable for serial console. - This cable is optional if you are using ethernet and an SSH connection. + This cable is optional if you are using Ethernet and an SSH connection. * USB 2.0 Hub. The hub is optional but makes it easy to connect multiple USB devices. * Ethernet cable. The cable is optional if you are using a serial console. * HDMI type D (Micro connector) cable and an associated display. - * 4Gbyte minimum micro-SD Card. It is recommended that you use a class 10 type. + * 4 Gbyte minimum MicroSD Card. It is recommended that you use a class 10 type. * USB touch screen device such as the GeChic 1502i/1503i. A touch screen device is optional. **NOTE:** The Salvator-X Board has NDA restrictions. @@ -260,120 +279,162 @@ Follow these steps to download the drivers you need: ## 5. Checking Your Configuration +Aside from environment variables and parameters you establish through +running the `aglsetup.sh` script, you can ensure your build's configuration +is just how you want it by examining the `local.conf` configuration file. -4. **Customize your build configuration:** Aside from environment variables - and parameters you establish through running the `aglsetup.sh` script, - you can ensure your build's configuration is just how you want it by - examining the `local.conf` configuration file. - In general, the defaults along with the configuration fragments the - `aglsetup.sh` script applies 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/). +You can find this configuration file in the Build Directory (e.g. +"$TOP_DIR/build/conf/local.conf"). +In general, the defaults along with the configuration fragments the +`aglsetup.sh` script applies in the `local.conf` 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 common configurations you might want to consider. +**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/). +A quick way to see if you have the `$MACHINE` variable set correctly +is to use the following command: +```bash +grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf +``` -Users may want to check that the board is correctly selected in the environment: +Depending on the Renesas board you are using, you should see output +as follows: ```bash -grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf MACHINE = "h3ulcb" +``` or +```bash MACHINE = "m3ulcb" +``` or +```bash MACHINE = "h3-salvator-x" ``` -Configure for Release or Development: +If you ran the `aglsetup.sh` script as described in the +"[Making Sure Your Build Environment is Correct](./renesas.html#4-making-sure-your-build-environment-is-correct)" +section earlier, the "agl-devel", "agl-demo", "agl-netboot", "agl-appfw-smack", and +"agl-localdev" AGL features will be in effect. +These features provide the following: + +* A debugger (gdb) +* Some tweaks, including a disabled root password +* A SFTP server +* The TCF Agent for easier application deployment and remote debugging +* Some extra system tools such as USB and bluetooth +* Support for the AGL demo platform +* Network boot support through TFTP and NBD protocols +* [IoT.bzh](https://iot.bzh/en/) Application Framework plus + [SMACK](https://en.wikipedia.org/wiki/Smack_(software)) and + [Cynara](https://wiki.tizen.org/Security:Cynara) +* Support for local development including `localdev.inc` when present + +## 6. Using BitBake + +This section shows the `bitbake` command used to build the AGL image. +Before running BitBake to start your build, it is good to be reminded that AGL +does provide pre-built images for developers that work with supported hardware. +You can find these pre-built images on the +[AGL Download web site](https://download.automotivelinux.org/AGL/release). + +For supported Renesas boards, the filenames have the following form: -* development images contain extra tools for developer convenience, in particular: - * a debugger (gdb) - * some tweaks, including a disabled root password - * a SFTP server - * the TCF Agent for easier application deployment and remote debugging - * some extra system tools (usb, bluetooth ...) - * ... - -We explicitely activate these debug facilities by specifying the “agl-devel agl-netboot” feature. +``` +//m3ulcb-nogfx/deploy/images/m3ulcb/Image-m3ulcb.bin +``` -## Building the AGL Demo Platform for R-Car Starter Kit Gen3 +Start the build using the `bitbake` command. -### Build your image +**NOTE:** An initial build can take many hours depending on your +CPU and and Internet connection speeds. +The build also takes approximately 100G-bytes of free disk space. -The process to build an image is simple: +For this example, the target is "agl-demo-platform": ```bash -bitbake agl-demo-platform + bitbake agl-demo-platform ``` -You may need to install rpcgen to run this command. - -When finished (it may take few hours), you should get the final result: +The build process puts the resulting image in the Build Directory: -```bash -ls -l $AGL_TOP/build/tmp/deploy/images/$MACHINE +``` +/tmp/deploy/images/$MACHINE ``` -**Note**: +## 7. Booting the Image Using a MicroSD Card -In case of failure of the build it is safe to first check that the Linux distribution chosen for your host has been validated for the current version of Yocto used by AGL. +To boot your image on the Renesas board, you need to do three things: -## 7. Booting the Image Using a MicroSD Card +1. Update all firmware on the board. +2. Prepare the MicroSD card to you can boot from it. +3. Boot the board. -To boot the board using a micro-SD card, there are two operations that must be done prior to first initial boot: +**NOTE:** For subsequent builds, you only have to re-write the MicroSD +card with a new image. -* Update all firmware on the device. -* Set up the board to boot on the SD-card. +### Updating the Board's Firmware -For each subsequent build you only need to rewrite the SD-card with the new image. +Follow these steps to update the firmware: -### Firmware Update +1. **Update the Sample Loader and MiniMonitor:** -This proceedure is done in two steps. The 'Sample Loader and MiniMonitor update' step only needs to be done once per device. The 'Firmware stack update' step is mandatory only if you use AGl Eel (version 5.0) or later. + You only need to make these updates one time per device. -#### Sample Loader and MiniMonitor update + Follow the procedure found on the + [eLinux.org wiki][R-car loader update] to update to at least version 3.02, + which is mandatory to run the AGL image. -Follow the documentation on the [eLinux.org wiki][R-car loader update] to update to at least version 3.02. This is mandatory to run AGL. +2. **Update the Firmware Stack:** -#### Firmware stack update + You only need to update the firmware stack if you are + using the Eel or later (5.0) version of AGL software. -As an AArch64 platform, both **h3ulcb** and **m3ulcb** have a firmware stack divided in : **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. + M3 and H3 Renesas board are AArch64 platforms. + As such, they have a firmware stack that is divided across: **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. -If you use AGl Eel (version 5.0) or later, you must update the firmware using the following links to eLinux.org wiki: **[h3ulcb][R-car h3ulcb firmware update]** or **[m3ulcb][R-car m3ulcb firmware update]**. + If you are using the Eel (5.0) version or later of the AGL software, you must update + the firmware using the **[h3ulcb][R-car h3ulcb firmware update]** + or **[m3ulcb][R-car m3ulcb firmware update]** links from the + [Embedded Linux Wiki](https://www.elinux.org/Main_Page) (i.e. `elinux.org`). -The files listed in the eLinux.org wiki table will be found in the directory: + The table in the wiki lists the files you need to flash the firmware. + You can find these files in the following directory: -```bash -*\$AGL_TOP/build/tmp/deploy/images/$MACHINE* -``` + ```bash + $AGL_TOP/build/tmp/deploy/images/$MACHINE + ``` -The Salvator-X firmware update process is not documented on eLinux. + **NOTE:** The Salvator-X firmware update process is not documented on eLinux. -### Prepare the SD-card on the host +### Preparing the MicroSD Card -Plug the microSD card and get its associated device by either running *`dmesg | tail -15`* or *`lsblk`*, for example: +Plug the MicroSD card into your Build Host. +After plugging in the device, use the `dmesg` command as follows to +discover the device name: ```bash -dmesg | tail -15 - - [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 - [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found - [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through - [ 1971.463870] sdc: sdc1 sdc2 +$ dmesg | tail -4 +[ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 +[ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found +[ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through +[ 1971.463870] sdc: sdc1 sdc2 ``` -Here, the SD-card is attached to the device /dev/sdc. +In the previous example, the MicroSD card is attached to the device `/dev/sdc`. -```bash -lsblk +You can also use the `lsblk` command to show all your devices. +Here is an example that shows the MicroSD card as `/dev/sdc`: +```bash +$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 167,7G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi @@ -386,30 +447,37 @@ lsblk └─sdc2 8:34 1 788M 0 part ``` -**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time: -so you should repeat this operation each time you insert the microSD card to confirm the device name. +**IMPORTANT NOTE:** Before re-writing any device on your Build Host, you need to +be sure you are actually writing to the removable MicroSD card and not some other +device. +Each computer is different and removable devices can change from time to time. +Consequently, you should repeat the previous operation with the MicroSD card to +confirm the device name every time you write to the card. -In the example above, we see: +To summarize this example so far, we have the following: -* the first SATA drive as 'sda'. -* 'sdc' corresponds to the microSD card, and is also marked as removable device by *lsblk* which is a good confirmation. -* Your desktop system probably offers a choice to mount the SD-card automatically in some directory. -* In the next sample code, we'll suppose that the SD-card mount directory is stored in the variable $SDCARD. -* For example, if the microSD card is associated with device *sdc*: +* The first SATA drive is `/dev/sda`. +* `/dev/sdc` corresponds to the MicroSD card, and is also marked as a removable device. + You can see this in the output of the `lsblk` command where "1" appears in the "RM" column + for that device. -Go to your build directory: +Now that you have identified the device you are going to be writing the image on, +you can use the `bmaptool` to copy the image to the MicroSD card. -```bash -cd $AGL_TOP/build/tmp/deploy/images/$MACHINE -``` +Your desktop system might offer a choice to mount the MicroSD automatically +in some directory. +For this example, assume that the MicroSD card mount directory is stored in the +`$SDCARD` variable. -You can use bmaptool to copy the **.wic.xz** file to the storage device, discovered in the previous step: +Following are example commands that write the image to the MicroSD card: ```bash +cd $AGL_TOP/build/tmp/deploy/images/$MACHINE bmaptool copy ./agl-demo-platform-$MACHINE.wic.xz $SDCARD ``` -Or you can be uncompressed and written to the device: +Alternatively, you can leave the image in an uncompressed state and write it +to the MicroSD card: ```bash sudo umount /dev/sdc @@ -417,33 +485,60 @@ Or you can be uncompressed and written to the device: sync ``` -### Booting the board +### Booting the Board + +Follow these steps to boot the board: + +1. Use the board's power switch to turn off the board. + +2. Insert the MicroSD card into the board. + +3. Verify that you have plugged in the following: + + * An external monitor into the board's HDMI port + + * An input device (e.g. keyboard, mouse, touchscreen, and so forth) into the board's USB ports. + +4. Use the board's power switch to turn on the board. -* Turn the board off using the power switch. -* Insert the microSD-card. -* Verify that you have plugged in, at least : - * An external monitor on HDMI port - * An input device (keyboard, mouse, touchscreen...) on USB port. +After a few seconds, you will see the AGL splash screen on the display and you +will be able to log in at the console's terminal or using the graphic screen. -* Turn the board on using the power switch. - After a few seconds, you'll see the AGL splash screen on the display and you'll be able to log in on the console terminal or in the graphic screen. +## 8. Setting Up the Serial Console -## Serial Console Setup +Setting up the Serial Console involves the following: -### Install a serial client on your computer +* Installing a serial client on your build host +* Connecting your build host to your Renesas board's serial port +* Powering on the board to get a shell at the console +* Configuring U-Boot parameters +* Logging into the console +* Determining the board's IP address -This can be “screen”, “picocom”, “minicom”. -The lighter of the 3 is “picocom” (it has less dependencies). +### Installing a Serial Client on Your Build Host -### Plug a USB cable from your computer to the serial CP2102 USB port (micro USB-A) +You need to install a serial client on your build host. +Some examples are +[GNU Screen](https://en.wikipedia.org/wiki/GNU_Screen), +[picocom](https://linux.die.net/man/8/picocom), +and +[Minicom](https://en.wikipedia.org/wiki/Minicom). -With “dmesg” you can check the device created for the serial link. -Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host. -To get it, you must switch the board on. -For example: +Of these three, "picocom" has less dependencies and is therefore +considered the "lightest" solution. + +### Connecting Your Build Host to Your Renesas Board's Serial Port + +You need to physically connect your build host to the Renesas board using +a USB cable from the host to the serial CP2102 USP port (i.e. Micro USB-A port) +on the Renesas board. + +Once you connect the board, determine the device created for the serial link. +Use the ``dmesg`` command on your build host. +Here is an example: ```bash -dmesg | tail +dmesg | tail 9 [2097783.287091] usb 2-1.5.3: new full-speed USB device number 24 using ehci-pci [2097783.385857] usb 2-1.5.3: New USB device found, idVendor=0403, idProduct=6001 [2097783.385862] usb 2-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 @@ -455,29 +550,41 @@ dmesg | tail [2097783.388658] usb 2-1.5.3: FTDI USB Serial Device converter now attached to ttyUSB0 ``` -The link is attached to the device /dev/ttyUSB0. -It is time to launch your serial client. -Example: +The device created is usually "/dev/ttyUSB0". +However, the number might vary depending on other USB serial ports connected to the host. + +To use the link, you need to launch the client. +Here are three commands, which vary based on the serial client, that show +how to launch the client: + ```bash -picocom -b 115200 /dev/ttyUSB0 +$ picocom -b 115200 /dev/ttyUSB0 ``` or ```bash -minicom -b 115200 -D /dev/ttyUSB0 +$ minicom -b 115200 -D /dev/ttyUSB0 ``` or ```bash -screen /dev/ttyUSB0 115200 +$ screen /dev/ttyUSB0 115200 ``` -### Power on the board to see a shell on the console +### Powering on the Board to Get a Shell at the Console + +Both the Pro and Premier kits (e.g. +[m3ulcb](https://elinux.org/R-Car/Boards/M3SK) and +[h3ulcb](https://elinux.org/R-Car/Boards/H3SK#Hardware)) have nine +switches (SW1 through SW9). +To power on the board, "short-press" SW8, which is the power switch. -* For machine h3ulcb: +Following, is console output for the power on process for each kit: + +**h3ulcb:** ```bash NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.7 @@ -517,7 +624,7 @@ Hit any key to stop autoboot: 0 => ``` -* For machine m3ulcb: +**m3ulcb:** ``` NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.14 @@ -558,55 +665,60 @@ Hit any key to stop autoboot: 0 => ``` -### Configure U-boot parameters +### Configuring U-Boot Parameters -Follow the steps below to configure the boot from microSD card and to set screen resolution: +Follow these steps to configure the board to use the MicroSD card as the +boot device and also to set the screen resolution: -* Turn the board on using the power switch. -* Hit any key to stop autoboot (warning you have only few seconds). -* Type **printenv** to check if you have correct parameters for booting your board: - * Example for a h3ulcb: +1. As the board is powering up, press any key to stop the autoboot process. + You need to press a key quickly as you have just a few seconds in which to + press a key. - ``` - => printenv - baudrate=115200 - bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 - bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 - bootdelay=3 - fdt_high=0xffffffffffffffff - initrd_high=0xffffffffffffffff - load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb - load_ker=ext4load mmc 0:1 0x48080000 /boot/Image - stderr=serial - stdin=serial - stdout=serial - ver=U-Boot 2015.04 (Jun 09 2016 - 19:21:52) - - Environment size: 648/131068 bytes - ``` +2. Once the autoboot process is interrupted, use the board's serial console to + enter **printenv** to check if you have correct parameters for booting your board: + Here is an example using the **h3ulcb** board: - * Example for a m3ulcb: + ``` + => printenv + baudrate=115200 + bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 + bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 + bootdelay=3 + fdt_high=0xffffffffffffffff + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb + load_ker=ext4load mmc 0:1 0x48080000 /boot/Image + stderr=serial + stdin=serial + stdout=serial + ver=U-Boot 2015.04 (Jun 09 2016 - 19:21:52) + + Environment size: 648/131068 bytes + ``` - ``` - => printenv - baudrate=115200 - bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 - bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 - bootdelay=3 - fdt_high=0xffffffffffffffff - filesize=cdeb - initrd_high=0xffffffffffffffff - load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb - load_ker=ext4load mmc 0:1 0x48080000 /boot/Image - stderr=serial - stdin=serial - stdout=serial - ver=U-Boot 2015.04 (Nov 30 2016 - 18:25:18) - - Environment size: 557/131068 bytes - ``` + Here is a second example using the **m3ulcb** board: + + ``` + => printenv + baudrate=115200 + bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait ro rootfstype=ext4 + bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000 + bootdelay=3 + fdt_high=0xffffffffffffffff + filesize=cdeb + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb + load_ker=ext4load mmc 0:1 0x48080000 /boot/Image + stderr=serial + stdin=serial + stdout=serial + ver=U-Boot 2015.04 (Nov 30 2016 - 18:25:18) + + Environment size: 557/131068 bytes + ``` - * To boot on a sd card, it is recommended to set your environment using these commands : +3. To boot your board using the MicroSD card, be sure your environment is set up + as follows: ``` setenv bootargs console=ttySC0,115200 ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2 @@ -614,53 +726,59 @@ Follow the steps below to configure the boot from microSD card and to set screen setenv load_ker ext4load mmc 0:1 0x48080000 /boot/Image ``` - * For machine h3ulcb (BSP >= 2.19): +4. Depending on the board type, the BSP version, and the existence of + a Kingfisher board, make sure your ``load_dtb`` is set as follows: + + **h3ulcb with BSP version greater than or equal to 2.19**: ``` setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb.dtb ``` - * For machine h3ulcb (BSP < 2.19): + **h3ulcb with BSP version less than 2.19**: ``` setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb ``` - * For machine m3ulcb: + **m3ulcb**: ```bash setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb ``` - * For machine m3ulcb with a kingfisher board: + **m3ulcb with a Kingfisher board**: ```bash setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb-kf.dtb ``` - * For machine h3ulcb with a kingfisher board: + **h3ulcb with a Kingfisher board**: ```bash setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb-kf.dtb ``` - * Finally save boot environment: +5. Save the boot environment: ```bash saveenv ``` -* Now you can boot: +6. Boot the board: ``` run bootcmd ``` -### Console boot +### Logging Into the Console -After booting, you should see the wayland display on the external monitor and a login prompt on the console, such as: +Once the board boots, you should see the +[Wayland display](https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)) +on the external monitor. +A login prompt should appear as follows depending on your board: -* For machine h3ulcb: +**h3ulcb**: ```bash Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 @@ -668,7 +786,7 @@ Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 h3ulcb login: root ``` -* For machine m3ulcb: +**m3ulcb**: ```bash Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0 @@ -676,15 +794,16 @@ Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0 m3ulcb login: root ``` -Logging in on the console is easy: +At the prompt, login by using `root` as the login. +The password is "empty" so you should not be prompted for the password. -* login is 'root' -* password is empty (not asked) +### Determining the Board's IP Address -### Network access +If your board is connected to a local network using Ethernet and +if a DHCP server is able to distribute IP addresses, +you can determine the board's IP address and log in using `ssh`. -If the board is connected to a local network using ethernet and if a DHCP server is able to distribute IP addresses, -you can then determine the Gen3 board IP address and log in using ssh: +Here is an example for the **m3ulcb** board: ```bash m3ulcb login: root @@ -699,7 +818,10 @@ root@m3ulcb:~# ip -4 a root@m3ulcb:~# ``` -Here, IP address is 10.0.0.27. Logging in using SSH is easy: +In the previous example, IP address is 10.0.0.27. +Once you know the address, you can use `ssh` to login. +Following is an example that shows logging into SSH and then +displaying the contents of the `/etc/os-release` file: ```bash $ ssh root@10.0.0.27 @@ -711,31 +833,3 @@ VERSION="3.0.0+snapshot-20161202 (chinook)" VERSION_ID="3.0.0-snapshot-20161202" PRETTY_NAME="Automotive Grade Linux 3.0.0+snapshot-20161202 (chinook)" ``` - -## More Documentation - -Detailed guides on how to build AGL for Renesas boards and using AGL SDK inside a ready-to-use Docker container: - -* [AGL-Devkit-Build-your-1st-AGL-Application.pdf][Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application] - Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. -* [AGL-Devkit-HowTo_bake_a_service.pdf][Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service] - Generic guide on how to add a new service in the BSP. -* [AGL-Kickstart-on-Renesas-Porter-Board.pdf][Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board] -* [AGL-Devkit-Image-and-SDK-for-Porter.pdf][Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter] -* [AGL Developer Website](http://docs.automotivelinux.org) - -[R-car m3ulcb]: http://elinux.org/R-Car/Boards/M3SK -[R-car m3ulcb firmware update]: https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware -[R-car h3ulcb]: http://elinux.org/R-Car/Boards/H3SK -[R-car h3ulcb firmware update]: https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware -[R-car salvator-x]: https://elinux.org/R-Car/Boards/Salvator-X -[R-car loader update]: http://elinux.org/R-Car/Boards/Kingfisher#How_to_update_of_Sample_Loader_and_MiniMonitor -[R-car Kingfisher]: https://elinux.org/R-Car/Boards/Kingfisher -[R-car yocto]: http://elinux.org/R-Car/Boards/Yocto-Gen3 -[rcar Linux Drivers]: https://www.renesas.com/solutions/automotive/rcar-download/rcar-demoboard.html -[rcar Linux Drivers 2]: https://www.renesas.com/en-us/solutions/automotive/rcar-download/rcar-demoboard-2.html -[Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf -[Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf -[Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf -[Iot.bzh AGL_Phase2-Devkit-HowTo_bake_a_service]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf - -- cgit 1.2.3-korg From 4149e2b20668c49b41dd1bbd292b155ea42a2713 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 26 Nov 2018 14:00:38 -0800 Subject: R-Car Build: Fixed spacing problem for list. Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/renesas.md | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index 14c91e1..c3943bc 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -457,6 +457,7 @@ confirm the device name every time you write to the card. To summarize this example so far, we have the following: * The first SATA drive is `/dev/sda`. + * `/dev/sdc` corresponds to the MicroSD card, and is also marked as a removable device. You can see this in the output of the `lsblk` command where "1" appears in the "RM" column for that device. -- cgit 1.2.3-korg From 832e42d64c7182aacc7e7e5b5d6cf71e75252879 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 26 Nov 2018 14:01:24 -0800 Subject: AGL Image Build: Provided links to R-Car and Raspberry PI sections. Signed-off-by: Scott Rifenbark --- docs/getting-started/image-workflow-build.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/image-workflow-build.md b/docs/getting-started/image-workflow-build.md index 4ea9018..0e28e25 100644 --- a/docs/getting-started/image-workflow-build.md +++ b/docs/getting-started/image-workflow-build.md @@ -14,5 +14,5 @@ or VirtualBox: * [Most Intel-based 64-Bit Boards](./machines/intel.html/) * [Emulation](./machines/qemu.html/) -* R Car Starter Kit Gen3 Board -* Raspberry PI 2 or 3 +* [R Car Starter Kit Gen3 Board](./machines/renesas.html/) +* [Raspberry PI 2 or 3](./machines/raspberrypi.html/) -- cgit 1.2.3-korg From 585389dc83aa377002b75ca348b2d789d0a97776 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 26 Nov 2018 14:01:58 -0800 Subject: Raspberry PI: Re-wrote the section on Raspberry PI build process. Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/raspberrypi.md | 154 +++++++++++++++++++++++---- 1 file changed, 132 insertions(+), 22 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md index f963e0b..b1b31cb 100644 --- a/docs/getting-started/machines/raspberrypi.md +++ b/docs/getting-started/machines/raspberrypi.md @@ -1,39 +1,149 @@ -# Building the AGL Demo Platform for Raspberry Pi +# Building for Raspberry PI 2 or 3 -## Raspberry Pi 3 +The +[Raspberry PI](https://www.raspberrypi.org/help/what-%20is-a-raspberry-pi/) is a small +computer that is ideal for learning computing and computer languages. +The AGL Project supports building images for the +[Raspberry PI 2](https://www.raspberrypi.org/products/raspberry-pi-2-model-b/) and the +[Raspberry PI 3](https://www.raspberrypi.org/products/raspberry-pi-3-model-a-plus/) boards. +Each of these boards comes in a variety of models. +See the +[Raspberry PI Product Page](https://www.raspberrypi.org/products/) for more information. -To build AGL demo platform for Raspberry Pi 3 use machine **raspberrypi3** and feature **agl-demo**: +This section describes the steps you need to take to build the +AGL demo image for both the Raspberry PI 2 and 3 boards. + +## 1. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +section presented generic information for setting up your build environment +using the `aglsetup.sh` script. +If you are building the AGL demo image for a Raspberry PI board, you need to specify some +specific options when you run the script. + +Use the following commands to initialize your build environment. +In each case, the "-m" option specifies the machine and the +list of AGL features used with script are appropriate for development of +the AGL demo image suited for either Raspberry PI 2 or 3: + +**Raspberry PI 2**: ```bash -source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-appfw-smack -bitbake agl-demo-platform +$ source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-appfw-smack ``` -## Raspberry Pi 2 - -To build AGL demo platform for Raspberry Pi 2 use machine **raspberrypi2** and feature **agl-demo**: +**Raspberry PI 3**: ```bash -source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-appfw-smack -bitbake agl-demo-platform +$ source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-appfw-smack ``` -## 2. Booting the Image on Raspberry Pi +## 2. Using BitBake -Follow the steps below to copy the image to microSD card and to boot it on Raspberry Pi 2 or 3: +This section shows the `bitbake` command used to build the AGL image. +Before running BitBake to start your build, it is good to be reminded that AGL +does provide a pre-built image for developers that want to use the Raspberry PI 3 +board. +You can find this pre-built image on the +[AGL Download web site](https://download.automotivelinux.org/AGL/release). + +For the supported image, the filename has the following form: + +``` +//raspberrypi3/deploy/images/raspberrypi3/* +``` -* Connect your sdcard in your linux machine. -* Copy output image from build machine to linux machine that is connected your sdcard. (Often, those are same machines) -* Output Image location in build machine for Raspberry Pi 2: *tmp/deploy/images/raspberrypi2/agl-demo-platform-raspberrypi2.wic.xz* -* Output Image location in build machine for Raspberry Pi 3: *tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic.xz* -* Unmount the microSD card and after that flash output image to it card with root user: +Start the build using the `bitbake` command. -*Note: the sdimage files can also be named rpi-sdimg-ota in case you have the **"agl-sota"** feature enabled* +**NOTE:** An initial build can take many hours depending on your +CPU and and Internet connection speeds. +The build also takes approximately 100G-bytes of free disk space. + +For this example, the target is "agl-demo-platform": ```bash -sudo umount [sdcard device] -xzcat [output image] | sudo dd of=[sdcard device] bs=4M -sync +$ bitbake agl-demo-platform +``` + +By default, the build process puts the resulting image in the Build Directory. +Here is example for the Raspberry PI 3 board: + ``` +/tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic.xz +``` + +If you build for the Raspberry PI 2 board, the location uses "raspberrypi2" in the path. + +## 2. Deploying the AGL Demo Image + +Deploying the AGL demo image consists of copying the image on a MicroSD card, +plugging the card into the Raspberry PI board, and then booting the board. + +Follow these steps to copy the image to a MicroSD card and boot +the image on the Raspberry PI 2 or 3 board: + +1. Plug your MicroSD card into your Build Host (i.e. the system that has your build output). + +2. Be sure you know the MicroSD device name. + + Use the `dmesg` command as follows to discover the device name: + + ```bash + $ dmesg | tail -4 + [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 + [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found + [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through + [ 1971.463870] sdc: sdc1 sdc2 + ``` + + In the previous example, the MicroSD card is attached to the device `/dev/sdc`. + + You can also use the `lsblk` command to show all your devices. + Here is an example that shows the MicroSD card as `/dev/sdc`: + + ```bash + $ lsblk + NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT + sda 8:0 0 167,7G 0 disk + ├─sda1 8:1 0 512M 0 part /boot/efi + ├─sda2 8:2 0 159,3G 0 part / + └─sda3 8:3 0 7,9G 0 part [SWAP] + sdb 8:16 0 931,5G 0 disk + └─sdb1 8:17 0 931,5G 0 part /media/storage + sdc 8:32 1 14,9G 0 disk + ├─sdc1 8:33 1 40M 0 part + └─sdc2 8:34 1 788M 0 part + ``` + + **IMPORTANT NOTE:** Before re-writing any device on your Build Host, you need to + be sure you are actually writing to the removable MicroSD card and not some other + device. + Each computer is different and removable devices can change from time to time. + Consequently, you should repeat the previous operation with the MicroSD card to + confirm the device name every time you write to the card. + + To summarize this example so far, we have the following: + + * The first SATA drive is `/dev/sda`. + + * `/dev/sdc` corresponds to the MicroSD card, and is also marked as a removable device. + You can see this in the output of the `lsblk` command where "1" appears in the "RM" column + for that device. + +3. Now that you know the device name, unmount the device and use the + `xzcat` command to copy the image to the MicroSD card. + + **NOTE:** For Raspberry PI 2, the image is at `build/tmp/deploy/images/raspberrypi2/agl-demo-platform-raspberrypi2.wic.xz`. + For Raspberry PI 3, the image is at `build/tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic.xz`. + + Be sure you are root, provide the actual device name for *sdcard_device_name*, and the actual + image name for *image_name*: + + ```bash + $ sudo umount + $ xzcat | sudo dd of= bs=4M + $ sync + ``` -* Plug your microSD card into Raspberry Pi 2 or 3 and boot the board +4. Plug your MicroSD card into the Raspberry PI board and boot the device. -- cgit 1.2.3-korg From 48d6a4e2195e5812ae192228da9d723e926801c0 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 29 Nov 2018 14:35:26 -0800 Subject: Customizing the AGL Image Build: Added sstate section Added a new section on how to use an sstate mirror from AGL. Signed-off-by: Scott Rifenbark --- docs/getting-started/image-workflow-cust-build.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'docs') diff --git a/docs/getting-started/image-workflow-cust-build.md b/docs/getting-started/image-workflow-cust-build.md index 2e712a5..3b2355b 100644 --- a/docs/getting-started/image-workflow-cust-build.md +++ b/docs/getting-started/image-workflow-cust-build.md @@ -117,3 +117,20 @@ For the AGL build you can set the download directory by adding the following to ```bash DL_DIR = "${HOME}/workspace_agl/downloads" ``` + +## Using a Shared State (sstate) Mirror + +The underlying Yocto Project build system uses Shared State Mirrors to cache +artifacts from previous builds. +You can significantly speed up builds and guard against fetcher failures by +using mirrors. +To use mirrors, add this line to your `local.conf` file in the Build directory: + +``` +SSTATE_MIRRORS_append = " file://.* https://download.automotivelinux.org/sstate-mirror/master/${DEFAULTTUNE}/PATH \n " +``` + +You can learn more about shared state and how it is used in the +"[Shared State Cache](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#shared-state-cache)" +section of the Yocto Project Reference Manual. + -- cgit 1.2.3-korg From 8e5eda536f1544891b258e7cecd1a152793d554f Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Fri, 30 Nov 2018 15:41:19 +0100 Subject: getting-started-book.yml: remove language array MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit SPEC-1996 language is now handled as suffix in yml keys Change-Id: I3971067fea3fcde8f9ab8f16669a63ef57616d98 Signed-off-by: Clément Bénier --- docs/getting-started-book.yml | 158 ++++++++++++++++++++---------------------- 1 file changed, 76 insertions(+), 82 deletions(-) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index 5fef636..0e18a75 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -3,95 +3,89 @@ books: - id: image-development-workflow order: 10 - languages: - - language: en - title: Image Development Workflow - description: - keywords: - author: "IotBzh" - website: http:docs.iot.bzh - version: master - chapters: - - url: getting-started/app-workflow-intro.md - name: Overview - - url: getting-started/image-workflow-prep-host.md - name: Preparing Your Build Host - - url: getting-started/image-workflow-download-sw.md - name: Downloading AGL Software - - url: getting-started/image-workflow-initialize-build-environment.md - name: Initializing Your Build Environment - - url: getting-started/image-workflow-cust-build.md - name: Customizing Your Build - - url: getting-started/image-workflow-build.md - name: Building the AGL Image - - url: getting-started/machines/intel.md - name: Building for Most Intel 64-Bit Hardware Platforms - - url: getting-started/machines/qemu.md - name: Building for Emulation - - url: getting-started/machines/R-Car-Starter-Kit-gen3.md - name: Build for R Car Starter Kit gen3 board - - url: getting-started/machines/raspberrypi.md - name: Build for Raspberry PI 2/3 + title: Image Development Workflow + title_fr: Processus de génération d'une image + description: + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: "%lang%/getting-started/image-workflow-intro.md" + name: Overview + name_fr: Vue d'ensemble + - url: "%lang%/getting-started/image-workflow-prep-host.md" + name: Preparing Your Build Host + - url: "%lang%/getting-started/image-workflow-download-sw.md" + name: Downloading AGL Software + - url: "%lang%/getting-started/image-workflow-initialize-build-environment.md" + name: Initializing Your Build Environment + - url: "%lang%/getting-started/image-workflow-cust-build.md" + name: Customizing Your Build + - url: "%lang%/getting-started/image-workflow-build.md" + name: Building the AGL Image + - url: "%lang%/getting-started/machines/intel.md" + name: Building for Most Intel 64-Bit Hardware Platforms + - url: "%lang%/getting-started/machines/qemu.md" + name: Building for Emulation + - url: "%lang%/getting-started/machines/R-Car-Starter-Kit-gen3.md" + name: Build for R Car Starter Kit gen3 board + - url: "%lang%/getting-started/machines/raspberrypi.md" + name: Build for Raspberry PI 2/3 - id: troubleshooting order: 51 - languages: - - language: en - title: Troubleshooting - description: Troubleshooting Description - keywords: - author: "IotBzh" - website: http:docs.iot.bzh - version: master - chapters: - - url: getting-started/troubleshooting.md - name: Generic issues - - url: getting-started/footers/intel-footer.md - name: Intel Boards - - url: getting-started/footers/raspberrypi-footer.md - name: Raspberry PI + title: Troubleshooting + description: Troubleshooting Description + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: "%lang%/getting-started/troubleshooting.md" + name: Generic issues + - url: "%lang%/getting-started/footers/intel-footer.md" + name: Intel Boards + - url: "%lang%/getting-started/footers/raspberrypi-footer.md" + name: Raspberry PI - id: sdk order: 51 - languages: - - language: en - title: SDK - description: SDK Quick Setup - keywords: - author: "IotBzh" - website: http:docs.iot.bzh - version: master - chapters: - - url: getting-started/setup-sdk-environment.md - name: SDK Quick Setup + title: SDK + description: SDK Quick Setup + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: "%lang%/getting-started/setup-sdk-environment.md" + name: SDK Quick Setup - id: app-development-workflow order: 60 - languages: - - language: en - title: Application Development Workflow - description: - keywords: - author: "IotBzh" - website: http:docs.iot.bzh - version: master - chapters: - - url: getting-started/image-workflow-intro.md - name: Overview - - url: getting-started/app-workflow-image.md - name: Download or Build Your Image - - url: getting-started/app-workflow-sdk.md - name: Download or Build Your SDK Installer - - url: getting-started/app-workflow-bootables.md - name: Create Bootable Media - - url: getting-started/app-workflow-boot.md - name: Boot the Image on the Board - - url: getting-started/app-workflow-prep-app.md - name: Get Ready to Create Your Application - - url: getting-started/app-workflow-build-app.md - name: Create and Build the Application - - url: getting-started/app-workflow-deploy-app.md - name: Deploy the Application to the Board - - url: getting-started/app-workflow-debug-app.md - name: Debug the Application + title: Application Development Workflow + description: + keywords: + author: "IotBzh" + website: http:docs.iot.bzh + version: master + chapters: + - url: "%lang%/getting-started/app-workflow-intro.md" + name: Overview + - url: "%lang%/getting-started/app-workflow-image.md" + name: Download or Build Your Image + - url: "%lang%/getting-started/app-workflow-sdk.md" + name: Download or Build Your SDK Installer + - url: "%lang%/getting-started/app-workflow-bootables.md" + name: Create Bootable Media + - url: "%lang%/getting-started/app-workflow-boot.md" + name: Boot the Image on the Board + - url: "%lang%/getting-started/app-workflow-prep-app.md" + name: Get Ready to Create Your Application + - url: "%lang%/getting-started/app-workflow-build-app.md" + name: Create and Build the Application + - url: "%lang%/getting-started/app-workflow-deploy-app.md" + name: Deploy the Application to the Board + - url: "%lang%/getting-started/app-workflow-debug-app.md" + name: Debug the Application -- cgit 1.2.3-korg From 2018c50c9fc8492241a74404bb3bf24cc90e012a Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 4 Dec 2018 17:56:35 -0800 Subject: Containers: Rename of the MD file for Containers plus edits I renamed the old SDK Quick Start file to be a "docker-container-setup.md" file. This is more appropriate for the content of this file. Edits included a complete re-write of the content to result in a procedure for installing Docker and setting up a container that has an installed SDK. Signed-off-by: Scott Rifenbark --- docs/getting-started/docker-container-setup.md | 278 +++++++++++++++++++++++++ docs/getting-started/setup-sdk-environment.md | 124 ----------- 2 files changed, 278 insertions(+), 124 deletions(-) create mode 100644 docs/getting-started/docker-container-setup.md delete mode 100644 docs/getting-started/setup-sdk-environment.md (limited to 'docs') diff --git a/docs/getting-started/docker-container-setup.md b/docs/getting-started/docker-container-setup.md new file mode 100644 index 0000000..78638b0 --- /dev/null +++ b/docs/getting-started/docker-container-setup.md @@ -0,0 +1,278 @@ +# Setting up a Docker Container + +This section explains how to quickly setup a Docker container environment +suitable for using the Yocto Project build system. +Within the container environment you can build images using BitBake +and create and package AGL applications with a Software Development +Kit (SDK) specifically tailored for your target hardware. + +Docker is an open source tool designed to make it easier to create, deploy, +and run applications by using containers. +Containers allow a developer to package up an application with all +the parts it needs, such as libraries and other dependencies, and ship +it all out as one package. + +The container you set up here is configured for Yocto Project and AGL. +This configuration means you do not have to have a native Linux build +host. +You can use a system running Microsoft or MacOS. + +You can learn more about Docker on the +[Docker Documentation](https://docs.docker.com/) site. + +**NOTE:** The information in this section has been tested using a Linux +system. +However, as previously mentioned, you could set up a Docker container +that works using Windows or MacOS. + +## 1. Installing Docker Community Edition (CE) + +If your build host does not already have +[Docker CE](https://docs.docker.com/install/) installed, you must install it. + +You can find general instructions for installing Docker CE on a Linux system +on the [Docker Site](https://docs.docker.com/engine/installation/linux/). + +You need to download the Docker CE version particular to your operating system. +For example, if you are running the Ubuntu 16.04 Linux distribution, you can +click the appropriate +[Supported Platform](https://docs.docker.com/install/#supported-platforms) checkmark +and see the instructions you need to install Docker CE on that platform. + +Follow the steps to install Docker CE for your particular distribution. +For example, the +[Get Docker CE for Ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/) +page describes how to install Docker CE on a build host running the Ubuntu +distribution. + +Successful Docker installation is measured by the results of running a "hello world" +application: + +```bash +$ sudo docker run hello-world +Hello from Docker! +This message shows that your installation appears to be working correctly. + +To generate this message, Docker took the following steps: + 1. The Docker client contacted the Docker daemon. + 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. + (amd64) + 3. The Docker daemon created a new container from that image which runs the + executable that produces the output you are currently reading. + 4. The Docker daemon streamed that output to the Docker client, which sent it + to your terminal. + +To try something more ambitious, you can run an Ubuntu container with: + $ docker run -it ubuntu bash + +Share images, automate workflows, and more with a free Docker ID: + https://hub.docker.com/ + +For more examples and ideas, visit: + https://docs.docker.com/get-started/ +``` + +## 2. Setting Up to Use Docker as a Non-Root User + +For Linux machines, Docker runs as a root user by default. +You can create a docker group and add yourself to it so that you do not +have to preface every `docker` command with `sudo`, for example. + +Follow the instructions on the +[Post-installation steps for Linux](https://docs.docker.com/install/linux/linux-postinstall/) +page for information on how to create a Docker group and add yourself to the group. + +Once you have set up to use Docker as a non-root user, you can log out of your +system, log back in, and run the "hello world" application again to verify you +do not have to use root: + +```bash +$ docker run hello-world +Hello from Docker! +This message shows that your installation appears to be working correctly. + +To generate this message, Docker took the following steps: + 1. The Docker client contacted the Docker daemon. + 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. + (amd64) + 3. The Docker daemon created a new container from that image which runs the + executable that produces the output you are currently reading. + 4. The Docker daemon streamed that output to the Docker client, which sent it + to your terminal. + +To try something more ambitious, you can run an Ubuntu container with: + $ docker run -it ubuntu bash + +Share images, automate workflows, and more with a free Docker ID: + https://hub.docker.com/ + +For more examples and ideas, visit: + https://docs.docker.com/get-started/ +``` + +## 3. Setting Up a Persistent Workspace + +Docker images are pre-configured to use a particular User Identifier (uid) and +Group Identifier (gid) that allow the Container to use the Yocto Project +build system. +The `uid:gid` provides a dedicated user account *devel*, +which belongs to `uid=1664(devel)` and `gid=1664(devel)`. + +**NOTE:** The password is `devel`. + +The `create_container.sh` script as shown in the following +section instantiates a new container and shares the following +volumes with the build host: + +* **/xdt:** + The build directory inside the container. + This directory is stored in **~/ssd/xdt_$ID**, which is specific to + the container's instance ID. + +* **/home/devel/mirror:** + A development mirror stored in **~/ssd/localmirror_$ID**, + which is specific to the container's instance ID. + +* **/home/devel/share:** + A development share at **~/devel/docker/share**, which is shared + by all containers. + +These shared volumes need the proper permissions in order form them +to be accessible from the container environment. +You can make sure permissions are in order using the following commands: + +```bash +$ mkdir ~/ssd ~/devel +$ chmod a+w ~/ssd ~/devel +``` + +**Note**: + +* To gain access from your host on files created within the container, your + host account requires to be added to group id 1664. + +## 4. Getting the Generic AGL Worker Docker Image + +You can either locate and install a pre-built image or rebuild the image. + +### Using a Pre-Built Image + +Use the `wget` command to download the latest pre-built Docker image +into your local Docker instance. +Here is an example: + +```bash +$ wget -O - https://download.automotivelinux.org/AGL/snapshots/sdk/docker/docker_agl_worker-latest.tar.xz | docker load +$ docker images + REPOSITORY TAG IMAGE ID CREATED SIZE + docker.automotivelinux.org/agl/worker-generic 5.99-95 6fcc19b4e0d7 2 weeks ago 1.56GB + jenkins latest 55720d63e328 5 weeks ago 711.9 MB + hello-world latest c54a2cc56cbb 5 months ago 1.848 kB +``` + +After loading the image, identify and export the `IMAGE_ID`. +For example, the `IMAGE_ID` given the previous command is "6fcc19b4e0d7". + +```bash +$ export IMAGE_ID=6fcc19b4e0d7 +``` + +### Building an Image + +You can build the Docker image using the +[docker-worker-generator](https://git.automotivelinux.org/AGL/docker-worker-generator/) +scripts. + +## 5. Starting the Container + +After you have the image available, use the +`create_container` script to start a new, fresh container that is +based on the AGL Worker image: + +**NOTE:** +The password for the ID "devel" inside the docker image is "devel". + +**WRITER NOTE:** I need to do this and see what this output really looks like. + +```bash +$ git clone https://git.automotivelinux.org/AGL/docker-worker-generator +$ cd docker-worker-generator +$ ./contrib/create_container 0 $IMAGE_ID +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +4fb7c550ad75 6fcc19b4e0d7 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx +``` + +## 6. Installing the AGL SDK for Your Target + +Once you have a new container that is based on the AGL Worker Image, you +can copy the SDK Installer to the container and then install +the target-specific AGL SDK. +With an SDK installed, you are able to develop AGL applications +using the SDK. + +For this section, assume that the SDK is `agl-demo-platform-crosssdk` and was built +according to the instructions in the +"[Download or Build Your SDK Installer](./app-workflow-sdk.html)" +section. + +Follow these steps: + +1. **Copy the SDK Installer to the Shared Volume: + + + + ``` + $ cp /xdt/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh ~/share + ``` + +2. Log into your "SDK Container" and install the SDK: + + ```bash + $ ssh -p 2222 devel@mysdk.local + $ install_sdk ~/share/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh + ``` + +## 7. Build Your Application + +Once you have the SDK installed in your container, you are ready +to develop your application. +See the +"[Create and Build the Application](./app-workflow-build-app.html)" +section for more information. + + + diff --git a/docs/getting-started/setup-sdk-environment.md b/docs/getting-started/setup-sdk-environment.md deleted file mode 100644 index 691702c..0000000 --- a/docs/getting-started/setup-sdk-environment.md +++ /dev/null @@ -1,124 +0,0 @@ -# AGL SDK Quick Setup - -This tutorial explains how to quickly setup an environment suitable to building and packaging AGL Applications using the SDK and a Docker container. - -The current tutorial has been tested on Linux, but may work with a few adjustments for Windows or MacOS. - -## Step 1: install Docker - -First install docker on your host, if not already done. -General instructions for Linux are available on the [Docker Site](https://docs.docker.com/engine/installation/linux/). - -Add yourself to the docker group. - -## Step 2: setup persistent workspace - -Docker images are pre-configured to use a particular uid:gid to enable the use -of OpenEmbedded build system. They provide a dedicated user account *devel* -which belong to uid=1664(devel) gid=1664(devel). (Note: password is *devel*) - -The script 'create_container' presented below instantiates a new container -and shares some volumes with the host: - -* /xdt (the build directory inside the container) is stored in ~/ssd/xdt_$ID (specific to instance ID) -* /home/devel/mirror is stored in ~/ssd/localmirror_$ID (specific to instance ID) -* /home/devel/share => points to ~/devel/docker/share (shared by all containers) - -Those shared volumes with the host needs the proper permissions to be accessible -from the contained environment. - -```bash -mkdir ~/ssd ~/devel -chmod a+w ~/ssd ~/devel -``` - -**Note**: - -* To gain access from your host on files created within the container, your - host account requires to be added to group id 1664. - -## Step 3: install the "Generic AGL Worker" Docker Image - -### Get docker image - -#### Pre-built image - -A pre-built image is available on automotivelinux download public site and can be used directly. - -First, download and load the image in your local Docker instance: - -```bash -wget -O - https://download.automotivelinux.org/AGL/snapshots/sdk/docker/docker_agl_worker-latest.tar.xz | docker load; -docker images; - REPOSITORY TAG IMAGE ID CREATED SIZE - docker.automotivelinux.org/agl/worker-generic 5.99-95 6fcc19b4e0d7 2 weeks ago 1.56GB - jenkins latest 55720d63e328 5 weeks ago 711.9 MB - hello-world latest c54a2cc56cbb 5 months ago 1.848 kB -``` - -Identify the IMAGE_ID you just loaded. In the example above, this is 6fcc19b4e0d7 - -```bash -export IMAGE_ID=6fcc19b4e0d7 -``` - -#### Rebuilt image - -The Docker image for AGL Worker can be rebuilt using the scripts published here [docker-worker-generator](https://git.automotivelinux.org/AGL/docker-worker-generator/). - -### Start image - -Then, use the 'create_container' script to start a new, fresh container based on the AGL Worker image: - -**Note**: - -* The password for the id 'devel' inside the docker image is 'devel'. - -```bash -git clone https://git.automotivelinux.org/AGL/docker-worker-generator; -cd docker-worker-generator; -./contrib/create_container 0 $IMAGE_ID; -docker ps; - CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES - 4fb7c550ad75 6fcc19b4e0d7 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx -``` - -## Step 4: install the AGL SDK for your target - -Here, we assume that we just built an image 'agl-demo-platform-crosssdk' using the Yocto build procedure documented in the [Getting Started](../) section of the documentation. - -So we can copy such file to the shared volume. - -For example, we could have built the SDK from another worker container listening with SSH on port 2223: - -```bash -create_container 1; -ssh -p 2223 devel@mybuilder.local; -... [ prepare build environment ] ... -bitbake agl-demo-platform-crosssdk; -... [ build happens in /xdt/build ] ... -cp /xdt/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh ~/share; -``` - -then login to the first "SDK Container" and install the SDK: - -```bash -ssh -p 2222 devel@mysdk.local; -install_sdk ~/share/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh; -``` - -## Step 5: build your application - -First, you must source the SDK environment you wish to use (you MUST repeat this step each time you open a new shell): - -```bash -source /xdt/sdk/environment-setup- -``` - -You're then ready to go: get the sources, run the builds ... - -```bash -git clone ; -cd ; -cmake; make; make package; -``` -- cgit 1.2.3-korg From 1d349e67c729173d0669769fd63633458613180c Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 4 Dec 2018 18:01:10 -0800 Subject: app-workflow-build-app: Re-writes to reflect how to build an app I added more general information about the build application process. Presented some various methods. Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-build-app.md | 79 +++++++++++++++++++------- 1 file changed, 59 insertions(+), 20 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-build-app.md b/docs/getting-started/app-workflow-build-app.md index dc478b1..6ce3fdd 100644 --- a/docs/getting-started/app-workflow-build-app.md +++ b/docs/getting-started/app-workflow-build-app.md @@ -1,23 +1,62 @@ # 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](../../../../../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](../../../../../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](../../../../../docs/devguides/en/dev/reference/xds/part-1/4-3_build-first-app-dashboard.html)" - section. +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 +"[Setup](../../../../../docs/devguides/en/dev/reference/xds/part-1/4-1_build-first-app-setup.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 command line tool](../../../../../docs/devguides/en/dev/reference/xds/part-1/4-2_build-first-app-cmd.html)" + section. + + * Use the XDS Dashboard. + For information on how to build the application using the XDS Dashboard, see the + "[Build using XDS Dashboard](../../../../../docs/devguides/en/dev/reference/xds/part-1/4-3_build-first-app-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. + +* **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. -- cgit 1.2.3-korg From c6514359c8c87ddd85e07e1b4788fa34a011d021 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 4 Dec 2018 18:03:08 -0800 Subject: app-workflow-prep-app: Re-write on installing a stand-alone SDK. Signed-off-by: Scott Rifenbark --- docs/getting-started/app-workflow-prep-app.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-prep-app.md b/docs/getting-started/app-workflow-prep-app.md index 7985a6a..7768c76 100644 --- a/docs/getting-started/app-workflow-prep-app.md +++ b/docs/getting-started/app-workflow-prep-app.md @@ -43,11 +43,15 @@ and then use XDS to install the SDK: "[Installing AGL SDKs](../../../../../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](../../../../../docs/getting_started/en/dev/reference/setup-sdk-environment.html)" - section for steps on how to work with a stand-alone SDK. +## 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. -- cgit 1.2.3-korg From a5949510b0abbdf0041242364b1e6ca2a82eedf4 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 4 Dec 2018 18:04:10 -0800 Subject: image-workflow-prep-host: Updated a link to the new container sect. Signed-off-by: Scott Rifenbark --- docs/getting-started/image-workflow-prep-host.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/getting-started/image-workflow-prep-host.md b/docs/getting-started/image-workflow-prep-host.md index 1205ac0..5bfaec1 100644 --- a/docs/getting-started/image-workflow-prep-host.md +++ b/docs/getting-started/image-workflow-prep-host.md @@ -36,7 +36,7 @@ section for more information on the ready-made images. and so forth) as would a properly prepared build host running a supported Linux distribution. For information on how to install and set up this Docker container, see the - "[AGL SDK Quick Setup](./setup-sdk-environment.html#step-1-install-docker)" + "[Setting Up a Docker Container](./setup-sdk-environment.html)" section. 2. **Be Sure Your Build Host Has Enough Free Disk Space:** -- cgit 1.2.3-korg From 73e67f5295d372852b29cfc0be2e4b48b2e4e69e Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 11 Dec 2018 16:11:46 -0800 Subject: Preparing Host Image build: minor edits Signed-off-by: Scott Rifenbark --- docs/getting-started/image-workflow-prep-host.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/image-workflow-prep-host.md b/docs/getting-started/image-workflow-prep-host.md index 5bfaec1..d1027aa 100644 --- a/docs/getting-started/image-workflow-prep-host.md +++ b/docs/getting-started/image-workflow-prep-host.md @@ -31,12 +31,13 @@ section for more information on the ready-made images. CentOS, or Debian. If you must use a build host that is not a native Linux machine, you can - install and use a Docker container. + install and use Docker to create a container that allows you to work as + if you are using a Linux-based host. The container contains the same development environment (i.e. distros, packages, and so forth) as would a properly prepared build host running a supported Linux distribution. For information on how to install and set up this Docker container, see the - "[Setting Up a Docker Container](./setup-sdk-environment.html)" + "[Setting Up a Docker Container](./docker-container-setup.html)" section. 2. **Be Sure Your Build Host Has Enough Free Disk Space:** -- cgit 1.2.3-korg From 5107da32e113e8f8eceb85d87936756afdbb8d26 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 11 Dec 2018 16:12:28 -0800 Subject: Intel Troubleshooting: Integrated info with Intel build process I took the information from the "Troubleshooting" section for Intel devices and dispersed it within the section for building Intel devices. Much of the information was redundant and could easily fit all within the topic of Intel devices. Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/intel.md | 199 +++++++++++++++++++++++++++++++-- 1 file changed, 190 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md index 4f2756b..3222793 100644 --- a/docs/getting-started/machines/intel.md +++ b/docs/getting-started/machines/intel.md @@ -6,7 +6,7 @@ to enable most 64-bit Intel Architecture (IA) platforms that use the 64-bit UEFI as the boot loader. In addition to the MinnowBoard, support for the [upCore & UpSquared boards](http://www.up-board.org/upsquared/) exists. -MinnowBoard Max and Turbot as well as Joule are both 64-bit capable. +MinnowBoard Max and Turbot are both 64-bit capable. If you are interested in creating ***applications*** to run on hardware booted using an image built with the AGL Project, see the following: @@ -14,13 +14,23 @@ using an image built with the AGL Project, see the following: * [Application Development Workflow](../app-workflow-intro.html/overview) * [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) -UEFI has significantly evolved and you will likely want to check that your hardware's +UEFI has significantly evolved and you should check that your hardware's firmware is up-to-date. -You should make this check for both the MinnowBoard-Max and the Joule platforms. -You do not need to make this check for the MinnowBoard-Turbo and Up platforms: +You must make this check for MinnowBoard-Max platforms. +You do not need to make this check for the MinnowBoard-Turbo, upCore, and UpSquared +platforms: * [`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max) -* [`https://software.intel.com/en-us/flashing-the-bios-on-joule`](https://software.intel.com/en-us/flashing-the-bios-on-joule) +* Intel automotive Module Reference Board (MRB) + + **NOTES:** By default, these MRBs ship with an Automotive + Fast Boot loader (ABL), which requires encrypted images. + You can ask Intel's "Engineering Sales support" for a special version + of the MRB that does not require an encrypted image. + You need this type of MRB in order to test AGL on the development board. + Contact your Intel technical support representative to get the non-signed + ABL firmware. + ## 1. Making Sure Your Build Environment is Correct @@ -88,12 +98,26 @@ See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL ## 3. Creating Bootable Media -Depending on your target hardware you will use an USB stick, an SD card or a HDD/SDD. +Typically, you use a USB stick, SD card, or HDD/SDD to create bootable media. +It is possible, however, to install the AGL image onto Embedded MultiMediaCard +(eMMC). +eMMC provides card longevity at a low cost and is used in automotive infotainment +systems, avionics displays, and industrial automation/HMI control applications +to name a few. + +### USB Stick, SD Card, and HDD/SDD + +Depending on your target hardware, use a USB stick, an SD card or an HDD/SDD. The creation process remains the same independently of the selected support. It does require to have access to a Linux machine with `sudo` or root password. -Create a bootable SD card with the script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) -check the available options with the -v option. mkefi-agl.sh -v +Create a bootable SD card with the script [`mkefi-agl.sh`](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD). +Use the "-v" option to check the available options. + +**NOTE:** If you are using an Intel Module Reference Board (MRB), you need to +use the +[`mkabl-agl.sh`](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) +script instead of the `mkefi-agl.sh` script. 1. **Insert Media Device:** Insert your removable media into the corresponding interface. @@ -131,9 +155,109 @@ check the available options with the -v option. mkefi-agl.sh -v # /dev/mmcblk0 is common for an integrated SD card reader in a notebook computer. ``` +### Embedded MultiMediaCard (eMMC) + +It is possible to install the AGL image directly on the internal eMMC +rather than a removable device such as a USB stick or SD card. +To do so, requires the following steps: + +1. **Add Required Tools to Your AGL Image:** + + Add a file named `site.conf` in your `build/conf` directory. + Make sure the file has the following content: + + ``` + INHERIT += "rm_work" + IMAGE_INSTALL_append = " linux-firmware-iwlwifi-7265d" + IMAGE_INSTALL_append = " parted e2fsprogs dosfstools" + IMAGE_INSTALL_append = " linux-firmware-i915 linux-firmware-ibt linux-firmware-iwlwifi-8000c" + ``` + In addition to the previous statements, you need to add the + Intel Wireless WiFi Link (`iwlifi`) driver for your own device + as needed. + +2. **Rebuild Your Image** + + Rebuild the AGL image by following the instructions in the + "[Using BitBake](./machines/intel.html#using-bitbake)" + step of this page. + +3. **Install the Rebuilt Image Onto a Removable Device** + + Follow the steps previously described here to copy the new + image onto a removable device such as a USB stick. + +4. **Copy the Image from the USB Stick to Your Build Host's Home Directory** + + Copy the image you just temporarily installed to the removable + device to your build host's home directory. + The process uses this image later for installation in the + eMMC. + For example, copy the image file created using the Yocto Project from + the build directory to your home directory: + + ```bash + $ cp build/tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic.xz ~/ + ``` + +5. **Boot the AGL Image from the Removable Device** + + You can see how to boot the image on the target device by + following the procedure in the next section. + +6. **Connect to Your Device that is Running the Image** + + You need to use a Serial Link or SSH to connect to the device running + your image. + +7. **Determine the eMMC Device Name** + + Be sure you know the name of the eMMC device. + Use the `lsblk` command. + +8. **Install the Image into the eMMC** + + Use the `mkefi-agl.sh` Script to install the image into the eMMC. + + ``` + cat /proc/partitions + ``` +9. **Remove the USB or SD Boot Device** + + Once your image is running on the booted device, you can remove the + media used to boot the hardware. + +10. **Reboot Your Device** + + Cycle through a reboot process and the device will boot from the + eMMC. + ## 4. Booting the Image on the Target Device -Follow these steps to boot your image on the target device: +Be aware of the following when booting your device: + +* Interrupting the boot process is easier to achieve when + using a USB keyboard as opposed to a serial link. + +* During the boot process, USB hubs are not supported. + You need to connect any USB keyboard directly to your device's + USB socket. + +* It is recommended that you use F9 to permanently change the boot + order rather than interrupt the process for each subsequent boot. + Also, you must have your bootable media plugged in or connected + to the target device before you can permanently change the boot + order. + +* Booting from an SD card is faster as compared to booting from + a USB stick. + Use an SD card for better boot performance. + +* The MinnowBoard, many laptops, and NUC devices do not accept + USB3 sticks during the boot process. + Be sure your image is not on a USB3 stick. + +Use these steps to boot your device: 1. Insert the bootable media that contains the AGL image into the target device. @@ -142,6 +266,9 @@ Follow these steps to boot your image on the target device: 3. As the device boots, access the boot option screen. You generally accomplish this with the F12 key during the power up operation. + **NOTE:** When booting a MinnowBoard, you can change the default boot + device by hitting F2 during initial UEFI boot. + 4. From the boot option screen, select your bootable media device. 5. Save and exit the screen and let the device boot from your media. @@ -152,3 +279,57 @@ Follow these steps to boot your image on the target device: It is common with USB sticks that you need to boot a couple of times. For Intel devices, the serial console is configured and activated at the rate of 115200 bps. + +## 5. Miscellaneous Information + +Following is information regarding serial debug ports, serial cables, and +port names for connected displays. + +### Serial Debug Port + +Serial debug port IDs vary across hardware platforms. +By default, when you build an AGL image for an Intel target such as the +Minnowboard, Module Reference Board (MRB), or Up board, the serial debug +ports are as follows: + +* MinnowBoard uses `/dev/ttyS0` +* MRB uses `/dev/ttyS2` +* Up boards the `/dev/ttyS0` serial port is difficult to access. + Using `/dev/ttyS4` is preferred, which is routed on the Arduino + connector. + See the [Up2 Pin Specification]( http://www.up-board.org/wp-content/uploads/2017/11/UP-Square-DatasheetV0.5.pdf) + for more information. + +Depending on your particular hardware, you might need to change the +configuration in your bootloader, which is located in the EFI partition. + +### Serial Debug Cable + +On the MinnowBoard, the serial debug cable is an FTDI serial cable. +You can learn more [here](https://minnowboard.org/tutorials/best-practice-serial-connection). + +Up Boards use the same FDDI 3.3V adapter as does the MinnowBoard. +However, the pin out is not adjacent and requires split pins. + +### Port Names and Connected Displays + +Port naming can change across hardware platforms and connected displays. +The simplest way to determine the port name used for a connected display +is to check the after the initial boot process completes. +You can make this check in the `systemd` journal as follows: + +```bash +$ journalctl | grep Output +``` + +**NOTE:** Output for the +[`journalctl`](https://www.freedesktop.org/software/systemd/man/journalctl.html) +command generates only when a real display is connected to the connector on the board. +The file holding that configuration is `/etc/xdg/weston/weston.ini`. + +Common Display names for Intel platforms are the following: + +* `HDMI-A-1` +* `HDMI-A-2` +* `LVDS-1` + -- cgit 1.2.3-korg From 4d1915579f5bfbab1c596f9b105f1c10184eef31 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 11 Dec 2018 16:28:00 -0800 Subject: Intel-footer.md: Removed. Information merged into the main building for Intel devices topic. Signed-off-by: Scott Rifenbark --- docs/getting-started/footers/intel-footer.md | 90 ---------------------------- 1 file changed, 90 deletions(-) delete mode 100644 docs/getting-started/footers/intel-footer.md (limited to 'docs') diff --git a/docs/getting-started/footers/intel-footer.md b/docs/getting-started/footers/intel-footer.md deleted file mode 100644 index 967feb4..0000000 --- a/docs/getting-started/footers/intel-footer.md +++ /dev/null @@ -1,90 +0,0 @@ -## BIOS update - -Both Joule and MinnowBoard-Max (not needed on Turbo) require a BIOS upgrade before running AGL on them. - -**Do not loose any time trying without upgrading your BIOS first.** - -For instructions on how to update the BIOS on those platforms, please refer to these documents: -* [MinnowBoard](https://firmware.intel.com/projects/minnowboard-max) -* [Intel Joule](https://software.intel.com/en-us/flashing-the-bios-on-joule) -* Intel MRB contact your technical support representative to get the non signed ABL firmware
-**Note** MRB users need to replace the mkefi-agl.sh script by mkabl-agl.sh - -## Creating a bootable image - -Multiple options are avaiable but `dd` and `tar` can very easily let you down due to the requirement to pass SMACK labels, create a proper UEFI configuration and a few other tricks. -The script [mkefi-agl.sh](https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob_plain;f=scripts/mkefi-agl.sh;hb=HEAD) has been done to help you. -The option -h will print the help and the option -v will detail the operation and ease any debug. - -## Installing your image on the internal eMMC - -It can be interesting to install the AGL image directly on the internal eMMC rather than to boot from and SD or a USB removable device. -The easiest to do so, is to add the required tools in your removable boot device, boot AGL from the removable device and -then use the mkefi-agl.sh script to install the image image on the internal eMMC. - * Add the tools to the AGL image. - ** Add a file site.conf in your build/conf directory with the following content: - ``` - INHERIT += "rm_work" - IMAGE_INSTALL_append = " linux-firmware-iwlwifi-7265d" - IMAGE_INSTALL_append = " parted e2fsprogs dosfstools" - IMAGE_INSTALL_append = " linux-firmware-i915 linux-firmware-ibt linux-firmware-iwlwifi-8000c" - add the iwlifi for your own device as needed - ``` - * rebuild your image and install it on your removable device with mkefi-agl.sh. - * add the AGL image file on your removable device in the home directory (for later installation) - ``` - the AGL image file created by yocto (.wic.xz) - located in build/tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic.xz - ``` - * boot AGL from your removable device - * connect to the AGL running image either via serial link or ssh - * locate the eMMC device name - * install image with mkefi-agl.sh - ``` - cat /proc/partitions - ``` - * install the AGL image on the eMMC with mkefi-agl.sh script - * remove the USB or SD boot device - * reboot - -## Selecting the SD or USB to boot - -When booting a MinnowBoard or a Joule you can change the default boot device by hitting F2 during initial UEFI boot. -It's easier to achieve it in the right time with a USB keyboard than via serial link. -During boot USB hubs are not supported, you need to connect the keyboard directly in the USB socket. -It's also preferable to use F9 and to change the boot order once for all. -Please note: You can only change the boot order when a valid device is inserted in the corresponding port (USB or SD). - -The MinnowBoard, Joule, many laptops and NUCs will not accept to boot with some USB3 sticks. If you have some trouble to get your USB3 stick detected during boot, swap it for a USB2. In any case working with SD card is faster to flash and to boot. SD should be preferred. -The Joule seems to refuse to boot with my SD-HC-I type cards while I had no problem with the MinnowBoard. If you work with a Joule, use regular SD-HC (mode 4 and 10 work fine). - -## Serial debug Port - -Serial debug port ID varies with the HW platform. By default AGL build Intel target as a MinnowBoard where serial is `/dev/ttyS0`, on Joule and MRB the serial debug is `/dev/ttyS2`. -On Up boards the /dev/ttyS0 serial port is not easy to access and using /dev/ttyS4 which is routed on the Arduino connector.
[See pinout]( http://www.up-board.org/wp-content/uploads/2017/11/UP-Square-DatasheetV0.5.pdf) - -You may have to change the configuration in your bootloader which is located in the EFI partition. - -## Serial debug cable - -On the MinnowBoard the serial cable is an FTDI serial cable. The wiring can be found [here](http://wiki.minnowboard.org/MinnowBoard_MAX_HW_Setup).
-Up Boards use the same FDDI 3.3V adaptor than the Minnow but the pin out is not adjacent and requires to split the pins. -On the Joule the serial connection is done via the micro USB cable which is not provided in the Developer kit. Details can be found [here](https://software.intel.com/en-us/node/667851). -Interface speed is 115200 bps, 8 bits, no parity, no flow control - -## Which port name is used to define the connected display(s) - -Port naming may change with HW platforms and connected display. The simplest is to check following the first boot, in the systemd journal, which display names are listed. - -```bash -journalctl |grep Output -``` - -**Note:** The Output information is only listed if a real Display is connected to the connector on the board. -The file holding that configuration is `/etc/xdg/weston/weston.ini`. - -Common Display names for Intel are: - -* `HDMI-A-1` -* `HDMI-A-2` -* `LVDS-1` -- cgit 1.2.3-korg From a4013befcbb2c82273067e401d3d393445a5a100 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 17 Dec 2018 09:37:38 -0800 Subject: Building for Raspberry PI: Added touchscreen configuration info. Signed-off-by: Scott Rifenbark --- docs/getting-started/machines/raspberrypi.md | 78 +++++++++++++++++++++++++++- 1 file changed, 76 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md index b1b31cb..7727267 100644 --- a/docs/getting-started/machines/raspberrypi.md +++ b/docs/getting-started/machines/raspberrypi.md @@ -39,9 +39,36 @@ $ source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-a $ source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-appfw-smack ``` -## 2. Using BitBake +## 2. Configuring the Build to Include Packages Under a Commercial License + +Before launching the build, it is good to be sure your build +configuration is set up correctly (`/build/conf/local.conf` file). +The +"[Customizing Your Build](./image-workflow-cust-build.html)" +section highlights some common configurations that are useful when +building any AGL image. + +For the Raspberry PI platforms, you need to take an additional +configuration step if you want to include any packages under a +commercial license. + +For example, suppose you want to include an implementation of the +[OpenMAX](https://www.khronos.org/openmax/) Intagration Library +(`libomxil`) under a commercial license as part of your AGL image. +If so, you must include the following two lines in your +`/build/conf/local.conf` file: + +```bash +# For libomxil +LICENSE_FLAGS_WHITELIST = "commercial" + +IMAGE_INSTALL_append = " libomxil" +``` + +## 3. Using BitBake This section shows the `bitbake` command used to build the AGL image. + Before running BitBake to start your build, it is good to be reminded that AGL does provide a pre-built image for developers that want to use the Raspberry PI 3 board. @@ -54,6 +81,7 @@ For the supported image, the filename has the following form: //raspberrypi3/deploy/images/raspberrypi3/* ``` + Start the build using the `bitbake` command. **NOTE:** An initial build can take many hours depending on your @@ -75,7 +103,7 @@ Here is example for the Raspberry PI 3 board: If you build for the Raspberry PI 2 board, the location uses "raspberrypi2" in the path. -## 2. Deploying the AGL Demo Image +## 4. Deploying the AGL Demo Image Deploying the AGL demo image consists of copying the image on a MicroSD card, plugging the card into the Raspberry PI board, and then booting the board. @@ -147,3 +175,49 @@ the image on the Raspberry PI 2 or 3 board: ``` 4. Plug your MicroSD card into the Raspberry PI board and boot the device. + +## 5. Raspberry PI Touch Display + +If you have connected the official +[Raspberry PI Touch Display](https://www.raspberrypi.org/products/raspberry-pi-touch-display/), +you can configure the display by editing the `weston.ini` file. + +Plenty of information exists on how to configure and use this touchscreen. +See the following references for more information: + +* For information on where the `weston.ini` file is located, see + [location](https://jlk.fjfi.cvut.cz/arch/manpages/man/weston.ini.5#DESCRIPTION). + +* For information on the `weston.ini` file in general, see the + [manpage](https://jlk.fjfi.cvut.cz/arch/manpages/man/weston.ini.5). + +* For information on Weston, which is the reference implementation of Wayland, see + [Wayland](https://wiki.archlinux.org/index.php/wayland). + +As an example on how to configure and manipulate the touchscreen, consider +the following edits to the `weston.ini` file used to rotate the +display: + +```bash +root@raspberrypi3:/etc/xdg/weston# cat weston.ini +[core] +backend=drm-backend.so +shell=desktop-shell.so + +[shell] +locking=true +# Uncomment below to hide panel +#panel-location=none + +[launcher] +icon=/usr/share/weston/terminal.png +path=/usr/bin/weston-terminal + +[launcher] +icon=/usr/share/weston/icon_flower.png +path=/usr/bin/weston-flower + +[output] +name=DSI-1 +transform=270 +``` -- cgit 1.2.3-korg From c416cea789822940c2241e61b0cb00dbbc3c25b6 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 17 Dec 2018 11:54:49 -0800 Subject: Raspberry PI build: Integrated old debug stuff into main build. Signed-off-by: Scott Rifenbark --- .../RaspberryPi2-ModelB-debug-serial-cable.jpg | Bin 96123 -> 0 bytes docs/getting-started/footers/raspberrypi-footer.md | 56 --------------------- .../RaspberryPi2-ModelB-debug-serial-cable.png | Bin 0 -> 411744 bytes docs/getting-started/machines/raspberrypi.md | 49 +++++++++++++++++- 4 files changed, 48 insertions(+), 57 deletions(-) delete mode 100644 docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg delete mode 100644 docs/getting-started/footers/raspberrypi-footer.md create mode 100644 docs/getting-started/machines/images/RaspberryPi2-ModelB-debug-serial-cable.png (limited to 'docs') diff --git a/docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg b/docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg deleted file mode 100644 index e8026d6..0000000 Binary files a/docs/getting-started/footers/images/RaspberryPi2-ModelB-debug-serial-cable.jpg and /dev/null differ diff --git a/docs/getting-started/footers/raspberrypi-footer.md b/docs/getting-started/footers/raspberrypi-footer.md deleted file mode 100644 index f5ff16f..0000000 --- a/docs/getting-started/footers/raspberrypi-footer.md +++ /dev/null @@ -1,56 +0,0 @@ -# Commercial Licensed Packages - -Append to following lines to **conf/local.conf** to include libomxil under a commercial license to your build: - -```bash -# For libomxil -LICENSE_FLAGS_WHITELIST = "commercial" - -IMAGE_INSTALL_append = " libomxil" -``` - -# Raspberry Pi Touchscreen with Rotation - -If you have Raspberry Pi official 7" touchscreen connected, you can rotate it with these lines in /etc/xdg/weston/weston.ini - -```bash -root@raspberrypi3:/etc/xdg/weston# cat weston.ini -[core] -backend=drm-backend.so -shell=desktop-shell.so - -[shell] -locking=true -# Uncomment below to hide panel -#panel-location=none - -[launcher] -icon=/usr/share/weston/terminal.png -path=/usr/bin/weston-terminal - -[launcher] -icon=/usr/share/weston/icon_flower.png -path=/usr/bin/weston-flower - -[output] -name=DSI-1 -transform=270 -``` - -# Debugging - -It is possible to debug AGL images on Raspberry Pi using 3.3V USB to serial cable, such as [Olimex USB-Serial-Cable-F](https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/), connected to the UART of the board. Follow the instructions below to connect a cable to the board (do it on your own risk, no warranty is provided): - -* Connect the BLUE wire if you are using Olimex USB-Serial-Cable-F to pin 6 of Raspberry Pi, -* Connect the RX line of the cable (GREEN wire if you are using Olimex USB-Serial-Cable-F) to pin 8 (TX line) of Raspberry Pi, -* Connect the TX line of the cable (RED wire if you are using Olimex USB-Serial-Cable-F) to pin 10 (RX line) of Raspberry Pi. - -![Olimex USB-Serial-Cable-F attached to Raspberry PI 2 for debugging through the serial console](images/RaspberryPi2-ModelB-debug-serial-cable.jpg) - -* Plug the USB connector of the cable to your computer and use your favorite tool for serial communication, for example on Ubuntu and other Linux distributions you may use screen: - -```bash -sudo screen /dev/ttyUSB0 115200 -``` - -Pay attention that the colors of the cable may vary depending on the vendor. If you have USB console cable from Adafruit please have a look [here](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead). diff --git a/docs/getting-started/machines/images/RaspberryPi2-ModelB-debug-serial-cable.png b/docs/getting-started/machines/images/RaspberryPi2-ModelB-debug-serial-cable.png new file mode 100644 index 0000000..f4374d0 Binary files /dev/null and b/docs/getting-started/machines/images/RaspberryPi2-ModelB-debug-serial-cable.png differ diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md index 7727267..ce9337c 100644 --- a/docs/getting-started/machines/raspberrypi.md +++ b/docs/getting-started/machines/raspberrypi.md @@ -176,7 +176,7 @@ the image on the Raspberry PI 2 or 3 board: 4. Plug your MicroSD card into the Raspberry PI board and boot the device. -## 5. Raspberry PI Touch Display +## 5. Using the Raspberry PI Touch Display If you have connected the official [Raspberry PI Touch Display](https://www.raspberrypi.org/products/raspberry-pi-touch-display/), @@ -221,3 +221,50 @@ path=/usr/bin/weston-flower name=DSI-1 transform=270 ``` + +## 6. Debugging + +When things go wrong, you can take steps to debug your Raspberry PI. +For debugging, you need a 3.3 Volt USB Serial cable to fascilitate +communication between your Raspberry PI board and your build host. +A good cable to use is the 3.3V USB-to-Serial cable +[Olimex USB-Serial-Cable-F](https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/). + +**NOTE:** If you are using a USB console cable from Adafruit, see +"[Adafruit's Raspberry Pi Lesson 5](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead)" +for connection information. + +Use the following steps, which assume you are using the previously mentioned +Olimex cable. +You can reference the following diagram for information on the following steps: + +

+ +

+ +1. Connect the Olimex cable to the Universal Asynchronous Receiver-Transmitter + (UART) connection on your Raspberry PI board. + Do not connect the USB side of the cable to your build host at this time. + + **CAUTION:** No warranty is provided using the following procedure. + Pay particular attention to the collors of your cable as they could + vary depending on the vendor. + +2. Connect the cable's BLUE wire to pin 6 (i.e. Ground) of the UART. + +3. Connect the cable's GREEN RX line to pin 8 (i.e. the TXD line) of + the UART. + +4. Connect the cable's RED TX line to pin 10 (i.e. the RXD line) of + the UART. + +5. Plug the USB connector of the cable into your build host's USB port. + +6. Use your favorite tool for serial communication between your build host + and your Raspberry PI. + For example, if your build host is a native Linux machine (e.g. Ubuntu) + you could use `screen` as follows from a terminal on the build host: + + ```bash + $ sudo screen /dev/ttyUSB0 115200 + ``` -- cgit 1.2.3-korg From 60b3dd58cbe8fa2cf5a1db13db7eafd3bff3c915 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 21 Dec 2018 14:06:47 -0800 Subject: Troubleshooting: Removed the mega-rust "bug" information. This content was dated. The issue is now fixed and the error should not be seen going forward. Signed-off-by: Scott Rifenbark --- docs/getting-started/troubleshooting.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'docs') diff --git a/docs/getting-started/troubleshooting.md b/docs/getting-started/troubleshooting.md index d3ad889..4e2b495 100644 --- a/docs/getting-started/troubleshooting.md +++ b/docs/getting-started/troubleshooting.md @@ -1,5 +1,13 @@ # Troubleshooting +**WRITER'S NOTE:** This content needs a new home. + Most likely it will be in some "how-to" area as most of the information + fits that category. + For now, I am leaving it here. + The other two board-specific troubleshooting sections have been merged + into their respective build topics in the section describing how to + build an AGL image. + ## Extended attributes MUST be copied **IMPORTANT, The extended attribute set during image construction MUST be copied to the SD card.** @@ -29,8 +37,13 @@ tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --tot --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz ``` + ## Screen orientation for Splash and in Weston -- cgit 1.2.3-korg From 50dece9f8688c4c7f70827956c7cce6838e43baf Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 21 Dec 2018 14:08:03 -0800 Subject: Docker Container Setup: Mods to give this an overview Modifications to structure the first item as "Overview" This gives some parallel structure to the "Getting Started" material. Signed-off-by: Scott Rifenbark --- docs/getting-started/docker-container-setup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/getting-started/docker-container-setup.md b/docs/getting-started/docker-container-setup.md index 78638b0..d984e5f 100644 --- a/docs/getting-started/docker-container-setup.md +++ b/docs/getting-started/docker-container-setup.md @@ -1,4 +1,4 @@ -# Setting up a Docker Container +# Overview This section explains how to quickly setup a Docker container environment suitable for using the Yocto Project build system. -- cgit 1.2.3-korg From 0dfed10b0c0d539de27f3d07dea8ed5757b4b4cf Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 21 Dec 2018 14:09:55 -0800 Subject: Welcome: I added a new "Welcome" section This is landing point content for what we currenly have as the "Getting Started". The content overviews AGL and provides some reader roadmap for the "Getting Started" items. Signed-off-by: Scott Rifenbark --- docs/getting-started/getting-started-welcome.md | 79 +++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 docs/getting-started/getting-started-welcome.md (limited to 'docs') diff --git a/docs/getting-started/getting-started-welcome.md b/docs/getting-started/getting-started-welcome.md new file mode 100644 index 0000000..f1e9038 --- /dev/null +++ b/docs/getting-started/getting-started-welcome.md @@ -0,0 +1,79 @@ +Overview +======== + +Welcome to the Automotive Grade Linux (AGL) documentation +"Getting Started" page. +This page provides you with a brief overview of the AGL Distribution +and with an introduction to selected topics that can help +you get a quick start using AGL for development. + +What is Automotive Grade Linux? +------------------------------- + +Automotive Grade Linux is a collaborative, open source project +that brings together automakers, suppliers, and technology companies +for the purpose of building Linux-based, open source software platforms +for automotive applications that can serve as de facto industry +standards. + +AGL address all software in the vehicle: infotainment, +instrument cluster, heads-up-display (HUD), telematics, connected car, +advanced driver assistance systems (ADAS), functional +safety, and autonomous driving. + +Adopting a shared platform across the industry reduces fragmentation +and allows automakers and suppliers to reuse the same code base, which +leads to rapid innovation and faster time-to-market for new products. + +AGL is a Linux Foundation project and its goals are as follows: + +* Build a single platform for the entire industry +* Develop 70 to 80% of the starting point for a production project +* Reduce fragmentation by combining the best of open source +* Develop an ecosystem of developers, suppliers, and expertise + that all use a single platform + +You can find additional overview information on the +"[About Automotive Grade Linux](https://www.automotivelinux.org/about)" page. +You can find information on the AGL Unified Code Base on the +"[Unified Code Base](https://www.automotivelinux.org/software/unified-code-base)" +page. + +What Can I Do Right Away Using AGL? +----------------------------------- + +The "Getting Started" topics allow you to quickly accomplish some work using +AGL. +You can use the "Getting Started" sections to do the following: + +* [Set Up a Docker Container](./docker-container-setup.html) to create a + contained, controlled development environment for building images and + Software Development Kits (SDKs) using AGL. + +* [Learn How to Build an AGL Image](./image-workflow-intro.html) by working + through fundamental steps that show you how to build for various supported + hardware targets (e.g. Raspberry PI boards). + +* [Learn How to Create an Application](./app-workflow-intro.html) using the + application development workflow. + +The AGL community is diverse and supportive. +You can become an active community member that contributes feedback, +ideas, suggestions, bugs and documentation. + +* Join the IRC conversation using the `#automotive` channel on + `irc.freenode.net`. + +* Subscribe to the AGL discussions mailing list at + [automotive-discussions](http://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions). + +* Learn about AGL distribution by visiting the + "[AGL Distribution](https://wiki.automotivelinux.org/agl-distro)" wiki page. + +* Explore further "Getting Started" information by visiting the + "[Getting Started with AGL](https://wiki.automotivelinux.org/start/getting-started)" + wiki page. + +* Learn how to contribute by visiting the + "[Contributing to the AGL Distro](https://wiki.automotivelinux.org/agl-distro/contributing)" + wiki page. -- cgit 1.2.3-korg From 7971ad9fa151e9f765b931c6de084b6b5e360b6e Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 27 Dec 2018 13:42:36 -0800 Subject: Extended Attributes: Re-write of xattrs information This section is about how to include xattrs when you create bootable media using 'tar'. For now, it remains in the "Troubleshooting" section. Signed-off-by: Scott Rifenbark --- docs/getting-started/troubleshooting.md | 77 +++++++++++++++++++++------------ 1 file changed, 49 insertions(+), 28 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/troubleshooting.md b/docs/getting-started/troubleshooting.md index 4e2b495..ea3aba1 100644 --- a/docs/getting-started/troubleshooting.md +++ b/docs/getting-started/troubleshooting.md @@ -8,34 +8,55 @@ into their respective build topics in the section describing how to build an AGL image. -## Extended attributes MUST be copied - -**IMPORTANT, The extended attribute set during image construction MUST be copied to the SD card.** - -When using tar to create the SDcard, it is a common error to not copy the extended attributes. Find below instruction for using tar. - -Verify that **tar** version is 1.28 or newer: - -```bash -tar --version -tar (GNU tar) 1.28 -[snip] -``` - -If it is not the case, a native up-to-date version of tar is also generated while building AGL distribution: - -```bash -tmp/sysroots/x86_64-linux/usr/bin/tar-native/tar --version -tar (GNU tar) 1.28 -[snip] -``` - -To copy Automotive Grade Linux (AGL) files AND EXTENDED ATRIBUTES onto the SDcard using tar the command is: - -```bash -tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --totals \ - --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz -``` +## Including Extended Attributes + +The +[Extended Attributes Set (`xattrs`)](https://linux-audit.com/using-xattrs-extended-attributes-on-linux/) +associated with the image during its construction must be copied to +the bootable media. +The `xattrs` supports +[Smack](https://en.wikipedia.org/wiki/Smack_(software)), which is a +Simplified Mandatory Access Control kernel. + +**NOTE:** See + [https://www.kernel.org/doc/Documentation/security/Smack.txt](https://www.kernel.org/doc/Documentation/security/Smack.txt). + for detailed information on Smack. + +Many methods exist that allow you to create bootable media (e.g. `dd`, `bmaptools`, +`tar`, and AGL-provided scripts such as `mkabl-agl.sh` and `mkefi-agl.sh`). +It is recommended that you do not use `tar` to create bootable media. +However, if you do, you must take these steps to copy `xattrs` to the media: + +1. Verify your `tar` version is 1.28 or newer: + + ```bash + $ tar --version + tar (GNU tar) 1.28 + [snip] + ``` + +2. Optionally update `tar` if required. + Most systems come with `tar` installed. + If you need to install it, see the + "[Installing tar](https://www.howtoforge.com/tutorial/linux-tar-command/#installing-tar)" + section for instructions. + + When you build an AGL distribution, a native up-to-date version of + `tar` is created. + Use the following command to see that version: + + ```bash + $ tmp/sysroots/x86_64-linux/usr/bin/tar-native/tar --version + tar (GNU tar) 1.28 + [snip] + ``` + +3. Copy the AGL files and Extended Attributes Set to your bootable media: + + ```bash + $ tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --totals \ + --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz + ``` + +## How to add a new documentation section into AGL documentation -This documentation helps you to add new markdown files to AGL documentation. They are two steps to add new markdown files to AGL documentation: -- Add a book yaml file to the repository where the markdown files are. -- Add an entry into the section yaml file that point to your book file. The section yaml file is in docs-webtemplate repository (git@github.com:automotive-grade-linux/docs-webtemplate.git) named ```section_.yml```. +- Add a book yaml file to the repository where the documentation sources are located (written in markdown files). +- Add an entry into the global section yaml file that point to your book file. The section yaml file is in [docs-webtemplate](https://github.com/automotive-grade-linux/docs-webtemplate) repository (`git@github.com:automotive-grade-linux/docs-webtemplate.git`) named `section_.yml`. --- -**Note**: To generate a local documentation please refer to the README of the docs-webtemplate (https://github.com/automotive-grade-linux/docs-webtemplate) and use the script ```setupdocs.sh```. +**Note**: To generate a local documentation please refer to the [README](https://github.com/automotive-grade-linux/docs-webtemplate/blob/master-next/README.md) of the docs-webtemplate (https://github.com/automotive-grade-linux/docs-webtemplate) and use `setupdocs.sh` script. --- -## Add a book yaml file into repository +### Add a book yaml file into a repository + +The book file is needed to describe how your documentation is structured and must be used to describe +among others : + +- the global title of the doc +- the chapter name when the doc will be part of the whole documentation website +- subchapters list and consequently subchapters hierarchy +- multi-language description + + -The book file is needed to describe your documentation. There are several types of book: - book - api -### Book Type +#### Book Type -The book type describes documentation chapters. +`book` type describes documentation structure and chapters. Below the generic way to include a book file: ```yaml @@ -30,7 +47,8 @@ type: books books: - id: - order: x #optional: between 0 in 100 default is 50, it allows to define order in final #documentation, more the order number is low more the documentation is first + order: x #optional: between 0 in 100 default when not set is 50, it allows to define order in final + #documentation, more the order number is low more the documentation is first title: title of your chapter #default title title_: title in description: description of your book @@ -40,17 +58,17 @@ books: chapters: - name: Name of your subchapter name_: Name of your subchapter in - url: "%lang%/softlink/to/your/mardown.md" #%lang% will be replaced by the - #available languages, - #default language can be in the root directory + url: "%lang%/relative-path/to/your/mardown.md" #%lang% will be replaced by the + #available languages, + #default language can be in the root directory - name: Name of your subchapter name_: Name of your subchapter in - url: "%lang%/softlink/to/your/mardown.md" + url: "%lang%/relative-path/to/your/mardown.md" - name: Name of your subchapter name_: Name of your subchapter in - name: Name of your subsubchapter name_: Name of your subsubchapter in - url: "%lang%/softlink/to/your/mardown.md" + url: "%lang%/relative-path/to/your/mardown.md" - name: Name of your subsubchapter name_: Name of your subsubchapter in children: @@ -62,21 +80,25 @@ books: ... ``` -Here a simple yaml file, you can start from : +[book.yml.in](https://github.com/automotive-grade-linux/docs-sources/blob/master/docs/handle-docs/book.yml.in) +is a sort of schema of book.yml. This file contains all supported keys. + +Here a sample yaml file, you can start from : ```bash -wget https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/handle-docs/simple-book.yml +wget https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master-next/docs/getting-started-book.yml -O my-new-book.yml ``` -### Api Type +#### Api Type In progress -## Add an entry in section file +### Add an entry in section file There are 4 sections in docs: getting_started, architecture_guides, developer_guides, apis_services. -They are located in content/docs in docs-webtemplate repository. In addition, each directory contains several section yaml file, one a version. For master version, it is ```section_master.yml```. +They are located in `content/docs` in [docs-webtemplate](https://github.com/automotive-grade-linux/docs-webtemplate) repository. +In addition, each directory contains several section yaml file, one a version. For master version, it is `section_master.yml`. Below the structure of section yaml file. @@ -91,14 +113,14 @@ books: id: url_fetch: #optional, overload the default one git_commit: #optional, overload the default one - path: "softpath/from/root/repository/to/the/book/yaml/file" + path: "relativepath/from/root/repository/to/the/book/yaml/file" books: #optional: subbooks, will be a child of the above book - id: url_fetch: #optional, overload the default one git_commit: #optional, overload the default one - path: "softpath/from/root/repository/to/the/book/yaml/file" + path: "relativepath/from/root/repository/to/the/book/yaml/file" - ... - id: ... -``` \ No newline at end of file +``` diff --git a/docs/handle-docs/simple-book.yml b/docs/handle-docs/simple-book.yml deleted file mode 100644 index ebee034..0000000 --- a/docs/handle-docs/simple-book.yml +++ /dev/null @@ -1,68 +0,0 @@ -type: books -books: -- - id: - order: #optional - title: - title_fr: #optionnal - title_jp: #optionnal - description: - keywords: - author: - version: - chapters: - - name: - name_fr: #optional - name_jp: #optional - url: "%lang%/" - - name: - name_fr: #optional - name_jp: #optional - children: #optional - - name: - name_fr: #optional - name_jp: #optional - url: "%lang/" - - name: - name_fr: #optional - name_jp: #optional - children: #optional - - name: - name_fr: #optional - name_jp: #optional - - name: - name_fr: #optional - url: "%lang%/" -- - id: - order: #optional - title: - title_fr: #optionnal - title_jp: #optionnal - description: - keywords: - author: - version: - chapters: - - name: - name_fr: #optional - name_jp: #optional - url: "%lang%/" - - name: - name_fr: #optional - name_jp: #optional - children: #optional - - name: - name_fr: #optional - name_jp: #optional - url: "%lang/" - - name: - name_fr: #optional - name_jp: #optional - children: - - name: - name_fr: #optional - name_jp: #optional - - name: - name_fr: #optional - url: "%lang%/" -- cgit 1.2.3-korg From 9e922d23f2b733ac47f9e433b8138b60161be4dc Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Wed, 5 Dec 2018 18:11:34 +0100 Subject: handle-doc: add a scheme into documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: I56e2c81f98c5cab1564fc5463154156c60aa0b71 Signed-off-by: Clément Bénier --- docs/handle-docs/handle-docs.md | 40 +++++++++++++++++++++++++++++++-- docs/handle-docs/pictures/workflow.odg | Bin 146638 -> 115915 bytes docs/handle-docs/pictures/workflow.png | Bin 244803 -> 206125 bytes 3 files changed, 38 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/handle-docs/handle-docs.md b/docs/handle-docs/handle-docs.md index c0ade95..9ecb421 100644 --- a/docs/handle-docs/handle-docs.md +++ b/docs/handle-docs/handle-docs.md @@ -5,7 +5,21 @@ A tool available in [docs-tools](https://github.com/automotive-grade-linux/docs- care of collecting and templating all markdown files according fetched_files.yml located in [docs-webtemplate](https://github.com/automotive-grade-linux/docs-webtemplate). - +See below a scheme of the workflow of agl documentation website generation. + +![alt text](pictures/workflow.png) + +As you can see, the section_``version``.yml contains the links to all the book yaml files, it is proceed to fetch all book yaml files from remote repositories to the docs-webtemplate. The book yaml files contains all the url to your markdown files from the remote repository. + +As soon as all the markdown files are fetched, the tools process to generate the AGL doc website. + +--- + +**Note:** + +The images described in markdown files are automatically fetched. For that, the necessary condition is that in markdown files, the relative path has to match with the location of images. + +--- ## How to add a new documentation section into AGL documentation @@ -30,7 +44,29 @@ among others : - subchapters list and consequently subchapters hierarchy - multi-language description - +--- + +**Note:** + +Multi-language is handled by key suffixes. That is to say, there are some keys that can be suffixed by a language: ``_`` +For the url to the markdown files, the prefix ```%lang%``` will match with suffixes. So, you have to create a subdirectory named ```%lang%``` where the markdown files are put. + +A example for the french: + +``` +name: "My section in english" +name_fr: "Ma section en français" +url: "%lang/section.md" +``` + +``` +$ ls -lR mydir +book.yml +section.md +fr/section.md +``` + +--- There are several types of book: diff --git a/docs/handle-docs/pictures/workflow.odg b/docs/handle-docs/pictures/workflow.odg index 24c59a4..c633359 100644 Binary files a/docs/handle-docs/pictures/workflow.odg and b/docs/handle-docs/pictures/workflow.odg differ diff --git a/docs/handle-docs/pictures/workflow.png b/docs/handle-docs/pictures/workflow.png index b5a39c7..75466e5 100644 Binary files a/docs/handle-docs/pictures/workflow.png and b/docs/handle-docs/pictures/workflow.png differ -- cgit 1.2.3-korg From d6cf0e129c521bc20dfa4e4b20b27f156bf86b31 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Wed, 13 Feb 2019 11:56:19 +0100 Subject: yml book: remove language from book MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: I3c3135465bb782ea3ba579118118b1594fd2825f Signed-off-by: Clément Bénier --- docs/signaling-book.yml | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) (limited to 'docs') diff --git a/docs/signaling-book.yml b/docs/signaling-book.yml index 1ac6d5c..aff6cec 100644 --- a/docs/signaling-book.yml +++ b/docs/signaling-book.yml @@ -1,15 +1,12 @@ type: books books: - - id: signaling - languages: - - language: en - title: Message Signaling - description: Message Signaling Description - keywords: - author: "IotBzh" - website: http:docs.iot.bzh - version: master - chapters: + id: signaling-docs-source + title: Message Signaling + description: Message Signaling Description + keywords: + author: "IotBzh" + version: master + chapters: - name: Message Signaling url: signaling/architecture.md -- cgit 1.2.3-korg From 3312c34c136d0cb864ad657b6570debdd39275b4 Mon Sep 17 00:00:00 2001 From: Sebastien Douheret Date: Thu, 20 Dec 2018 12:05:07 +0100 Subject: Remove useless reference to %lang% Change-Id: I91e0ef7a2eb09e841da43f917ea661cef0c06556 Signed-off-by: Sebastien Douheret --- docs/getting-started-book.yml | 49 +++++++++++++++++++++---------------------- 1 file changed, 24 insertions(+), 25 deletions(-) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index 0e18a75..b5fd31b 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -7,30 +7,29 @@ books: title_fr: Processus de génération d'une image description: keywords: - author: "IotBzh" - website: http:docs.iot.bzh + author: version: master chapters: - - url: "%lang%/getting-started/image-workflow-intro.md" + - url: "getting-started/image-workflow-intro.md" name: Overview name_fr: Vue d'ensemble - - url: "%lang%/getting-started/image-workflow-prep-host.md" + - url: "getting-started/image-workflow-prep-host.md" name: Preparing Your Build Host - - url: "%lang%/getting-started/image-workflow-download-sw.md" + - url: "getting-started/image-workflow-download-sw.md" name: Downloading AGL Software - - url: "%lang%/getting-started/image-workflow-initialize-build-environment.md" + - url: "getting-started/image-workflow-initialize-build-environment.md" name: Initializing Your Build Environment - - url: "%lang%/getting-started/image-workflow-cust-build.md" + - url: "getting-started/image-workflow-cust-build.md" name: Customizing Your Build - - url: "%lang%/getting-started/image-workflow-build.md" + - url: "getting-started/image-workflow-build.md" name: Building the AGL Image - - url: "%lang%/getting-started/machines/intel.md" + - url: "getting-started/machines/intel.md" name: Building for Most Intel 64-Bit Hardware Platforms - - url: "%lang%/getting-started/machines/qemu.md" + - url: "getting-started/machines/qemu.md" name: Building for Emulation - - url: "%lang%/getting-started/machines/R-Car-Starter-Kit-gen3.md" + - url: "getting-started/machines/R-Car-Starter-Kit-gen3.md" name: Build for R Car Starter Kit gen3 board - - url: "%lang%/getting-started/machines/raspberrypi.md" + - url: "getting-started/machines/raspberrypi.md" name: Build for Raspberry PI 2/3 - id: troubleshooting @@ -42,11 +41,11 @@ books: website: http:docs.iot.bzh version: master chapters: - - url: "%lang%/getting-started/troubleshooting.md" + - url: "getting-started/troubleshooting.md" name: Generic issues - - url: "%lang%/getting-started/footers/intel-footer.md" + - url: "getting-started/footers/intel-footer.md" name: Intel Boards - - url: "%lang%/getting-started/footers/raspberrypi-footer.md" + - url: "getting-started/footers/raspberrypi-footer.md" name: Raspberry PI - id: sdk @@ -58,7 +57,7 @@ books: website: http:docs.iot.bzh version: master chapters: - - url: "%lang%/getting-started/setup-sdk-environment.md" + - url: "getting-started/setup-sdk-environment.md" name: SDK Quick Setup - id: app-development-workflow @@ -70,22 +69,22 @@ books: website: http:docs.iot.bzh version: master chapters: - - url: "%lang%/getting-started/app-workflow-intro.md" + - url: "getting-started/app-workflow-intro.md" name: Overview - - url: "%lang%/getting-started/app-workflow-image.md" + - url: "getting-started/app-workflow-image.md" name: Download or Build Your Image - - url: "%lang%/getting-started/app-workflow-sdk.md" + - url: "getting-started/app-workflow-sdk.md" name: Download or Build Your SDK Installer - - url: "%lang%/getting-started/app-workflow-bootables.md" + - url: "getting-started/app-workflow-bootables.md" name: Create Bootable Media - - url: "%lang%/getting-started/app-workflow-boot.md" + - url: "getting-started/app-workflow-boot.md" name: Boot the Image on the Board - - url: "%lang%/getting-started/app-workflow-prep-app.md" + - url: "getting-started/app-workflow-prep-app.md" name: Get Ready to Create Your Application - - url: "%lang%/getting-started/app-workflow-build-app.md" + - url: "getting-started/app-workflow-build-app.md" name: Create and Build the Application - - url: "%lang%/getting-started/app-workflow-deploy-app.md" + - url: "getting-started/app-workflow-deploy-app.md" name: Deploy the Application to the Board - - url: "%lang%/getting-started/app-workflow-debug-app.md" + - url: "getting-started/app-workflow-debug-app.md" name: Debug the Application -- cgit 1.2.3-korg From 398b7ec40fe5ba507ea4d446f98eecde641807b8 Mon Sep 17 00:00:00 2001 From: Sebastien Douheret Date: Thu, 20 Dec 2018 13:58:13 +0100 Subject: Fix renesas.md filename and remove author Change-Id: I6e4335d71084b2af4157bcce0a14516a0912f107 Signed-off-by: Sebastien Douheret --- docs/getting-started-book.yml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index b5fd31b..fd18953 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -27,7 +27,7 @@ books: name: Building for Most Intel 64-Bit Hardware Platforms - url: "getting-started/machines/qemu.md" name: Building for Emulation - - url: "getting-started/machines/R-Car-Starter-Kit-gen3.md" + - url: "getting-started/machines/renesas.md" name: Build for R Car Starter Kit gen3 board - url: "getting-started/machines/raspberrypi.md" name: Build for Raspberry PI 2/3 @@ -37,8 +37,7 @@ books: title: Troubleshooting description: Troubleshooting Description keywords: - author: "IotBzh" - website: http:docs.iot.bzh + author: version: master chapters: - url: "getting-started/troubleshooting.md" @@ -53,7 +52,7 @@ books: title: SDK description: SDK Quick Setup keywords: - author: "IotBzh" + author: website: http:docs.iot.bzh version: master chapters: @@ -65,8 +64,7 @@ books: title: Application Development Workflow description: keywords: - author: "IotBzh" - website: http:docs.iot.bzh + author: version: master chapters: - url: "getting-started/app-workflow-intro.md" -- cgit 1.2.3-korg From 9a383952c0120f172fdde1827a451a37d9e4cfa4 Mon Sep 17 00:00:00 2001 From: Sebastien Douheret Date: Thu, 20 Dec 2018 16:09:16 +0100 Subject: Fix images link (markdown syntax) Change-Id: I22201168f30077f69abcbf46d753f75e0509b715 Signed-off-by: Sebastien Douheret --- docs/getting-started/app-workflow-intro.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/app-workflow-intro.md b/docs/getting-started/app-workflow-intro.md index 256e91f..063e486 100644 --- a/docs/getting-started/app-workflow-intro.md +++ b/docs/getting-started/app-workflow-intro.md @@ -14,7 +14,7 @@ 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. @@ -25,11 +25,10 @@ elsewhere. 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. + 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. - -- cgit 1.2.3-korg From 068a776161c774095f97d0a437459bf240e40b01 Mon Sep 17 00:00:00 2001 From: Frederic Marec Date: Fri, 21 Dec 2018 10:47:07 +0100 Subject: docs: add yaml book Bug-AGL: SPEC-1988 Signed-off-by: Frederic Marec --- docs/app-framework-book.yml | 12 ++++++++++++ docs/audio-book.yml | 14 ++++++++++++++ 2 files changed, 26 insertions(+) create mode 100644 docs/app-framework-book.yml create mode 100644 docs/audio-book.yml (limited to 'docs') diff --git a/docs/app-framework-book.yml b/docs/app-framework-book.yml new file mode 100644 index 0000000..662c2fd --- /dev/null +++ b/docs/app-framework-book.yml @@ -0,0 +1,12 @@ +type: books +books: +- + id: app-framework-docs-sources + title: App Framework + description: App Framework documentation + keywords: + author: "IotBzh" + version: master + chapters: + - url: app-framework/index.md + name: Resources diff --git a/docs/audio-book.yml b/docs/audio-book.yml new file mode 100644 index 0000000..6c5265e --- /dev/null +++ b/docs/audio-book.yml @@ -0,0 +1,14 @@ +type: books +books: +- + id: audio-docs-sources + title: Audio Docs Sources + description: Audio Docs Sources documentation + keywords: + author: "IotBzh" + version: master + chapters: + - url: audio/4a-framework.md + name: 4a-framework + - url: audio/bluez-alsa.md + name: bluez-alsa \ No newline at end of file -- cgit 1.2.3-korg From 4379ba7a6625fc47937c03a1aded2eb47dfe95ad Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Thu, 14 Feb 2019 10:23:55 +0100 Subject: books: fix hierarchical errors and add new one MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - add new one for hmi-framework Change-Id: Ie84fc486a505d7d5f3954cd54a32524b839b716d Signed-off-by: Clément Bénier --- docs/app-framework-book.yml | 2 +- docs/audio-book.yml | 4 +--- docs/hmi-framework-book.yml | 9 +++++++++ 3 files changed, 11 insertions(+), 4 deletions(-) create mode 100644 docs/hmi-framework-book.yml (limited to 'docs') diff --git a/docs/app-framework-book.yml b/docs/app-framework-book.yml index 662c2fd..385397d 100644 --- a/docs/app-framework-book.yml +++ b/docs/app-framework-book.yml @@ -2,7 +2,7 @@ type: books books: - id: app-framework-docs-sources - title: App Framework + title: Resources description: App Framework documentation keywords: author: "IotBzh" diff --git a/docs/audio-book.yml b/docs/audio-book.yml index 6c5265e..b1e7f83 100644 --- a/docs/audio-book.yml +++ b/docs/audio-book.yml @@ -2,13 +2,11 @@ type: books books: - id: audio-docs-sources - title: Audio Docs Sources + title: Audio Framework description: Audio Docs Sources documentation keywords: author: "IotBzh" version: master chapters: - - url: audio/4a-framework.md - name: 4a-framework - url: audio/bluez-alsa.md name: bluez-alsa \ No newline at end of file diff --git a/docs/hmi-framework-book.yml b/docs/hmi-framework-book.yml new file mode 100644 index 0000000..f10ef29 --- /dev/null +++ b/docs/hmi-framework-book.yml @@ -0,0 +1,9 @@ +type: books +books: +- + id: hmiframework-docs-source + title: HMI Framework + description: HMI Framework Description + keywords: + author: "IotBzh" + version: master -- cgit 1.2.3-korg From 933c81675ea2f0f5982f0864528425260479e445 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Sun, 24 Feb 2019 17:33:28 +0100 Subject: book for continuous integration MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: I39bd2c0b60619e773680d7884ca6a5a2007a6304 Signed-off-by: Clément Bénier --- docs/continuous-integration-book.yml | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 docs/continuous-integration-book.yml (limited to 'docs') diff --git a/docs/continuous-integration-book.yml b/docs/continuous-integration-book.yml new file mode 100644 index 0000000..a368e79 --- /dev/null +++ b/docs/continuous-integration-book.yml @@ -0,0 +1,9 @@ +type: books +books: +- + id: continuous-integration-docs-source + title: Continuous Integration - Automated Testing (CIAT) + description: Continuous Integration - Automated Testing (CIAT) + keywords: + author: "Ciat" + version: master -- cgit 1.2.3-korg From 1701ae9c3cc37139f36adc8116e37ebf68102caa Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Sun, 24 Feb 2019 18:56:50 +0100 Subject: getting started book: updated MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: Ia06214fb5209cf3456f3bba559685f8aefea061f Signed-off-by: Clément Bénier --- docs/getting-started-book.yml | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) (limited to 'docs') diff --git a/docs/getting-started-book.yml b/docs/getting-started-book.yml index fd18953..12b4b75 100644 --- a/docs/getting-started-book.yml +++ b/docs/getting-started-book.yml @@ -1,9 +1,20 @@ type: books books: +- + id: welcome-overview + order: 10 + title: "Welcome !" + description: + keywords: + author: + version: master + chapters: + - url: "getting-started/getting-started-welcome.md" + name: Overview - id: image-development-workflow order: 10 - title: Image Development Workflow + title: Developing an AGL Image title_fr: Processus de génération d'une image description: keywords: @@ -42,26 +53,21 @@ books: chapters: - url: "getting-started/troubleshooting.md" name: Generic issues - - url: "getting-started/footers/intel-footer.md" - name: Intel Boards - - url: "getting-started/footers/raspberrypi-footer.md" - name: Raspberry PI - - id: sdk + id: docker-container-setup order: 51 - title: SDK - description: SDK Quick Setup + title: Setting Up a Docker Container + description: setup docker container Description keywords: author: - website: http:docs.iot.bzh version: master chapters: - - url: "getting-started/setup-sdk-environment.md" - name: SDK Quick Setup + - url: "getting-started/docker-container-setup.md" + name: Overview - id: app-development-workflow order: 60 - title: Application Development Workflow + title: Developing an Application description: keywords: author: -- cgit 1.2.3-korg From 2b371e2b45e0a3139608caec65f3d68e01589b53 Mon Sep 17 00:00:00 2001 From: Clément Bénier Date: Sun, 24 Feb 2019 19:54:14 +0100 Subject: handle-docs-book: book for handling docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: I41c773681488f25811b8cf44a3b173291fb013c6 Signed-off-by: Clément Bénier --- docs/handle-docs-book.yml | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 docs/handle-docs-book.yml (limited to 'docs') diff --git a/docs/handle-docs-book.yml b/docs/handle-docs-book.yml new file mode 100644 index 0000000..34017a9 --- /dev/null +++ b/docs/handle-docs-book.yml @@ -0,0 +1,13 @@ +type: books +books: +- + id: handle-docs + title: "Add your documentation to AGL" + description: + keywords: + author: + version: master + chapters: + - url: "handle-docs/handle-docs.md" + name: Handle documentation + -- cgit 1.2.3-korg From 88faa299e5bd21cd64efeeed32c450b355fcd695 Mon Sep 17 00:00:00 2001 From: Sebastien Douheret Date: Thu, 20 Dec 2018 12:05:37 +0100 Subject: Add new book.yml for Security Blueprint Change-Id: I0565d1e9b668c4b493573692ad9f44b5c9548893 Signed-off-by: Sebastien Douheret --- docs/security-blueprint-book.yml | 116 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 docs/security-blueprint-book.yml (limited to 'docs') diff --git a/docs/security-blueprint-book.yml b/docs/security-blueprint-book.yml new file mode 100644 index 0000000..7b8bd62 --- /dev/null +++ b/docs/security-blueprint-book.yml @@ -0,0 +1,116 @@ +type: books +books: +- + id: security_blueprint + title: Security Blueprint + description: Identify areas that need to be addressed from a security perspective as part of Automotive Grade Linux (AGL) + keywords: Security + author: "IotBzh" + version: master + src_prefix: security-blueprint/ + chapters: + - name: Introduction + url: "README.md" + + - name: Part-1 Hardware + children: + - name: Introduction + url: "part-1/0_Abstract.md" + + - name: Part-2 Secure Boot + children: + - name: Introduction + url: "part-2/0_Abstract.md" + - name: Image + url: "part-2/1-Image.md" + - name: Communication modes + url: "part-2/2-Communication-modes.md" + - name: Consoles + url: "part-2/3-Consoles.md" + + - name: Part-3 Hypervisor + children: + - name: Introduction + url: "part-3/0_Abstract.md" + + - name: Part-4 Kernel + children: + - name: Introduction + url: "part-4/0_Abstract.md" + - name: General + url: "part-4/1-General.md" + - name: Memory + url: "part-4/2-Memory.md" + - name: Consoles + url: "part-4/3-Consoles.md" + - name: Debug + url: "part-4/4-Debug.md" + - name: File Systems + url: "part-4/5-FileSystems.md" + + - name: Part-5 Platform + children: + - name: Introduction + url: "part-5/0_Abstract.md" + - name: Mandatory Access Control + url: "part-5/1-MAC.md" + - name: SystemD + url: "part-5/2-SystemD.md" + - name: SystemBus + url: "part-5/3-SystemBus.md" + - name: System services and daemons + url: "part-5/4-Services.md" + - name: Application Framework + url: "part-5/5-AppFw.md" + - name: Utilities + url: "part-5/6-Utilities.md" + - name: Users + url: "part-5/7-Users.md" + + - name: Part-6 Application + children: + - name: Introduction + url: "part-6/0_Abstract.md" + - name: Installation + url: "part-6/1-Installation.md" + - name: Privilege management + url: "part-6/2-PrivilegeManagement.md" + - name: Signature + url: "part-6/3-Signature.md" + - name: Services + url: "part-6/4-Services.md" + + - name: Part-7 Connectivity + children: + - name: Introduction + url: "part-7/0_Abstract.md" + - name: Bus and connectors + url: "part-7/1-BusAndConnectors.md" + - name: Wireless + url: "part-7/2-Wireless.md" + - name: Cloud + url: "part-7/3-Cloud.md" + + - name: Part-8 Update + children: + - name: Introduction + url: "part-8/0_Abstract.md" + - name: FOTA + url: "part-8/1-FOTA.md" + - name: SOTA + url: "part-8/2-SOTA.md" + + - name: Part-9 Secure development + children: + - name: Introduction + url: "part-9/0_Abstract.md" + + - name: Annexes + children: + - name: Annexes + url: "annexes/0_Abstract.md" + - name: Config notes + url: "annexes/ConfigNotes.md" + - name: Todo notes + url: "annexes/todoNotes.md" + -- cgit 1.2.3-korg From 721ae64bff54b1213835322cdd5dc2903af032d3 Mon Sep 17 00:00:00 2001 From: "ronan [iot.bzh]" Date: Tue, 19 Mar 2019 15:40:56 +0100 Subject: Update RCAR BSP version on AGL --- docs/getting-started/machines/renesas.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index c3943bc..7fc8309 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -137,7 +137,8 @@ Follow these steps to download the drivers you need: | AGL Version| Renesas version | |:-:|:-:| - | AGL master | 3.9.0 | + | AGL master | 3.15.0 | + | AGL 7.0.0 | 3.9.0 | | AGL 6.0.0 | 3.7.0 | | AGL 5.0.x, 5.1.0| 2.23.1 | | AGL 4.0.x |2.19.0 | -- cgit 1.2.3-korg From 56b6ac542c76117300b05b0982f49f65cf9583e5 Mon Sep 17 00:00:00 2001 From: Pierre Marzin Date: Tue, 19 Mar 2019 10:08:45 +0100 Subject: R-Car build: Fix broken links --- docs/getting-started/machines/renesas.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index 7fc8309..37db7c5 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -24,16 +24,16 @@ You can find more information on building images from these resources: This following list looks a bit dated. Do we want to update these PDFs or are they still useful? -* [AGL-Devkit-Build-your-1st-AGL-Application.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf) +* [AGL-Devkit-Build-your-1st-AGL-Application.pdf](https://iot.bzh/download/public/2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf) Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. This is really about building an application and not the AGL image. -* [AGL-Devkit-HowTo_bake_a_service.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf) +* [AGL-Devkit-HowTo_bake_a_service.pdf](https://iot.bzh/download/public/2016/bsp/AGL_Phase2-Devkit-HowTo_bake_a_service.pdf) Generic guide on how to add a new service in the BSP. Goes back to 2015 and uses Yocto 2.x. Includes stuff on building an image but looks like the focus is really the service. -* [AGL-Kickstart-on-Renesas-Porter-Board.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf) +* [AGL-Kickstart-on-Renesas-Porter-Board.pdf](https://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf) Guide on how to build an image for the Porter Board using AGL 2.0. -* [AGL-Devkit-Image-and-SDK-for-Porter.pdf](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf) +* [AGL-Devkit-Image-and-SDK-for-Porter.pdf](https://iot.bzh/download/public/2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf) Guide on building an AGL image and SDK for the Porter board. Uses Yocto 2.x. -- cgit 1.2.3-korg From 783118feba54a67127d55959fe7cf2ab1a2d739b Mon Sep 17 00:00:00 2001 From: Pierre MARZIN Date: Tue, 19 Mar 2019 12:08:27 +0100 Subject: getting-started: Fix some errors image-workflow-intro.md: Correct image link image-workflow-build.md: Fix broken links --- docs/getting-started/image-workflow-build.md | 8 ++++---- docs/getting-started/image-workflow-intro.md | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/image-workflow-build.md b/docs/getting-started/image-workflow-build.md index 0e28e25..13f542f 100644 --- a/docs/getting-started/image-workflow-build.md +++ b/docs/getting-started/image-workflow-build.md @@ -12,7 +12,7 @@ This section, provides links to topics with instructions needed to create images three types of supported platforms and for emulation using Quick EMUlator (QEMU) or VirtualBox: -* [Most Intel-based 64-Bit Boards](./machines/intel.html/) -* [Emulation](./machines/qemu.html/) -* [R Car Starter Kit Gen3 Board](./machines/renesas.html/) -* [Raspberry PI 2 or 3](./machines/raspberrypi.html/) +* [Most Intel-based 64-Bit Boards](./machines/intel.html) +* [Emulation](./machines/qemu.html) +* [R Car Starter Kit Gen3 Board](./machines/renesas.html) +* [Raspberry PI 2 or 3](./machines/raspberrypi.html) diff --git a/docs/getting-started/image-workflow-intro.md b/docs/getting-started/image-workflow-intro.md index ad36d01..393a9f5 100644 --- a/docs/getting-started/image-workflow-intro.md +++ b/docs/getting-started/image-workflow-intro.md @@ -16,9 +16,9 @@ in the AGL Documentation set. Links are provided when a set of steps is required that is documented elsewhere. -
+![](images/image-developer-workflow.png){:: style="margin:auto; display:flex"} -1. Prepare your build host to use use the tools needed to build your image. +1. Prepare your build host to be able to use the tools needed to build your image. 2. Download the AGL software into a local Git repository on your build host. -- cgit 1.2.3-korg From 711115e4ee564baabd18d3e53e670c07e5234b41 Mon Sep 17 00:00:00 2001 From: Pierre MARZIN Date: Tue, 19 Mar 2019 15:38:39 +0100 Subject: R-Car Build: Update build doc --- docs/getting-started/machines/renesas.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index 37db7c5..8660e20 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -61,7 +61,7 @@ Follow these steps to download the drivers you need: 4:ZIP_2="R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston2-20170904.zip" ``` - The script's output identifies the files you need to download from the page. + The script's output identifies the files you need to download from the page and the example above correspond to the Electric Eel AGL revision (v5.0.0). Note that since Flounder AGL revision (v6.0.0), both zip have been renamed. 2. **Find the Download Links:** @@ -139,7 +139,8 @@ Follow these steps to download the drivers you need: |:-:|:-:| | AGL master | 3.15.0 | | AGL 7.0.0 | 3.9.0 | - | AGL 6.0.0 | 3.7.0 | + | AGL 6.0.3, 6.0.4 | 3.9.0 | + | AGL 6.0.0, 6.0.1, 6.0.2 | 3.7.0 | | AGL 5.0.x, 5.1.0| 2.23.1 | | AGL 4.0.x |2.19.0 | @@ -390,8 +391,8 @@ Follow these steps to update the firmware: You only need to make these updates one time per device. Follow the procedure found on the - [eLinux.org wiki][R-car loader update] to update to at least version 3.02, - which is mandatory to run the AGL image. + eLinux.org wiki to update to at least version 3.02, + which is mandatory to run the AGL image ([R-car loader update](https://elinux.org/R-Car/Boards/Kingfisher#How_to_update_of_Sample_Loader_and_MiniMonitor)). 2. **Update the Firmware Stack:** @@ -402,8 +403,8 @@ Follow these steps to update the firmware: As such, they have a firmware stack that is divided across: **ARM Trusted Firmware**, **OP-Tee** and **U-Boot**. If you are using the Eel (5.0) version or later of the AGL software, you must update - the firmware using the **[h3ulcb][R-car h3ulcb firmware update]** - or **[m3ulcb][R-car m3ulcb firmware update]** links from the + the firmware using the **[h3ulcb][R-car h3ulcb firmware update](http://elinux.org/R-Car/Boards/H3SK#Flashing_firmware)** + or **[m3ulcb][R-car m3ulcb firmware update](https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware)** links from the [Embedded Linux Wiki](https://www.elinux.org/Main_Page) (i.e. `elinux.org`). The table in the wiki lists the files you need to flash the firmware. -- cgit 1.2.3-korg From 06fa1ddb4be912b76a2df88137d753ea4968d5bd Mon Sep 17 00:00:00 2001 From: Pierre MARZIN Date: Tue, 19 Mar 2019 17:01:08 +0100 Subject: getting-started: machines: Fix broken links --- docs/getting-started/machines/intel.md | 8 ++++---- docs/getting-started/machines/qemu.md | 2 +- docs/getting-started/machines/raspberrypi.md | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md index 2a7eddb..bd55fdc 100644 --- a/docs/getting-started/machines/intel.md +++ b/docs/getting-started/machines/intel.md @@ -5,13 +5,13 @@ you can use the information found on the "[MinnowBoard wiki](https://minnowboard to enable most 64-bit Intel Architecture (IA) platforms that use the 64-bit UEFI as the boot loader. In addition to the MinnowBoard, support for the -[upCore & UpSquared boards](http://www.up-board.org/upsquared/) exists. +[upCore & UpSquared boards](http://up-board.org/upsquared/specifications/) exists. MinnowBoard Max and Turbot are both 64-bit capable. If you are interested in creating ***applications*** to run on hardware booted using an image built with the AGL Project, see the following: -* [Application Development Workflow](../app-workflow-intro.html/overview) +* [Application Development Workflow](../app-workflow-intro.html) * [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps) UEFI has significantly evolved and you should check that your hardware's @@ -35,7 +35,7 @@ platforms: ## 1. Making Sure Your Build Environment is Correct The -"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html)" section presented generic information for setting up your build environment using the `aglsetup.sh` script. If you are building for an Intel 64-bit platform, you need to specify some @@ -200,7 +200,7 @@ To do so, requires the following steps: 2. **Rebuild Your Image** Rebuild the AGL image by following the instructions in the - "[Using BitBake](./machines/intel.html#using-bitbake)" + "[Using BitBake](../machines/intel.html#2-using-bitbake)" step of this page. 3. **Install the Rebuilt Image Onto a Removable Device** diff --git a/docs/getting-started/machines/qemu.md b/docs/getting-started/machines/qemu.md index f7e837d..459725e 100644 --- a/docs/getting-started/machines/qemu.md +++ b/docs/getting-started/machines/qemu.md @@ -10,7 +10,7 @@ VirtualBox. ## 1. Making Sure Your Build Environment is Correct The -"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html)" section presented generic information for setting up your build environment using the `aglsetup.sh` script. If you are building the AGL demo image for emulation, you need to specify some diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md index ce9337c..76e3929 100644 --- a/docs/getting-started/machines/raspberrypi.md +++ b/docs/getting-started/machines/raspberrypi.md @@ -16,7 +16,7 @@ AGL demo image for both the Raspberry PI 2 and 3 boards. ## 1. Making Sure Your Build Environment is Correct The -"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html/Initializing-your-build-environment)" +"[Initializing Your Build Environment](../image-workflow-initialize-build-environment.html)" section presented generic information for setting up your build environment using the `aglsetup.sh` script. If you are building the AGL demo image for a Raspberry PI board, you need to specify some @@ -44,7 +44,7 @@ $ source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-a Before launching the build, it is good to be sure your build configuration is set up correctly (`/build/conf/local.conf` file). The -"[Customizing Your Build](./image-workflow-cust-build.html)" +"[Customizing Your Build](../image-workflow-cust-build.html)" section highlights some common configurations that are useful when building any AGL image. -- cgit 1.2.3-korg From 10db36254b03a648a9534b936fc61196a139afc0 Mon Sep 17 00:00:00 2001 From: Pierre MARZIN Date: Fri, 22 Mar 2019 17:53:39 +0100 Subject: getting-started: Add new titles to improve reading --- docs/getting-started/machines/renesas.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index 8660e20..fc1d57e 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -667,7 +667,7 @@ Net: ravb Hit any key to stop autoboot: 0 => ``` - +## 9. Setting-up U-boot ### Configuring U-Boot Parameters Follow these steps to configure the board to use the MicroSD card as the @@ -773,7 +773,7 @@ boot device and also to set the screen resolution: ``` run bootcmd ``` - +## 10. Troubleshooting ### Logging Into the Console Once the board boots, you should see the @@ -836,3 +836,5 @@ VERSION="3.0.0+snapshot-20161202 (chinook)" VERSION_ID="3.0.0-snapshot-20161202" PRETTY_NAME="Automotive Grade Linux 3.0.0+snapshot-20161202 (chinook)" ``` + +**NOTE:** More generics troubleshooting can be found here : [Generic issues](../troubleshooting.html) -- cgit 1.2.3-korg From bb997cda4aaaf2c41cb2a83bdabb6b9539221bbf Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 28 Mar 2019 08:23:45 -0700 Subject: Removed WRITER'S NOTES. I took out some remaining WRITER'S NOTES from four of the *.md files. Signed-off-by: Scott Rifenbark --- docs/getting-started/docker-container-setup.md | 2 -- docs/getting-started/machines/intel.md | 2 -- docs/getting-started/machines/renesas.md | 4 ---- docs/getting-started/troubleshooting.md | 28 +------------------------- 4 files changed, 1 insertion(+), 35 deletions(-) (limited to 'docs') diff --git a/docs/getting-started/docker-container-setup.md b/docs/getting-started/docker-container-setup.md index d984e5f..48df10a 100644 --- a/docs/getting-started/docker-container-setup.md +++ b/docs/getting-started/docker-container-setup.md @@ -192,8 +192,6 @@ based on the AGL Worker image: **NOTE:** The password for the ID "devel" inside the docker image is "devel". -**WRITER NOTE:** I need to do this and see what this output really looks like. - ```bash $ git clone https://git.automotivelinux.org/AGL/docker-worker-generator $ cd docker-worker-generator diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md index bd55fdc..3658408 100644 --- a/docs/getting-started/machines/intel.md +++ b/docs/getting-started/machines/intel.md @@ -88,8 +88,6 @@ The build process puts the resulting image in the Build Directory: /tmp/deploy/images/intel-corei7-64/ ``` -**WRITER NOTE:** I am not sure what to do with the following information: - An alternative method for building an image is to use the AGL SDK delivered in a Docker container. There is currently no SDK dedicated to IA but the SDK provided for the Porter Board can build an IA image without changes (just `aglsetup.sh` needs to call for Intel). diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md index fc1d57e..895fe19 100644 --- a/docs/getting-started/machines/renesas.md +++ b/docs/getting-started/machines/renesas.md @@ -20,10 +20,6 @@ Renesas development kits. You can find more information on building images from these resources: -**WRITER NOTE:** -This following list looks a bit dated. -Do we want to update these PDFs or are they still useful? - * [AGL-Devkit-Build-your-1st-AGL-Application.pdf](https://iot.bzh/download/public/2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf) Generic guide on how to build various application types (HTML5, native, Qt, QML, …) for AGL. This is really about building an application and not the AGL image. diff --git a/docs/getting-started/troubleshooting.md b/docs/getting-started/troubleshooting.md index ea3aba1..90c1fae 100644 --- a/docs/getting-started/troubleshooting.md +++ b/docs/getting-started/troubleshooting.md @@ -1,12 +1,6 @@ # Troubleshooting -**WRITER'S NOTE:** This content needs a new home. - Most likely it will be in some "how-to" area as most of the information - fits that category. - For now, I am leaving it here. - The other two board-specific troubleshooting sections have been merged - into their respective build topics in the section describing how to - build an AGL image. +This topic describes various areas that could cause you problems. ## Including Extended Attributes @@ -58,26 +52,6 @@ However, if you do, you must take these steps to copy `xattrs` to the media: --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz ``` - - ## Screen orientation for Splash and in Weston Depending of your scren mounting the default orientation of the UI an/or splash screen might be incorrect. -- cgit 1.2.3-korg