diff options
Diffstat (limited to 'docs/01_Getting_Started/02_Building_AGL_Image')
17 files changed, 2132 insertions, 0 deletions
diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/01_Build_Process_Overview.md b/docs/01_Getting_Started/02_Building_AGL_Image/01_Build_Process_Overview.md new file mode 100644 index 0000000..f1a48c7 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/01_Build_Process_Overview.md @@ -0,0 +1,33 @@ +--- +title: Build Process 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 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. + +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://docs.yoctoproject.org/bitbake.html) + to build your image. diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/02_Preparing_Your_Build_Host.md b/docs/01_Getting_Started/02_Building_AGL_Image/02_Preparing_Your_Build_Host.md new file mode 100644 index 0000000..846271f --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/02_Preparing_Your_Build_Host.md @@ -0,0 +1,67 @@ +--- +title: 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://docs.yoctoproject.org/bitbake.html). + +This section presents minimal information so you can prepare the build host +to use the "Dunfell" version of the Yocto Project (i.e. version 3.1.2). +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](https://download.automotivelinux.org/AGL/snapshots/master/latest/) exist for several boards as +well as for the Quick EMUlator (QEMU). +See the +"[Quickstart](../01_Quickstart/01_Using_Ready_Made_Images.md)" +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://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions)" + section in the Yocto Project Reference Manual. + Basically, you should be running a recent version of Ubuntu, Fedora, openSUSE, + CentOS, or Debian. + +2. **Be Sure Your Build Host Has Enough Free Disk Space:** + Your build host should have at least 100 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://docs.yoctoproject.org/ref-manual/system-requirements.html#required-git-tar-python-and-gcc-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://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host)" + 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://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host)" + 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/01_Getting_Started/02_Building_AGL_Image/03_Downloading_AGL_Software.md b/docs/01_Getting_Started/02_Building_AGL_Image/03_Downloading_AGL_Software.md new file mode 100644 index 0000000..02d9108 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/03_Downloading_AGL_Software.md @@ -0,0 +1,102 @@ +--- +title: 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. + +**NOTE:** Further information about Download and Build AGL Source Code available at [AGL wiki](https://wiki.automotivelinux.org/agl-distro/source-code). + +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": + + ```sh + $ export AGL_TOP=$HOME/AGL + $ echo 'export AGL_TOP=$HOME/AGL' >> $HOME/.bashrc + $ 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: + + ```sh + $ mkdir -p $HOME/bin + $ export PATH=$HOME/bin:$PATH + $ echo 'export PATH=$HOME/bin:$PATH' >> $HOME/.bashrc + $ curl https://storage.googleapis.com/git-repo-downloads/repo > $HOME/bin/repo + $ chmod a+x $HOME/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](https://wiki.automotivelinux.org/agl-distro/release-notes#latest_stable_release), use + the following commands: + + **Note:** In this below command please change the branch name to the [latest stable release branch](https://wiki.automotivelinux.org/agl-distro/release-notes#latest_stable_release). For example, for Nifty Needlefish branch use the last name i.e. "needlefish" as branch. + + + ```sh + $ cd $AGL_TOP + $ mkdir <<branch name>> + $ cd <<branch name>> + $ repo init -b <<branch name>> -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" branch. + The resulting local repository you download is dynamic and changes frequently 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: + + ```sh + $ cd $AGL_TOP + $ mkdir master + $ cd master + $ 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: + + ```sh + $ tree -L 1 + . + ├── bsp + ├── external + ├── meta-agl + ├── meta-agl-cluster-demo + ├── meta-agl-demo + ├── meta-agl-devel + ├── meta-agl-extra + └── meta-agl-telematics-demo + ``` diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/04_Initializing_Your_Build_Environment.md b/docs/01_Getting_Started/02_Building_AGL_Image/04_Initializing_Your_Build_Environment.md new file mode 100644 index 0000000..efe7001 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/04_Initializing_Your_Build_Environment.md @@ -0,0 +1,255 @@ +--- +title: 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: + +```sh +$AGL_TOP/master/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: + +```sh +$ cd $AGL_TOP/master +$ source meta-agl/scripts/aglsetup.sh -h +``` + +## AGL Machines (board support) + +Your target platform will be selected with the `-m` flag. +The MACHINE can be selected from the templates in `meta-agl/templates/machine/*`. +Note: This is also the place where you can add new boards. + +Following is a list of the available machines (level of support varies!): + +```sh +Available machines: + [meta-agl] + bbe # BeagleBoneEnhanced + beaglebone # BeagleBone + cubox-i # multiple i.MX6 boards + dragonboard-410c # Qualcomm Dragonboard 410c + dragonboard-820c # Qualcomm Dragonboard 820c + ebisu # Renesas RCar Ebisu + h3-salvator-x # Renesas RCar Salvator/H3 + h3ulcb # Renesas RCar H3 + h3ulcb-kf # Renesas RCar H3 w Kingfisher Board + h3ulcb-nogfx # Renesas RCar H3 w/o gfx blobs + hsdk # ARC HS + imx6qdlsabreauto # i.MX6 sabreauto + imx8mqevk # i.MX8 w etnaviv + imx8mqevk-viv # i.MX8 w vivante + intel-corei7-64 # x86-64 (Intel flavour) + j7-evm # TI Jacinto 7 EVM + m3-salvator-x # Renesas RCar Salvator/M3 + m3ulcb # Renesas RCar M3 + m3ulcb-kf # Renesas RCar M3 w Kingfisher Board + m3ulcb-nogfx # Renesas RCAR M3 w/o gfx blobs + nitrogen6x # i.MX6 nitrogen board + qemuarm # Qemu ARM + qemuarm64 # Qemu AArch 64 (ARM 64bit) + * qemux86-64 # Qemu x86-64 + raspberrypi4 # Raspberry Pi 4 + virtio-aarch64 # Virtio Guest + +``` + +## 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: + +```sh +Available features: + + [meta-agl] # CORE layer + agl-all-features :( agl-demo agl-pipewire agl-app-framework agl-netboot ) + # For the usual demo image + agl-app-framework # Application Framework + agl-archiver # Source Archiver + agl-buildstats # Build Statistics + agl-devel :( agl-package-management ) # Developer Env (root login) + agl-fossdriver # Fossology integration + agl-gplv2 # GPLv2-only packages + agl-localdev # inclusion of local development folder + agl-netboot # network boot (e.g. CI) + agl-package-management # include package management (e.g. rpm) + agl-pipewire # include pipewire + agl-ptest # enable ptest pckages + agl-refhw-h3 # enable reference hardware + agl-virt # EG-Virt features + agl-virt-guest-xen # EG-Virt features + agl-virt-xen :( agl-virt ) # EG-Virt features + agl-weston-remoting :( agl-demo agl-pipewire agl-app-framework ) + agl-weston-waltham-remoting :( agl-demo agl-pipewire agl-app-framework ) + + [meta-agl-demo] # DEMO layer + agl-cluster-demo-support :( agl-weston-remoting agl-demo agl-pipewire agl-app-framework ) + # sample IVI demo + agl-demo :( agl-pipewire agl-app-framework ) # default IVI demo + agl-demo-preload # Add Tokens and sample files + + [meta-agl-devel] # Development layer + agl-basesystem # Toyota basesystem + agl-drm-lease # DRM lease support + agl-egvirt # EG-Virt feature + agl-flutter # Flutter support + agl-jailhouse # GSoC: jailhouse enablement + agl-lxc :( agl-drm-lease agl-pipewire ) # IC-EG container support + agl-ros2 # GSoC: ros2 enablement + +Specialized features (e.g. CI): + agl-ci # Tweaks for CI + agl-ci-change-features :( agl-demo agl-pipewire agl-app-framework agl-devel agl-package-management agl-netboot agl-pipewire agl-buildstats agl-ptest ) + agl-ci-change-features-nogfx :( agl-demo agl-pipewire agl-app-framework agl-devel agl-package-management agl-netboot agl-pipewire agl-buildstats agl-ptest ) + agl-ci-snapshot-features :( agl-demo agl-pipewire agl-app-framework agl-devel agl-package-management agl-netboot agl-archiver agl-pipewire agl-buildstats agl-ptest ) + agl-ci-snapshot-features-nogfx :( agl-demo agl-pipewire agl-app-framework agl-devel agl-package-management agl-netboot agl-archiver agl-pipewire agl-buildstats agl-ptest ) + +``` + +To find out exactly what a feature provides, check out the respective layer and its README. + +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-app-framework**: Application Framework + +* **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/3.1.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-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/3.1.4/dev-manual/dev-manual.html#testing-packages-with-ptest) + as part of the build. + +* **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-pipewire**: Enables AGLs pipewire support. + +* **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. + +## 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: + +```sh +$ source meta-agl/scripts/aglsetup.sh -m qemux86-64 -b qemux86-64 agl-demo agl-devel +aglsetup.sh: Starting +Generating configuration files: + Build dir: /home/scottrif/workspace_agl/build + Machine: qemux86-64 + Features: agl-appfw-smack agl-demo agl-devel + 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. +The default Build Directory is `$AGL_TOP/<release-branch-name>/build`, and the nomenclature to be used throughout this doc is going to be `$AGL_TOP/<release-branch-name>/<build-dir>` +For this example, the Build Directory is `$AGL_TOP/master/qemux86-64`. + +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/3.1.4/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconf) +* [Local](https://yoctoproject.org/docs/3.1.4/ref-manual/ref-manual.html#ref-varlocality-config-local) +* [build/conf/local.conf](https://yoctoproject.org/docs/3.1.4/ref-manual/ref-manual.html#structure-build-conf-local.conf) +* [build/conf/bblayers.conf](https://yoctoproject.org/docs/3.1.4/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf) +* [BBLAYERS](https://yoctoproject.org/docs/3.1.4/ref-manual/ref-manual.html#var-BBLAYERS) +* [User Configuration](https://yoctoproject.org/docs/3.1.4/ref-manual/ref-manual.html#user-configuration) +* [Enabling Your Layer](https://yoctoproject.org/docs/3.1.4/dev-manual/dev-manual.html#enabling-your-layer) diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/05_Customizing_Your_Build.md b/docs/01_Getting_Started/02_Building_AGL_Image/05_Customizing_Your_Build.md new file mode 100644 index 0000000..31d2852 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/05_Customizing_Your_Build.md @@ -0,0 +1,150 @@ +--- +title: 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: + +```sh +$ vim $AGL_TOP/<release-branch-name>/<build-dir>/conf/local.conf +``` + +As mentioned in the "[Initializing Your Build Environment](./04_Initializing_Your_Build_Environment.md)" 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: + +```sh +INHERIT += "buildhistory" +BUILDHISTORY_COMMIT = "1" +``` + +See the +"[Maintaining Build Output Quality](https://www.yoctoproject.org/docs/3.1.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: + +```sh +INHERIT += "rm_work" +``` + +You can read about the class in the +"[rm_work.bbclass](https://www.yoctoproject.org/docs/3.1.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: + +```sh +SSTATE_DIR = "${AGL_TOP}/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: + +```sh +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/3.1.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/3.1.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: + +```sh +DL_DIR = "${AGL_TOP}/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: + +```sh +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/3.1.4/ref-manual/ref-manual.html#shared-state-cache)" +section of the Yocto Project Reference Manual. + +## Common Settings using Symbolic Link with site.conf + +```sh +$ echo "# reuse download directories" >> $AGL_TOP/site.conf +$ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +$ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +$ cd $AGL_TOP/master/qemux86-64/ +$ ln -sf $AGL_TOP/site.conf conf/ + +In General; +$ cd $AGL_TOP/<release-branch-name>/<build-dir>/ +$ ln -sf $AGL_TOP/site.conf conf/ +``` diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/06_Building_the_AGL_Image.md b/docs/01_Getting_Started/02_Building_AGL_Image/06_Building_the_AGL_Image.md new file mode 100644 index 0000000..faa033c --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/06_Building_the_AGL_Image.md @@ -0,0 +1,21 @@ +--- +title: 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. AGL has both `Qt` based and `HTML5` based IVI demos, where in the build process is almost the same except few changes in the build enviroment. + +This section, provides links to topics with instructions needed to create images for +three types of supported platforms and for emulation/virtualization using Quick +EMUlator (QEMU) or VirtualBox: + +* [x86 (Emulation and Hardware)](./07_Building_for_x86_(Emulation_and_Hardware).md) +* [Raspberry Pi 4](./08_Building_for_Raspberry_Pi_4.md) +* [R Car Gen 3](./09_Building_for_Supported_Renesas_Boards.md) +* [Virtio](./10_Building_for_Virtio.md) diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/07_Building_for_x86_(Emulation_and_Hardware).md b/docs/01_Getting_Started/02_Building_AGL_Image/07_Building_for_x86_(Emulation_and_Hardware).md new file mode 100644 index 0000000..e78ef58 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/07_Building_for_x86_(Emulation_and_Hardware).md @@ -0,0 +1,255 @@ +--- +title: Building for x86 (Emulation and Hardware) +--- + +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, and later the same image can be used to boot any hardware. + +## 1. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](./04_Initializing_Your_Build_Environment.md)" +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: + +**Sample Qt based IVI demo :** + +```sh +$ source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 -b qemux86-64 agl-demo agl-devel +$ echo "# reuse download directories" >> $AGL_TOP/site.conf +$ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +$ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +$ ln -sf $AGL_TOP/site.conf conf/ +``` + +**Sample HTML5 based IVI demo :** + +```sh +$ source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 -b qemux86-64 agl-demo agl-devel agl-profile-graphical-html5 +$ echo "# reuse download directories" >> $AGL_TOP/site.conf +$ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +$ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +$ ln -sf $AGL_TOP/site.conf conf/ +``` + +**IVI-EG Flutter based demo :** + +```sh +$ source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 -b qemux86-64 agl-flutter agl-devel +$ echo "# reuse download directories" >> $AGL_TOP/site.conf +$ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +$ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +$ ln -sf $AGL_TOP/site.conf conf/ +``` + +**IC-EG container image :** +```sh +### TBD +``` + +**Virt-EG demo image :** +```sh +### TBD +``` + +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 + +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. + +**Sample Qt based IVI demo :** +The target is `agl-demo-platform`. + +```sh +$ time bitbake agl-demo-platform +``` + +By default, the build process puts the resulting image in the Build Directory and further exporting that as `$IMAGE_NAME`: + +```sh +<build_directory>/tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz + +$ export IMAGE_NAME=agl-demo-platform-qemux86-64.vmdk.xz +``` + +**Sample HTML5 based IVI demo :** +The target is `agl-demo-platform-html5`. + +```sh +$ time bitbake agl-demo-platform-html5 +``` + +By default, the build process puts the resulting image in the Build Directory and further exporting that as `$IMAGE_NAME`: + +```sh +<build_directory>/tmp/deploy/images/qemux86-64/agl-demo-platform-html5-qemux86-64.vmdk.xz + +$ export IMAGE_NAME=agl-demo-platform-html5-qemux86-64.vmdk.xz +``` + +**IVI-EG Flutter based demo :** +The target is `agl-image-flutter`. + +```sh +$ time bitbake agl-image-flutter +``` + +**IC-EG container image :** +```sh +# TBD +``` + +**Virt-EG demo image :** +```sh +# TBD +``` + +## 3. Deploying the AGL Demo Image + +Deploying the image consists of decompressing the image and then +booting it using either QEMU, VirtualBox or physical system. +The examples below are usually for the 'agl-demo-platform' target. +Please adapt accordingly to your target image. + +**3.1 QEMU** + +Depending on your Linux distribution, use these commands to install QEMU: + +If you built your image with bitbake, you can now just use the ``runqemu`` wrapper, after sourcing `agl-init-build-env` inside the build-dir : + +For this example : + +```sh +$ source $AGL_TOP/master/qemux86-64/agl-init-build-env +``` + +In general : + +```sh +$ source $AGL_TOP/<release-branch-name>/<build-dir>/ +``` + +And further use `runqemu` to boot the image : + +```sh +$ runqemu tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.qemuboot.conf kvm serialstdio slirp publicvnc audio +``` + +If you need to run it outside of the bitbake environment or need special settings for +hardware pass-through using `qemu` : + + +**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 and +need to call your host's qemu binary instead. + +**NOTE:** the VM images need UEFI in the emulator to boot. Thus you need +to install the necessary files with below commands (ovmf). + +If your build host is running +[Arch Linux](https://www.archlinux.org/), use the following commands: + +```sh +sudo pacman -S qemu ovmf +export OVMF_PATH=/usr/share/ovmf/x64/OVMF_CODE.fd +``` + +If your build host is running Debian or Ubuntu, use the following commands: + +```sh +sudo apt-get install qemu-system-x86 ovmf +export OVMF_PATH=/usr/share/ovmf/OVMF.fd +``` + +If you build host is running Fedora, use the following commands: + +```sh +sudo yum install qemu qemu-kvm edk2-ovmf +export OVMF_PATH=/usr/share/edk2/ovmf/OVMF_CODE.fd +``` + +**Note:** + +Once QEMU is installed, boot the image with KVM support: + +```sh +qemu-system-x86_64 -enable-kvm -m 2048 \ + -bios ${OVMF_PATH} \ + -hda ${IMAGE_NAME} \ + -cpu kvm64 -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt \ + -vga virtio -show-cursor \ + -device virtio-rng-pci \ + -serial mon:stdio -serial null \ + -soundhw hda \ + -net nic \ + -net user,hostfwd=tcp::2222-:22 +``` + +**NOTE:** KVM may not be supported within a virtualized environment such as +VirtualBox. This is indicated by the qemu command above giving the error +message `Could not access KVM kernel module: No such file or directory` or +the kernel log output contains the error message `kvm: no hardware support`. +The image can be booted in such an environment by removing `-enable-kvm` from +the qemu command line, however this will result in lower perfromance within +the AGL demo. + +**3.2 VirtualBox** + +Once VirtualBox is installed, follow these steps to boot the image: + + 1. Install and set up [Virtual Box](https://www.virtualbox.org/wiki/Linux_Downloads). + + 2. Extract the vmdk file : + + ```sh + cd tmp/deploy/images/qemux86-64 + xz -d ${IMAGE_NAME} + ``` + + 3. Configure virtual box for AGL : + - Click on `New` or `Add`. + - Enter Name as `agl-demo`. + - Type as `Linux`. + - Version as `Other Linux (64-bit)`, click on `Next`. +  + - Select Memory size. Recommended is `2048 MB`, click on `Next`. +  + - Click on `Use an existing virtual hard disk file`, and select the extracted `agl-demo-platform-qemux86-64.vmdk.xz` or `<html5-image?>` file, click on `Create`. +  + - Go to `Settings`, and into `System`. Select `Chipset : IHC9`. Check on `Enable EFI (special OSes only)` and click on `OK`. +  + - Go to `Storage`, and change the attribute to `Type : AHCI` and click on `OK`. +  + - Click on `Start`. + - For troubleshooting, you can refer [here](https://lists.automotivelinux.org/g/agl-dev-community/message/8474). + +**3.3 x86 physical system** + + **NOTE :** UEFI enabled system is required. + + 1. Extract the image into USB drive : + + ```sh + $ cd tmp/deploy/images/qemux86-64 + $ lsblk + $ sudo umount <usb_device_name> + $ xzcat agl-demo-platform-qemux86-64.wic.xz | sudo dd of=<usb_device_name> bs=4M + $ sync + ``` + + 2. Boot from USB drive on the x86 system. diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/08_Building_for_Raspberry_Pi_4.md b/docs/01_Getting_Started/02_Building_AGL_Image/08_Building_for_Raspberry_Pi_4.md new file mode 100644 index 0000000..2ac3a2a --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/08_Building_for_Raspberry_Pi_4.md @@ -0,0 +1,204 @@ +--- +title: Building for Raspberry Pi 4 +--- + +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 4](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/) board. +These board comes in a variety of models. +See the +[Raspberry Pi Product Page](https://www.raspberrypi.org/products/) for more information. + +This section describes the steps you need to take to build the +AGL demo image for the Raspberry Pi 4 board. + +## 1. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](./04_Initializing_Your_Build_Environment.md)" +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 4 board, you need to specify some +specific options when you run the script : + +**Qt based IVI demo :** + + ```sh + $ source meta-agl/scripts/aglsetup.sh -f -m raspberrypi4 -b raspberrypi4 agl-demo agl-devel + $ echo "# reuse download directories" >> $AGL_TOP/site.conf + $ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf + $ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf + $ ln -sf $AGL_TOP/site.conf conf/ + ``` + +**HTML5 based IVI demo :** + + ```sh + $ source meta-agl/scripts/aglsetup.sh -f -m raspberrypi4 -b raspberrypi4 agl-demo agl-devel agl-profile-graphical-html5 + $ echo "# reuse download directories" >> $AGL_TOP/site.conf + $ echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf + $ echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf + $ ln -sf $AGL_TOP/site.conf conf/ + ``` + +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 Raspberry Pi 4. + +## 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](./05_Customizing_Your_Build.md)" +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: + +```sh +# 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. + +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. + +**Qt Based IVI demo :** +The target is `agl-demo-platform`. + +```sh +$ time bitbake agl-demo-platform +``` + +By default, the build process puts the resulting image in the Build Directory and further exporting that as `$IMAGE_NAME`. +Here is example for the Raspberry Pi 4 board for Qt Based demo: + +```sh +<build_dir>/tmp/deploy/images/raspberrypi4/agl-demo-platform-raspberrypi4.wic.xz + +$ export IMAGE_NAME=agl-demo-platform-raspberrypi4.wic.xz +``` + +**HTML5 Based IVI demo :** +The target is `agl-demo-platform-html5`. + +```sh +$ time bitbake agl-demo-platform-html5 +``` + +By default, the build process puts the resulting image in the Build Directory and further exporting that as `$IMAGE_NAME`. +Here is example for the Raspberry Pi 4 board for HTML5 Based demo: + +```sh +<build_dir>/tmp/deploy/images/raspberrypi4/agl-demo-platform-html5-raspberrypi4-64.wic.xz + +$ export IMAGE_NAME=agl-demo-platform-html5-raspberrypi4-64.wic.xz +``` + +## 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 4 board: + + 1. Plug your MicroSD card into your Build Host (i.e. the system that has your build output). + + 2. Extract the image into the SD card of Raspberry Pi 4 : + + **NOTE:** For Raspberry Pi 4, the image is at `<build-dir>/tmp/deploy/images/raspberrypi4/${IMAGE_NAME}`. + + Be sure you are root, provide the actual device name for *sdcard_device_name*, and the actual image name for *image_name*. + + ```sh + $ lsblk + $ sudo umount <sdcard_device_name> + $ xzcat ${IMAGE_NAME} | sudo dd of=<sdcard_device_name> bs=4M + $ sync + ``` + + **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` and `/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. SSH into Raspberry Pi : + - Connect Raspberry Pi to network : `Homescreen > Settings`, IP address mentioned here. + - SSH : + + ```sh + $ ssh root@<Raspberry-Pi-ip-address> + ``` + + 4. Serial 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. + + You can reference the following diagram for information on the following steps: + +  + + 1. Connect the TTL 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 able'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: + + ```sh + $ sudo screen /dev/ttyUSB0 115200 + ``` + +5. SOTA + + Follow the step below to build AGL for Raspberry Pi with enabled software over + the air (SOTA) updates: + + 1. Include **agl-sota** feature. + + 2. In **bblayers.conf** replace meta-updater-qemux86-64 with + **meta-updater-raspberrypi**. + + 3. In **local.conf** set `SOTA_PACKED_CREDENTIALS` and `OSTREE_BRANCHNAME`. + + More details are available [here](https://docs.ota.here.com/getstarted/dev/raspberry-pi.html). diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/09_Building_for_Supported_Renesas_Boards.md b/docs/01_Getting_Started/02_Building_AGL_Image/09_Building_for_Supported_Renesas_Boards.md new file mode 100644 index 0000000..8622194 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/09_Building_for_Supported_Renesas_Boards.md @@ -0,0 +1,894 @@ +--- +title: 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 on [elinux.org](https://elinux.org). +The information on this page describes setup and build procedures for both of these +Renesas development kits. + +Additionally, the AGL Reference Hardware platform is based on the same Renesas +H3 processor used on the Renesas R-Car Starter Kit Premier and Salvator-X boards, +so support for it leverages the Starter Kit Premier (also known as "h3ulcb") +build. +For more information on the AGL reference hardware platform, please refer to its +[manual](https://wiki.automotivelinux.org/_media/eg-rhsa/rh_manual_ver.1.0.pdf), +or the Reference Hardware System Architecture Expert Group +[wiki page](https://wiki.automotivelinux.org/eg-rhsa). + +## 1. Prepare your build + +### 1.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/application/automotive/r-car-h3-m3-documents-software) +site. + +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: + + ```sh + grep -rn ZIP_.= $AGL_TOP/meta-agl/meta-agl-bsp/meta-rcar-gen3/scripts/setup_mm_packages.sh + ``` + + The script's output identifies the files you need to download from the page. + +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. + Find the appropriate download links on the + [R-Car H3/M3 Software library and Technical document](https://www.renesas.com/us/en/application/automotive/r-car-h3-m3-documents-software) + site. + The file pairs are grouped according to the Yocto Project version you are + using with the AGL software. + + Use the following table to map the Renesas version to your AGL software: + + | AGL Version | Renesas version | + |:-:|:-:| + | AGL master | 5.9.0 | + +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/application/automotive/r-car-h3-m3-documents-software) + 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: + + ```sh + 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: + + ```sh + chmod a+rw $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: + + ```sh + $ 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-weston8-20200923.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-weston8-20200923.zip + ``` + +### 1.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. + +### 1.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. + +### 1.4. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](./04_Initializing_Your_Build_Environment.md)" +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 Pro/M3 + kingfisher support | `MACHINE`=m3ulcb-kf | + | Starter Kit Pro/M3 without graphic driver (using pixman) | `MACHINE`=m3ulcb-nogfx | + | Starter Kit Premier/H3 | `MACHINE`=h3ulcb | + | Starter Kit Premier/H3 + kingfisher support | `MACHINE`=h3ulcb-kf | + | Starter Kit Premier/H3 without graphic driver (using pixman) | `MACHINE`=h3ulcb-nogfx | + | Salvator-X | `MACHINE`=h3-salvator-x | + | AGL Reference Hardware | `MACHINE`=h3ulcb | + | AGL Reference Hardware without graphic driver (using pixman) | `MACHINE`=h3ulcb-nogfx | + + For example, the following command defines and exports the `MACHINE` variable + for the Starter Kit Premier/H3 Board: + + ```sh + export MACHINE=h3ulcb + ``` + +### 1.5. **Run the `aglsetup.sh` Script:** + +Use the following commands to run the AGL Setup script: + +```sh +cd $AGL_TOP +source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo +``` + +**NOTE:** +To avoid useless download and rebuild, it's important to set the variable DL_DIR and SSTATE_DIR in your configuration. + +```sh +echo "# reuse download directories" >> $AGL_TOP/site.conf +echo "DL_DIR = \"$HOME/downloads/\"" >> $AGL_TOP/site.conf +echo "SSTATE_DIR = \"$AGL_TOP/sstate-cache/\"" >> $AGL_TOP/site.conf +ln -sf $AGL_TOP/site.conf conf/ +``` + +**Reference Hardware :** + +If building for the AGL Reference Hardware (with `MACHINE` set to "h3ulcb" or +"h3ulcb-nogfx"), add `agl-refhw-h3`, for example: + +```sh +cd $AGL_TOP +source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo agl-refhw-h3 +``` + +**HTML5 based IVI demo :** + +For HTML5 based IVI demo the feature "agl-profile-graphical-html5" is needed. + +```sh +$ source meta-agl/scripts/aglsetup.sh -f -m $MACHINE -b $MACHINE agl-demo agl-devel agl-profile-graphical-html5 +``` + +**Instrument Cluster with Container isolation demo :** + +```sh +$ source meta-agl/scripts/aglsetup.sh -f -m $MACHINE -b $MACHINE agl-lxc +``` + +**NOTE:** +You can check if your logs match what is expected in the [troubleshooting section](#4-troubleshooting). + +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](./04_Initializing_Your_Build_Environment.md)" +section. + +## 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 work with supported hardware. +You can find these pre-built images on the +[AGL Download web site](https://download.automotivelinux.org/AGL/release). + +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. + +**Qt based IVI demo :** +For this example, the target is "agl-demo-platform": + +```sh +bitbake agl-demo-platform +``` + +**HTML5 based IVI demo :** +The target is `agl-demo-platform-html5`. + +```sh +$ time bitbake agl-demo-platform-html5 +``` + +**Instrument Cluster with Container isolation demo :** +The target is `lxc-host-image-demo`. + +```sh +$ time bitbake lxc-host-image-demo +``` + +The build process puts the resulting image in the Build Directory: + +```sh +<build_directory>/tmp/deploy/images/$MACHINE +``` + +## 3. Deploying the AGL Demo Image + +To boot your image on the Renesas board, you need to do three things: + +1. [Update all firmware on the board.](#4-troubleshooting) +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. + +### 3.1. Booting the Image Using a MicroSD Card + +1. 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: + + ```sh + $ 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`: + + ```sh + $ 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: + + ```sh + cd $AGL_TOP/build/tmp/deploy/images/$MACHINE + bmaptool copy ./agl-demo-platform-$MACHINE.wic.xz <boot_device_name> + ``` + + Alternatively, you can leave the image in an uncompressed state and write it + to the MicroSD card: + + ```sh + sudo umount <boot_device_name> + xzcat ./agl-demo-platform-$MACHINE.wic.xz | sudo dd of=<boot_device_name> bs=4M + sync + ``` + +2. 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. + +### 3.2. 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 + +1. 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) + * [Minicom](https://en.wikipedia.org/wiki/Minicom) + + Of these three, "picocom" has the least dependencies and is therefore + considered the "lightest" solution. + +2. 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: + + ```sh + 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: + + ```sh + picocom -b 115200 /dev/ttyUSB0 + ``` + + or + + ```sh + minicom -b 115200 -D /dev/ttyUSB0 + ``` + + or + + ```sh + screen /dev/ttyUSB0 115200 + ``` + +3. 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**: + + ```text + 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 + => + ``` + +### 3.3. 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: + + ```sh + => 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/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 + ``` + +3. To boot your board using the MicroSD card, be sure your environment is set up +as follows: + + ```sh + 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. Loading dtb : + + **NOTE** : Refer [here](https://elinux.org/R-Car/Boards/Yocto-Gen3-CommonFAQ/Which_dtb_file_is_required_to_boot_linux_on_the_R-Car_Starter_Kit_board_%3F) for more information. + + Make sure your ``load_dtb`` is set as follows : + + | Renesas Boards | DTB Name | + |:-:|:-:| + | **H3SK v2.0(DDR 4GB)** | r8a7795-h3ulcb.dtb | + | **H3SK v2.0(DDR 8GB)/v3.0(DDR 8GB)** | r8a7795-h3ulcb-4x2g.dtb | + | **M3SK v1.0** | r8a7796-m3ulcb.dtb | + | **M3SK v3.0** | r8a7796-m3ulcb-2x4g.dtb | + | **H3SK with a Kingfisher board** | r8a7795-h3ulcb-kf.dtb | + | **M3SK with a Kingfisher board** | r8a7796-m3ulcb-kf.dtb | + | **AGL Reference Hardware board** | r8a7795-agl-refhw.dtb | + + ```sh + setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-h3ulcb-kf.dtb + ``` + +5. Save the boot environment: + + ```sh + saveenv + ``` + +6. Boot the board: + + ```sh + run bootcmd + ``` + +## 4. Troubleshooting + +### 4.1. 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](05_Customizing_Your_Build.md)" +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: + +```sh +grep -w -e "^MACHINE =" $AGL_TOP/build/conf/local.conf +``` + +Depending on the Renesas board you are using, you should see output +as follows: + +```sh +MACHINE = "h3ulcb" +``` + +or + +```sh +MACHINE = "m3ulcb" +``` + +or + +```sh +MACHINE = "h3-salvator-x" +``` + +If you ran the `aglsetup.sh` script as described in the +"[Making Sure Your Build Environment is Correct](#14-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 + +### 4.2. Check 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: + +```text +[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-weston8-20200923.zip + R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston8-20200923.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: + +```text +~/workspace_agl/build/conf $ cat setup.log +--- beginning of setup script +--- fragment /home/working/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh +--- fragment /home/working/workspace_agl/meta-agl/templates/machine/h3ulcb/50_setup.sh +~/workspace_agl ~/workspace_agl/build +ERROR: FILES "+/home/working/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston8-20200923.zip+" NOT EXTRACTING CORRECTLY +ERROR: FILES "+/home/working/Downloads/R-car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston8-20200923.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/application/automotive/r-car-h3-m3-documents-software> + +These 2 files from there should be stored in your +'/home/working/Downloads' directory. + R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston8-20200923.zip + R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston8-20200923.zip +ERROR: Script /home/working/workspace_agl/build/conf/setup.sh failed +[snip] +``` + +### 4.3. 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: + + ```sh + $AGL_TOP/build/tmp/deploy/images/$MACHINE + ``` + + **NOTE:** The Salvator-X firmware update process is not documented on eLinux. + **NOTE:** The AGL Reference Hardware board generally should not require a + firmware update to be usable, and has a slightly different update procedure. + If you do need to update the firmware, the procedure is documented + [here](https://git.automotivelinux.org/AGL/meta-agl-refhw/tree/meta-agl-refhw-gen3/docs/ReferenceHW_Rcar_gen3.md). + +### 4.4. 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** or **AGL Reference Hardware**: + +```text +Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 + +h3ulcb 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. + +### 4.5. 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 **h3ulcb** board: + +```sh +h3ulcb login: root +Last login: Tue Dec 6 09:55:15 UTC 2016 on tty2 +root@h3ulcb:~# 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@h3ulcb:~# +``` + +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: + +```sh +$ ssh root@10.0.0.27 +Last login: Tue Dec 6 10:01:11 2016 from 10.0.0.13 +root@h3ulcb:~# cat /etc/os-release +ID="poky-agl" +NAME="Automotive Grade Linux" +VERSION="11.0.0+snapshot-20210128 (koi)" +VERSION_ID="11.0.0-snapshot-20210128" +PRETTY_NAME="Automotive Grade Linux 11.0.0+snapshot-20210128 (koi)" +``` + +## 5. Supplementary Information + +### 5.1. R-Car Generation 3 Information + +Refer to the [R-Car](https://elinux.org/R-Car) page on the +[elinux.org](https://elinux.org) website for more information. + +### 5.2. Proprietary libraries for meta-rcar-gen3 + +The meta-rcar-gen3 layer of meta-renesas supports Graphic GLES(GSX) +libraries, proprietary multimedia libraries, and ICCOM software. + +### 5.3. Build with Renesas multimedia libraries + +Multimedia portions depend on GLES portions. + +* A. Configuration for Multimedia features + + * Please copy proprietary libraries to the directory of recipes. + + * Please set local.conf the following. + + **Enable multimedia features. This provides package group of plug-ins of the GStreamer, multimedia libraries and kernel drivers.** + + ```sh + MACHINE_FEATURES:append = " multimedia" + ``` + +* B. Configuration for optional codecs and middleware + + * Please copy proprietary libraries to the directory of recipes. + + * Add features to `DISTRO_FEATURES:append` to local.conf + + **Additional configuration in OMX module**: + + ```text + " h263dec_lib" - for OMX Media Component H263 Decoder Library + " h264dec_lib" - for OMX Media Component H264 Decoder Library + " h264enc_lib" - for OMX Media Component H.264 Encoder Library + " h265dec_lib" - for OMX Media Component H265 Decoder Library + " mpeg2dec_lib" - for OMX Media Component MPEG2 Decoder Library + " mpeg4dec_lib" - for OMX Media Component MPEG4 Decoder Library + " vc1dec_lib" - for OMX Media Component VC-1 Decoder Library + " divxdec_lib" - for OMX Media Component DivX Decoder Library + " rvdec_lib" - for OMX Media Component RealVideo Decoder Library + " alacdec_lib" - for OMX Media Component ALAC Decoder Library + " flacdec_lib" - for OMX Media Component FLAC Decoder Library + " aaclcdec_lib" - for OMX Media Component AAC-LC Decoder Library + " aaclcdec_mdw" - for AAC-LC 2ch Decoder Middleware for Linux + " aacpv2dec_lib" - for OMX Media Component aacPlus V2 Decoder Library + " aacpv2dec_mdw" - for aacPlus V2 Decoder Middleware for Linux + " mp3dec_lib" - for OMX Media Component MP3 Decoder Library + " mp3dec_mdw" - for MP3 Decoder Middleware for Linux + " wmadec_lib" - for OMX Media Component WMA Standard Decoder Library + " wmadec_mdw" - for WMA Standard Decoder Middleware for Linux + " dddec_lib" - for OMX Media Component Dolby(R) Digital Decoder Library + " dddec_mdw" - for Dolby(R) Digital Decoder Middleware for Linux + " aaclcenc_lib" - for OMX Media Component AAC-LC Encoder Library + " vp8dec_lib" - for OMX Media Component VP8 Decoder Library for Linux + " vp8enc_lib" - for OMX Media Component VP8 Encoder Library for Linux + " vp9dec_lib" - for OMX Media Component VP9 Decoder Library for Linux + " aaclcenc_mdw" - for AAC-LC Encoder Middleware for Linux + " cmsbcm" - for CMS Basic Color Management Middleware for Linux + " cmsblc" - for CMS CMM3 Backlight Control Middleware for Linux + " cmsdgc" - for CMS VSP2 Dynamic Gamma Correction Middleware for Linux + " dtv" - for ISDB-T DTV Software Package for Linux + " dvd" - for DVD Core-Middleware for Linux + " adsp" - for ADSP driver, ADSP interface and ADSP framework for Linux + " avb" - for AVB Software Package for Linux + ``` + + Example: + + ```sh + DISTRO_FEATURES:append = " h264dec_lib h265dec_lib mpeg2dec_lib aaclcdec_lib aaclcdec_mdw" + ``` + +* C. Configuration for test packages + + Must ensure that Multimedia features have been enabled. + (Please refer to III/A to enable Multimedia.) + + * Please add feature to `DISTRO_FEATURES:append` to local.conf. + + **Configuration for multimedia test package** + + ```sh + DISTRO_FEATURES:append = " mm-test" + ``` + +### 5.4. Enable Linux ICCOM driver and Linux ICCOM library + +For Linux ICCOM driver and Linux ICCOM library + +* Please copy proprietary libraries to the directory of recipes. + +* Please set the following in local.conf: + + ```sh + DISTRO_FEATURES:append = "iccom" + ``` diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/10_Building_for_Virtio.md b/docs/01_Getting_Started/02_Building_AGL_Image/10_Building_for_Virtio.md new file mode 100644 index 0000000..a80479d --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/10_Building_for_Virtio.md @@ -0,0 +1,151 @@ +--- +title: Building for virtio +--- + +Virtio is a standardized interface for implementing virtual I/O devices: + +* Russell, Rusty. "virtio: towards a de-facto standard for virtual I/O devices." ACM SIGOPS Operating Systems Review 42.5 (2008): 95-103. + +This section describes the steps you need to take to build the AGL demo image +for virtio "platform". Later, the same image can be run on various emulators or +hypervisors that provide virtio devices, for example, QEMU aarch64 emulation on +PC, QEMU/KVM aarch64 virtualization on AGL Reference Hardware, etc. + +Below, AGL minimal image and Qt based IVI demo are used as example, but +similiarly one can run HTML5 based demos, cluster demo, or other AGL images. + +## 1. Making Sure Your Build Environment is Correct + +The +"[Initializing Your Build Environment](./04_Initializing_Your_Build_Environment.md)" +section presented generic information for setting up your build environment +using the `aglsetup.sh` script. +If you are building the AGL demo image for virtio platform, you need to specify +some specific options when you run the script: + +```sh +$ source meta-agl/scripts/aglsetup.sh -m virtio-aarch64 -b build-virtio-aarch64 agl-demo +``` + +The "-m" option specifies the "virtio-aarch64" machine. + +The "-b" option sets custom build directory instead of default "build". + +The "-f" option might be added to override previously available configuration. +By default, if there were already configuration files in build directory, they +will not be overriden, as result, aglsetup.sh might not have desired effect. + +## 2. Using BitBake + +This section shows the `bitbake` command used to build the AGL image. + +Start the build using the `bitbake` command. + +**AGL minimal image :** +The target is `agl-image-minimal`. + +```sh +$ bitbake agl-image-minimal +``` + +**Qt Based IVI demo :** +The target is `agl-demo-platform`. + +```sh +$ bitbake agl-demo-platform +``` + +## 3. Deploying the AGL Demo Image + +This subsection describes AGL virtio-aarch64 image deployment under virtio +platform provided by QEMU aarch64 emulator on PC, or QEMU/KVM hypervisor on AGL +Reference Hardware board. + +**3.1 QEMU on PC** + +If shell from which AGL was built is closed, or new shell is opened, then it is +needed to re-initialize build environment: + +```sh +$ source $AGL_TOP/build-virtio-aarch64/agl-init-build-env +``` + +And further use `runqemu` to boot the image : + +```sh +$ runqemu +``` + +**3.2 QEMU/KVM on AGL Reference Hardware** + +Follow these steps to run virtual AGL on bare-metal AGL (AGL-in-AGL) on AGL Reference Hardware board: + + 1. Partition eMMC or SD-Card to have two partitions, at least 1 GiB each. + Actually, can be less but just rounded up to have a nice number. + + 2. Flash AGL minimal image root file system to the second partition on SD-Card + or eMMC. + + 3. Build AGL minimal image for AGL Reference Hardware. + + ```sh + source meta-agl/scripts/aglsetup.sh -m h3ulcb -b build-h3ulcb agl-refhw-h3 + ``` + + In `build-h3ulcb/conf/local.conf` add + + ``` + AGL_DEFAULT_IMAGE_FSTYPES = "ext4" + IMAGE_INSTALL_append = "qemu" + ``` + + CAUTION: Calling aglsetup.sh with "-f" flag will remove above modification + in "local.conf", so they will be needed to be re-applied. + + Build image: + + ```sh + bitbake agl-image-minimal + ``` + + Add virtio kernel to the AGL Reference Hardware Linux rootfs: + + ```sh + cp build-virtio-aarch64/tmp/deploy/images/virtio-aarch64/Image build-h3ulcb/tmp/work/h3ulcb-agl-linux/agl-image-minimal/1.0-r0/rootfs/linux2 + bitbake agl-image-minimal -c image_ext4 -f + bitbake agl-image-minimal -c image_complete + ``` + + Flash root file system to the first partition on SD-Card or eMMC. + + 4. Boot AGL Reference Hardware board using Linux located on the first partition of SD-Card or eMMC. + + 5. Run QEMU from Linux 1 command line + + ```sh + qemu-system-aarch64 \ + -machine virt \ + -cpu cortex-a57 \ + -m 2048 \ + -serial mon:stdio \ + -global virtio-mmio.force-legacy=false \ + -drive id=disk0,file=/dev/mmcblk0p2,if=none,format=raw \ + -device virtio-blk-device,drive=disk0 \ + -object rng-random,filename=/dev/urandom,id=rng0 \ + -device virtio-rng-device,rng=rng0 \ + -nographic \ + -kernel /linux2 + -append 'root=/dev/vda rw mem=2048M' + ``` + + NOTE: mmcblk0p2 above is used for when root file system is flashed on eMMC. + In case of SD-Card, mmcblk1p2 has to be used. + + 6. It is possible to exit from QEMU using monitor commands. Enter "Ctrl+a h" for help. + +Know issue: to enable hardware virtualization using KVM, option `-enable-kvm` +could be added to QEMU command line, but it fails with: + +``` +qemu-system-aarch64: kvm_init_vcpu failed: Invalid argument +``` diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png Binary files differnew file mode 100644 index 0000000..f4374d0 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/image-developer-workflow.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/image-developer-workflow.png Binary files differnew file mode 100644 index 0000000..a185dc6 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/image-developer-workflow.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-1.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-1.png Binary files differnew file mode 100644 index 0000000..a43c111 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-1.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-2.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-2.png Binary files differnew file mode 100644 index 0000000..d4e1dd0 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-2.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-3.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-3.png Binary files differnew file mode 100644 index 0000000..f6389f1 --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-3.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-4.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-4.png Binary files differnew file mode 100644 index 0000000..09f7f0b --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-4.png diff --git a/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-5.png b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-5.png Binary files differnew file mode 100644 index 0000000..0c3f51b --- /dev/null +++ b/docs/01_Getting_Started/02_Building_AGL_Image/images/vbox-5.png |
