Merge remote-tracking branch 'origin/master-next'

Change-Id: Ifda0fa9a9940d056f72bcad0ea94821face3685d

5 files changed, 1460 insertions, 203 deletions

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
--- /dev/null
+++ b/docs/getting-started/machines/images/RaspberryPi2-ModelB-debug-serial-cable.png
diff --git a/docs/getting-started/machines/intel.md b/docs/getting-started/machines/intel.md
index 34957a8..3658408 100644
--- a/docs/getting-started/machines/intel.md
+++ b/docs/getting-started/machines/intel.md
@@ -1,186 +1,354 @@
-# Running AGL on Intel MinnowBoard (and most Intel 64 bits HW)
+# Building for Most Intel 64-Bit Hardware Platforms
 
-## Scope
+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://up-board.org/upsquared/specifications/) exists.
+MinnowBoard Max and Turbot are both 64-bit capable.
 
-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.
-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:
 
-**Note**: This page is more focused on those who want to create bespoke AGL images and BSPs.
+* [Application Development Workflow](../app-workflow-intro.html)
+* [Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps)
 
-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 significantly evolved and you should check that your hardware's
+firmware is up-to-date.
+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:
 
-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)
+* Intel automotive Module Reference Board (MRB)
 
-[`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)
+  **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.
 
-## Where to find an AGL bootable image
 
-### Download a ready made image
+## 1. Making Sure Your Build Environment is Correct
 
-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
+The
+"[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
+specific options when you run the script:
 
-### 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.
+```bash
+$ source meta-agl/scripts/aglsetup.sh \
+    -m intel-corei7-64 \
+    agl-devel agl-demo agl-appfw-smack agl-netboot agl-audio-4a-framework
+```
 
-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).
+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.
 
-See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf "wikilink").
+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.
 
-#### Download AGL source code
+## 2. Using BitBake
 
-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").
+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).
 
-To install the `repo` tool:
+For supported Intel images, the filenames have the following form:
 
-```bash
-  mkdir -p ~/bin;
-  export PATH=~/bin:$PATH;
-  curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo;
-  chmod a+x ~/bin/repo;
 ```
+<release-name>/<release-number>/intel-core17-64/deploy/images/intel-core17-64/bzImage-intel-corei7-64.bin
+```
+
+Start the build using the `bitbake` command.
 
-#### Configuring for the current *(older)* stable (Electric Eel 5.0.x)
+**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
-  cd AGL-5.0.x;
-  repo init -b eel -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+  bitbake agl-demo-platform
 ```
 
-#### Configuring for master (DD)
+The build process puts the resulting image in the Build Directory:
 
-```bash
-  cd AGL-master;
-  repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo;
+```
+<build_directory>/tmp/deploy/images/intel-corei7-64/
 ```
 
-Once that you repo is initialised either with the stable or WIP, you need to sync the repo to fetch the various git trees.
+An alternative method for building an image is to use the AGL SDK delivered in a Docker container.
 
-#### Downloading the configured AGL source code
+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).
 
-```bash
-  repo sync;
-```
+See chapter 2 of [Porter QuickStart](http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf "wikilink").
 
-#### Building the AGL distro
+## 3. Creating Bootable Media
+
+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.
+
+When creating bootable media,
+[Extended Attributes (`xattrs`)](https://linux-audit.com/using-xattrs-extended-attributes-on-linux/)
+are required for use with
+[Smack](https://en.wikipedia.org/wiki/Smack_(software)).
+This section describes using the `mkabl-agl.sh` or `mkefi-agl.sh` scripts
+to create bootable media.
+Use of either of these scripts include all required `xattrs`.
+
+**NOTE:** You can find detailed information on Smack at
+  [https://www.kernel.org/doc/Documentation/security/Smack.txt](https://www.kernel.org/doc/Documentation/security/Smack.txt).
+
+While the `mkabl-agl.sh` or `mkefi-agl.sh` scripts are recommended for creating
+your bootable media for Intel devices, other methods exist.
+If you use an alternative method (e.g. `tar`), be sure you take steps to copy
+`xattrs` as part of the image.
+See the
+"[Including Extended Attributes](../troubleshooting.html#including-extended-attributes)"
+section for more information.
+
+### 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.
 
-You are now ready to initialise your Yocto build.
-When running the command:
+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.
 
-```bash
-  source meta-agl/scripts/aglsetup.sh -h
-```
+**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.
 
-You will notice the Intel entries
+Follow these steps to create your bootable media:
 
-```bash
-  intel-corei7-64
-  joule
-```
+1. **Insert Media Device:**
+   Insert your removable media into the corresponding interface.
 
-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
+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.
 
-```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
-```
+   ```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)
+   ```
 
-**Note:** use the option "-m joule" when building for a Joule developer Kit target.
+3. **Download the `mkefi-agl.sh` Script:**
+   You can find the script in the "meta-agl/scripts" folder of your AGL source files.
 
-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**
+   Alternatively, you can download the script from the following Git repository:
 
-```bash
-  bitbake agl-demo-platform
-```
+   [https://github.com/dominig/mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh)
 
-**Your newly baked disk image (.wic.xz) will be located at**:
-  `tmp/deploy/images/intel-corei7-64/`
+4. **Create Your Bootable Media:**
+   Run the following to see `mkefi-agl.sh` usage information:
 
-##### Alternative: Download a *ready made* image from AGL web site
+   ```bash
+     ./mkefi-agl.sh -v
+   ```
 
-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).
+   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`:
 
-Once you have validated your process you can start to play/work with the snapshot pointer.
+   ```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.
+   ```
 
-Note that snapshot build may not work.
+### Embedded MultiMediaCard (eMMC)
 
-Follow the directory:
+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:
 
-`intel-corei7-64/deploy/images/intel-corei7-64/`
+1. **Add Required Tools to Your AGL Image:**
 
-and download the file:
+   Add a file named `site.conf` in your `build/conf` directory.
+   Make sure the file has the following content:
 
-`agl-demo-platform-intel-corei7-64.hddimg`
+   ```
+   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.
 
-## Create a bootable media
+2. **Rebuild Your Image**
 
-Depending your target HW 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.
+   Rebuild the AGL image by following the instructions in the
+   "[Using BitBake](../machines/intel.html#2-using-bitbake)"
+   step of this page.
 
-### Insert you removable media in the corresponding interface
+3. **Install the Rebuilt Image Onto a Removable Device**
 
-### Check the device name where the media can be accessed with the command
+   Follow the steps previously described here to copy the new
+   image onto a removable device such as a USB stick.
 
-```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)
-```
+4. **Copy the Image from the USB Stick to Your Build Host's Home Directory**
 
-### Download the script `mkefi-agl.sh`
+   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:
 
-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)
+   ```bash
+   $ cp build/tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic.xz ~/
+   ```
 
-Alternatively you can download it from the following Git repo:
+5. **Boot the AGL Image from the Removable Device**
 
-[https://github.com/dominig/mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh)
+   You can see how to boot the image on the target device by
+   following the procedure in the next section.
 
-### check the available options
+6. **Connect to Your Device that is Running the Image**
 
-```bash
-  sh mkefi-agl.sh -v;
-```
+   You need to use a Serial Link or SSH to connect to the device running
+   your image.
 
-### create your media with the command adjusted to your configuration
+7. **Determine the eMMC Device Name**
 
-```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
-```
+   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
+
+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.
 
-## Boot the image on the target device
+Use these steps to boot your device:
 
-1. Insert the created media with the AGL image in the target device
+1. Insert the bootable media that contains the AGL image into the target device.
 
-1. Power on the device
+2. Power on the device.
 
-1. Select Change one off boot option (generally F12 key during power up)
+3. As the device boots, access the boot option screen.
+   You generally accomplish this with the F12 key during the power up operation.
 
-1. Select your removable device
+   **NOTE:** When booting a MinnowBoard, you can change the default boot
+   device by hitting F2 during initial UEFI boot.
 
-1. Let AGL boot
+4. From the boot option screen, select your bootable media device.
 
-**Note:**: depending on the speed of the removable media, the first boot may not complete, in that case simply reboot the device.
+5. Save and exit the screen and let the device boot from your media.
+
+   **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.
+
+   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
+```
 
-This is quite common with USB2 sticks.
+**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`.
 
-By default the serial console is configured and activated at the rate of 115200 bps.
+Common Display names for Intel platforms are the following:
 
-## How to create your 1st AGL application
+* `HDMI-A-1`
+* `HDMI-A-2`
+* `LVDS-1`
 
-[Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps)
diff --git a/docs/getting-started/machines/qemu.md b/docs/getting-started/machines/qemu.md
index 7bd14c0..459725e 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)"
+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:
+
+```
+<release-name>/<release-number>/qemuarm/*
+<release-name>/<release-number>/qemuarm64/*
+<release-name>/<release-number>/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
+```
+<build_directory>/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**
diff --git a/docs/getting-started/machines/raspberrypi.md b/docs/getting-started/machines/raspberrypi.md
index e016584..76e3929 100644
--- a/docs/getting-started/machines/raspberrypi.md
+++ b/docs/getting-started/machines/raspberrypi.md
@@ -1,39 +1,270 @@
-# 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)"
+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 3**:
+
+```bash
+$ source meta-agl/scripts/aglsetup.sh -m raspberrypi3 agl-demo agl-netboot agl-appfw-smack
+```
+
+## 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.
+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:
+
 ```
+<release-name>/<release-number>/raspberrypi3/deploy/images/raspberrypi3/*
+```
+
 
-## Raspberry Pi 2
+Start the build using the `bitbake` command.
 
-To build AGL demo platform for Raspberry Pi 2 use machine **raspberrypi2** and feature **agl-demo**:
+**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
-source meta-agl/scripts/aglsetup.sh -m raspberrypi2 agl-demo agl-netboot agl-appfw-smack
-bitbake agl-demo-platform
+$ bitbake agl-demo-platform
 ```
 
-## Booting AGL Demo Platform on Raspberry Pi
+By default, the build process puts the resulting image in the Build Directory.
+Here is example for the Raspberry PI 3 board:
+
+```
+<build_directory>/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.
+
+## 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.
+
+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.
 
-Follow the steps below to copy the image to microSD card and to boot it on Raspberry Pi 2 or 3:
+   Use the `dmesg` command as follows to discover the device name:
 
-* 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:
+   ```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
+   ```
 
-*Note: the sdimage files can also be named rpi-sdimg-ota in case you have the **"agl-sota"** feature enabled*
+   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 <sdcard_device_name>
+   $ xzcat <image_name> | sudo dd of=<sdcard_device_name> bs=4M
+   $ sync
+   ```
+
+4. Plug your MicroSD card into the Raspberry PI board and boot the device.
+
+## 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/),
+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
-sudo umount [sdcard device]
-xzcat [output image] | sudo dd of=[sdcard device] bs=4M
-sync
+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
 ```
 
-* Plug your microSD card into Raspberry Pi 2 or 3 and boot the board
+## 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:
+
+<p align="center">
+  <img src="./images/RaspberryPi2-ModelB-debug-serial-cable.png">
+</p>
+
+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
+   ```
diff --git a/docs/getting-started/machines/renesas.md b/docs/getting-started/machines/renesas.md
new file mode 100644
index 0000000..895fe19
--- /dev/null
+++ b/docs/getting-started/machines/renesas.md
@@ -0,0 +1,836 @@
+# 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.
+
+You can find more information on building images from these resources:
+
+* [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](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](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](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.
+
+
+## 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)
+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 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:**
+
+   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.15.0 |
+     | AGL 7.0.0  | 3.9.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 |
+
+   **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.
+   * 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.
+   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:**
+
+   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:
+
+   ```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.
+
+   Here is another 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:
+   <https://www.renesas.com/us/en/solutions/automotive/rcar-download/rcar-demoboard-2.html>
+
+   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
+
+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.
+
+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
+```
+
+Depending on the Renesas board you are using, you should see output
+as follows:
+
+```bash
+  MACHINE = "h3ulcb"
+```
+or
+```bash
+  MACHINE = "m3ulcb"
+```
+or
+```bash
+  MACHINE = "h3-salvator-x"
+```
+
+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:
+
+```
+<release-name>/<release-number>/m3ulcb-nogfx/deploy/images/m3ulcb/Image-m3ulcb.bin
+```
+
+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
+```
+
+The build process puts the resulting image in the Build Directory:
+
+```
+<build_directory>/tmp/deploy/images/$MACHINE
+```
+
+## 7. Booting the Image Using a MicroSD Card
+
+To boot your image on the Renesas board, you need to do three things:
+
+1. Update all firmware on the board.
+2. Prepare the MicroSD card to you can boot from it.
+3. Boot the board.
+
+**NOTE:** For subsequent builds, you only have to re-write the MicroSD
+card with a new image.
+
+### Updating the Board's Firmware
+
+Follow these steps to update the firmware:
+
+1. **Update the Sample Loader and MiniMonitor:**
+
+   You only need to make these updates one time per device.
+
+   Follow the procedure found on the
+   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:**
+
+   You only need to update the firmware stack if you are
+   using the Eel or later (5.0) version of AGL software.
+
+   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 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](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.
+   You can find these files in the following directory:
+
+   ```bash
+   $AGL_TOP/build/tmp/deploy/images/$MACHINE
+   ```
+
+   **NOTE:** The Salvator-X firmware update process is not documented on eLinux.
+
+### Preparing the MicroSD Card
+
+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 -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.
+
+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.
+
+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.
+
+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
+```
+
+Alternatively, you can leave the image in an uncompressed state and write it
+to the MicroSD card:
+
+```bash
+  sudo umount /dev/sdc
+  xzcat ./agl-demo-platform-$MACHINE.wic.xz | sudo dd of=$SDCARD bs=4M
+  sync
+```
+
+### 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.
+
+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.
+
+## 8. Setting Up the Serial Console
+
+Setting up the Serial Console involves the following:
+
+* 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
+
+### Installing a Serial Client on Your Build Host
+
+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).
+
+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 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
+[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 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
+```
+
+or
+
+```bash
+$ minicom -b 115200 -D /dev/ttyUSB0
+```
+
+or
+
+```bash
+$ screen /dev/ttyUSB0 115200
+```
+
+### 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.
+
+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
+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
+=>
+```
+
+**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
+=>
+```
+## 9. Setting-up U-boot
+### Configuring U-Boot Parameters
+
+Follow these steps to configure the board to use the MicroSD card as the
+boot device and also to set the screen resolution:
+
+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.
+
+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:
+
+   ```
+   => 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
+   ```
+
+   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
+   ```
+
+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
+    setenv bootcmd run load_ker\; run load_dtb\; booti 0x48080000 - 0x48000000
+    setenv load_ker ext4load mmc 0:1 0x48080000 /boot/Image
+    ```
+
+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
+    ```
+
+    **h3ulcb with BSP version less than 2.19**:
+
+    ```
+    setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-h3ulcb.dtb
+    ```
+
+    **m3ulcb**:
+
+    ```bash
+    setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb.dtb
+    ```
+
+    **m3ulcb with a Kingfisher board**:
+
+    ```bash
+    setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7796-m3ulcb-kf.dtb
+    ```
+
+    **h3ulcb with a Kingfisher board**:
+
+    ```bash
+    setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/Image-r8a7795-es1-h3ulcb-kf.dtb
+    ```
+
+5. Save the boot environment:
+
+    ```bash
+    saveenv
+    ```
+
+6. Boot the board:
+
+```
+run bootcmd
+```
+## 10. Troubleshooting
+### Logging Into the Console
+
+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:
+
+**h3ulcb**:
+
+```bash
+Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0
+
+h3ulcb login: root
+```
+
+**m3ulcb**:
+
+```bash
+Automotive Grade Linux ${AGL_VERSION} m3ulcb ttySC0
+
+m3ulcb login: root
+```
+
+At the prompt, login by using `root` as the login.
+The password is "empty" so you should not be prompted for the password.
+
+### Determining the Board's IP Address
+
+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`.
+
+Here is an example for the **m3ulcb** board:
+
+```bash
+m3ulcb login: root
+Last login: Tue Dec  6 09:55:15 UTC 2016 on tty2
+root@m3ulcb:~# ip -4 a
+1: lo: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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:~#
+```
+
+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
+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)"
+```
+
+**NOTE:** More generics troubleshooting can be found here : [Generic issues](../troubleshooting.html)