diff options
| author |   growupboron <shankhoghosh123@gmail.com> | 2020-10-09 00:19:18 +0530 |
|---|---|---|
| committer |   Jan-Simon Moeller <jsmoeller@linuxfoundation.org> | 2020-10-14 11:19:53 +0000 |
| commit | eefc3ab6cbb8a5901632f46d99e13c8d90b2415d (patch) | |
| tree | 90815d532ed7b2d0962a1468aee29f05a4404eef /docs/0_Getting_Started | |
| parent | 4aad369c9728061c97b3de792286e743ee884b09 (diff) | |
rewrote quickstart, build-process
Revamped and updated documentation to install and build AGL images.
(removed whitespaces, added contribution guide, corrected rcar-gen3 section 7, added aglsetup.h flags to hardware support, some minor changes)
Bug-AGL: [SPEC-3633]
Signed-off-by: Shankho Boron Ghosh <shankhoghosh123@gmail.com>
Change-Id: Iedb6c7dc1661f4bc58b5f25ea5d188778c7ff908
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25407
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Diffstat (limited to 'docs/0_Getting_Started')
49 files changed, 1459 insertions, 2662 deletions
diff --git a/docs/0_Getting_Started/1_Quickstart/Using_Ready_Made_Images.md b/docs/0_Getting_Started/1_Quickstart/Using_Ready_Made_Images.md new file mode 100644 index 0000000..08af3a0 --- /dev/null +++ b/docs/0_Getting_Started/1_Quickstart/Using_Ready_Made_Images.md @@ -0,0 +1,209 @@ +--- +title: Using Ready Made Images +--- + +AGL provides a number of pre-built ready-made images of various versions. + +## x86 (Emulation and Hardware) + +### 1. QEMU (Emulation) + +1. Download the [compressed prebuilt image](https://download.automotivelinux.org/AGL/snapshots/master/latest/qemux86-64/deploy/images/qemux86-64/agl-demo-platform-crosssdk-qemux86-64.ext4.xz). + +2. Download the [compressed kernel image](https://download.automotivelinux.org/AGL/snapshots/master/latest/qemux86-64/deploy/images/qemux86-64/bzImage). + +3. Install [QEMU](https://www.qemu.org/download/) : + + ```sh + $ apt-get install qemu + ``` + +4. Install [vinagre](https://wiki.gnome.org/Apps/Vinagre) : + + ```sh + $ sudo apt install vinagre + ``` + +5. Create boot directory and copy compressed images (prebuilt & kernel) into them : + + ```sh + $ mkdir ~/agl-demo/ + $ cp ~/Downloads/agl-demo-platform-crosssdk-qemux86-64.ext4.xz ~/agl-demo/ + $ cp ~/Downloads/bzImage ~/agl-demo/ + $ cd ~/agl-demo + $ sync + ``` + +6. Extract prebuilt compressed image : + + ```sh + $ xz -v -d agl-demo-platform-crosssdk-qemux86-64.ext4.xz + ``` + +7. Launch QEMU with vinagre (for scaling), remove `- snapshot \` if you want to save changes to the image files : + +```sh + $ ( sleep 5 && vinagre --vnc-scale localhost ) & + qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::2222-:22 \ + -drive file=agl-demo-platform-crosssdk-qemux86-64.ext4,if=virtio,format=raw -show-cursor -usb -usbdevice tablet -device virtio-rng-pci \ + -snapshot \ + -vnc :0 -soundhw hda -machine q35 -cpu kvm64 -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt -enable-kvm \ + -m 2048 -serial mon:vc -serial mon:stdio -serial null -kernel bzImage \ + -append 'root=/dev/vda rw console=tty0 mem=2048M ip=dhcp oprofile.timer=1 console=ttyS0,115200n8 verbose fstab=no' +``` + + - Login into AGL : + + ```sh + Automotive Grade Linux 9.99.4+snapshot qemux86-64 ttyS1 + + qemux86-64 login: root + ``` + + + - Shutdown QEMU : `$ poweroff`, otherwise QEMU will run in the background. + - To use vnc-viewer instead of vinagre : + ```sh + $ ( sleep 5 && vncviewer ) & + qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::2222-:22 \ + -drive file=agl-demo-platform-crosssdk-qemux86-64.ext4,if=virtio,format=raw -show-cursor -usb -usbdevice tablet -device virtio-rng-pci \ + -snapshot \ + -vnc :0 -soundhw hda -machine q35 -cpu kvm64 -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt -enable-kvm \ + -m 2048 -serial mon:vc -serial mon:stdio -serial null -kernel bzImage \ + -append 'root=/dev/vda rw console=tty0 mem=2048M ip=dhcp oprofile.timer=1 console=ttyS0,115200n8 verbose fstab=no' + ``` + +### 2. Virtual Box (Emulation) + + 1. Download the [compressed vbox disk image](https://download.automotivelinux.org/AGL/snapshots/master/latest/qemux86-64/deploy/images/qemux86-64/agl-demo-platform-crosssdk-qemux86-64.wic.vmdk.xz). + + 2. Install and set up [Virtual Box](https://www.virtualbox.org/wiki/Linux_Downloads). + + 3. Extract the vmdk file : `$ xz -v -d agl-demo-platform-crosssdk-qemux86-64.wic.vmdk.xz` + + 4. 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-crosssdk-qemux86-64.wic.vmdk` 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. x86 physical system + + **NOTE :** UEFI enabled system is required. + + 1. Download the [compressed prebuilt image](https://download.automotivelinux.org/AGL/snapshots/master/latest/qemux86-64/deploy/images/qemux86-64/agl-demo-platform-crosssdk-qemux86-64.wic.xz). + + 2. Extract the image into USB drive : + + ```sh + $ lsblk + $ sudo umount <usb_device_name> + $ xzcat agl-demo-platform-crosssdk-qemux86-64.wic.xz | sudo dd of=<usb_device_name> bs=4M + $ sync + ``` + + + 3. Boot from USB drive on the x86 system. + + +## Raspberry Pi 4 + + 1. Download the [compressed prebuilt image](https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi4/deploy/images/raspberrypi4-64/agl-demo-platform-crosssdk-raspberrypi4-64.wic.xz). + + 2. Extract the image into the SD card of Raspberry Pi 4 : + + ```sh + $ lsblk + $ sudo umount <sdcard_device_name> + $ xzcat agl-demo-platform-crosssdk-raspberrypi4-64.wic.xz | 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 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 + ``` + +## R-Car H3SK (H3ULCB board) + +**NOTE :** The prebuilt image doesn't support graphics (as of yet) and will run headless. For graphical support, a local build with the neccesary graphics driver is required. + + + 1. Update the [firmware](https://elinux.org/R-Car/Boards/H3SK#Flashing_firmware) using files from [here](https://download.automotivelinux.org/AGL/snapshots/master/latest/h3ulcb-nogfx/deploy/images/h3ulcb/). + + 2. Download the [compressed prebuilt image](https://download.automotivelinux.org/AGL/snapshots/master/latest/h3ulcb-nogfx/deploy/images/h3ulcb/agl-image-ivi-crosssdk-h3ulcb.wic.xz). + + 3. Extract the image into the boot device : + + ```sh + $ lsblk + $ sudo umount <boot_device_name> + $ xzcat agl-image-ivi-crosssdk-h3ulcb.wic.xz | sudo dd of=<boot_device_name> bs=4M + $ sync + ``` + + 3. [Serial](https://elinux.org/R-Car/Boards/H3SK) into the board for debugging. + 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 + ``` diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png b/docs/0_Getting_Started/1_Quickstart/images/RaspberryPi2-ModelB-debug-serial-cable.png Binary files differindex f4374d0..f4374d0 100644 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png +++ b/docs/0_Getting_Started/1_Quickstart/images/RaspberryPi2-ModelB-debug-serial-cable.png diff --git a/docs/0_Getting_Started/1_Quickstart/images/vbox-1.png b/docs/0_Getting_Started/1_Quickstart/images/vbox-1.png Binary files differnew file mode 100644 index 0000000..a43c111 --- /dev/null +++ b/docs/0_Getting_Started/1_Quickstart/images/vbox-1.png diff --git a/docs/0_Getting_Started/1_Quickstart/images/vbox-2.png b/docs/0_Getting_Started/1_Quickstart/images/vbox-2.png Binary files differnew file mode 100644 index 0000000..d4e1dd0 --- /dev/null +++ b/docs/0_Getting_Started/1_Quickstart/images/vbox-2.png diff --git a/docs/0_Getting_Started/1_Quickstart/images/vbox-3.png b/docs/0_Getting_Started/1_Quickstart/images/vbox-3.png Binary files differnew file mode 100644 index 0000000..f6389f1 --- /dev/null +++ b/docs/0_Getting_Started/1_Quickstart/images/vbox-3.png diff --git a/docs/0_Getting_Started/1_Quickstart/images/vbox-4.png b/docs/0_Getting_Started/1_Quickstart/images/vbox-4.png Binary files differnew file mode 100644 index 0000000..09f7f0b --- /dev/null +++ b/docs/0_Getting_Started/1_Quickstart/images/vbox-4.png diff --git a/docs/0_Getting_Started/1_Quickstart/images/vbox-5.png b/docs/0_Getting_Started/1_Quickstart/images/vbox-5.png Binary files differnew file mode 100644 index 0000000..0c3f51b --- /dev/null +++ b/docs/0_Getting_Started/1_Quickstart/images/vbox-5.png diff --git a/docs/0_Getting_Started/1_Welcome/Overview.md b/docs/0_Getting_Started/1_Welcome/Overview.md deleted file mode 100644 index f1e9038..0000000 --- a/docs/0_Getting_Started/1_Welcome/Overview.md +++ /dev/null @@ -1,79 +0,0 @@ -Overview -======== - -Welcome to the Automotive Grade Linux (AGL) documentation -"Getting Started" page. -This page provides you with a brief overview of the AGL Distribution -and with an introduction to selected topics that can help -you get a quick start using AGL for development. - -What is Automotive Grade Linux? -------------------------------- - -Automotive Grade Linux is a collaborative, open source project -that brings together automakers, suppliers, and technology companies -for the purpose of building Linux-based, open source software platforms -for automotive applications that can serve as de facto industry -standards. - -AGL address all software in the vehicle: infotainment, -instrument cluster, heads-up-display (HUD), telematics, connected car, -advanced driver assistance systems (ADAS), functional -safety, and autonomous driving. - -Adopting a shared platform across the industry reduces fragmentation -and allows automakers and suppliers to reuse the same code base, which -leads to rapid innovation and faster time-to-market for new products. - -AGL is a Linux Foundation project and its goals are as follows: - -* Build a single platform for the entire industry -* Develop 70 to 80% of the starting point for a production project -* Reduce fragmentation by combining the best of open source -* Develop an ecosystem of developers, suppliers, and expertise - that all use a single platform - -You can find additional overview information on the -"[About Automotive Grade Linux](https://www.automotivelinux.org/about)" page. -You can find information on the AGL Unified Code Base on the -"[Unified Code Base](https://www.automotivelinux.org/software/unified-code-base)" -page. - -What Can I Do Right Away Using AGL? ------------------------------------ - -The "Getting Started" topics allow you to quickly accomplish some work using -AGL. -You can use the "Getting Started" sections to do the following: - -* [Set Up a Docker Container](./docker-container-setup.html) to create a - contained, controlled development environment for building images and - Software Development Kits (SDKs) using AGL. - -* [Learn How to Build an AGL Image](./image-workflow-intro.html) by working - through fundamental steps that show you how to build for various supported - hardware targets (e.g. Raspberry PI boards). - -* [Learn How to Create an Application](./app-workflow-intro.html) using the - application development workflow. - -The AGL community is diverse and supportive. -You can become an active community member that contributes feedback, -ideas, suggestions, bugs and documentation. - -* Join the IRC conversation using the `#automotive` channel on - `irc.freenode.net`. - -* Subscribe to the AGL discussions mailing list at - [automotive-discussions](http://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions). - -* Learn about AGL distribution by visiting the - "[AGL Distribution](https://wiki.automotivelinux.org/agl-distro)" wiki page. - -* Explore further "Getting Started" information by visiting the - "[Getting Started with AGL](https://wiki.automotivelinux.org/start/getting-started)" - wiki page. - -* Learn how to contribute by visiting the - "[Contributing to the AGL Distro](https://wiki.automotivelinux.org/agl-distro/contributing)" - wiki page. diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/0_Overview.md b/docs/0_Getting_Started/2_Building_AGL_Image/0_Build_Process.md index 745cec1..fe6f687 100644 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/0_Overview.md +++ b/docs/0_Getting_Started/2_Building_AGL_Image/0_Build_Process.md @@ -1,14 +1,7 @@ --- -edit_link: '' -title: Overview -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/image-workflow-intro.md +title: Build Process Overview --- -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Overview # - The AGL image development workflow consists of setting up the system (i.e. the build host) that builds the image and finishes with using the @@ -25,7 +18,7 @@ in the AGL Documentation set. Links are provided when a set of steps is required that is documented elsewhere. -{:: style="margin:auto; display:flex"} + 1. Prepare your build host to be able to use the tools needed to build your image. @@ -36,5 +29,5 @@ elsewhere. 4. Make sure your build configuration is defined exactly how you want it for your build. 5. Use - [BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html) + [BitBake](https://yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html) to build your image. diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/1_Preparing_Your_Build_Host.md b/docs/0_Getting_Started/2_Building_AGL_Image/1_Preparing_Your_Build_Host.md index e609e4c..74877b0 100644 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/1_Preparing_Your_Build_Host.md +++ b/docs/0_Getting_Started/2_Building_AGL_Image/1_Preparing_Your_Build_Host.md @@ -1,22 +1,15 @@ --- -edit_link: '' title: Preparing Your Build Host -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/image-workflow-prep-host.md --- -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 1. Preparing Your Build Host - Preparing your build host so that it can build an AGL image means making sure your system is set up to use the [Yocto Project](https://yoctoproject.org) OpenEmbedded build system, which is based on -[BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html). +[BitBake](https://yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html). This section presents minimal information so you can prepare the build host -to use the "Rocko" version of the Yocto Project (i.e. version 2.4.4). +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/). @@ -24,17 +17,16 @@ the Yocto Project documentation **NOTE:** This entire section presumes you want to build an image. You can skip the entire build process if you want to use a ready-made development image. -The -[supported images][AGL snapshots master latest] exist for several boards as +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 -"[Downloading an Image](./app-workflow-image.html#downloading-an-image)" +"[Quickstart](../1_Quickstart/Quickstart.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://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#detailed-supported-distros)" + "[Supported Linux Distributions](https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#detailed-supported-distros)" section in the Yocto Project Reference Manual. Basically, you should be running a recent version of Ubuntu, Fedora, openSUSE, CentOS, or Debian. @@ -46,11 +38,11 @@ section for more information on the ready-made images. and so forth) as would a properly prepared build host running a supported Linux distribution. For information on how to install and set up this Docker container, see the - "[Setting Up a Docker Container](./docker-container-setup.html)" + "[Setting Up a Docker Container -- FIX ME](./docker-container-setup.html)" section. 2. **Be Sure Your Build Host Has Enough Free Disk Space:** - Your build host should have at least 50 Gbytes. + 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: @@ -60,7 +52,7 @@ section for more information on the ready-made images. * Python 3.4.0 or greater If your distribution does not meet these minimal requirements, see the - "[Required Git, tar, and Python Versions](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#required-git-tar-and-python-versions)" + "[Required Git, tar, and Python Versions](https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#required-git-tar-and-python-versions)" section in the Yocto Project Reference Manual for steps that you can take to be sure you have these tools. @@ -69,13 +61,13 @@ section for more information on the ready-made images. Depending on the Linux distribution you are using, the list of host packages differ. See - "[The Build Host Packages](https://www.yoctoproject.org/docs/2.4.4/yocto-project-qs/yocto-project-qs.html#packages)" + "[The Build Host Packages](https://www.yoctoproject.org/docs/3.1.2/yocto-project-qs/yocto-project-qs.html#packages)" section of the Yocto Project Quick Start for information on the packages you need. **NOTE:** If you are using the CentOS distribution, you need to separately install the epel-release package and run the `makecache` command as described in - "[The Build Host Packages](https://www.yoctoproject.org/docs/2.4.4/yocto-project-qs/yocto-project-qs.html#packages)" + "[The Build Host Packages](https://www.yoctoproject.org/docs/3.1.2/yocto-project-qs/yocto-project-qs.html#packages)" section of the Yocto Project Quick Start. Aside from the packages listed in the previous section, you need the following: diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/2_Downloading_AGL_Software.md b/docs/0_Getting_Started/2_Building_AGL_Image/2_Downloading_AGL_Software.md new file mode 100644 index 0000000..88e6bb1 --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/2_Downloading_AGL_Software.md @@ -0,0 +1,98 @@ +--- +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. + +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 (i.e. Jellyfish), use + the following commands: + + ```sh + $ cd $AGL_TOP + $ mkdir jellyfish + $ cd jellyfish + $ repo init -b jellyfish -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/0_Getting_Started/2_Developing_an_AGL_Image/3_Initializing_Your_Build_Environment.md b/docs/0_Getting_Started/2_Building_AGL_Image/3_Initializing_Your_Build_Environment.md index 7158bfc..d31b3ff 100644 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/3_Initializing_Your_Build_Environment.md +++ b/docs/0_Getting_Started/2_Building_AGL_Image/3_Initializing_Your_Build_Environment.md @@ -1,14 +1,7 @@ --- -edit_link: '' title: Initializing Your Build Environment -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/image-workflow-initialize-build-environment.md --- -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 3. Initializing Your Build Environment - Part of the downloaded AGL software is a setup script that you must run to initialize the build environment. @@ -16,21 +9,20 @@ run to initialize the build environment. You can find this script here: -``` -$AGL_TOP/meta-agl/scripts/aglsetup.sh +```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: -``` -$ bash -$ cd $AGL_TOP +```sh +$ cd $AGL_TOP/master $ source meta-agl/scripts/aglsetup.sh -h ``` -## AGL Machines (= board support) +## 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/*`. @@ -38,7 +30,7 @@ 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 @@ -51,19 +43,22 @@ Available machines: 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) + 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 - raspberrypi3 # Raspberry Pi 3 raspberrypi4 # Raspberry Pi 4 - ``` ## AGL Features @@ -75,7 +70,7 @@ which they reside. Following is a list of the available features: -``` +```sh Available features: [meta-agl] agl-all-features :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-netboot ) @@ -83,48 +78,46 @@ Available features: agl-archiver agl-buildstats agl-ci - agl-ci-change-features :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-devel agl-netboot agl-pipewire agl-buildstats agl-ptest ) - agl-ci-change-features-nogfx :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-devel agl-netboot agl-pipewire agl-buildstats agl-ptest ) + agl-ci-change-features :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-devel agl-netboot agl-pipewire agl-cloudproxy agl-buildstats agl-ptest ) + agl-ci-change-features-nogfx :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-devel agl-netboot agl-pipewire agl-cloudproxy agl-buildstats agl-ptest ) agl-ci-snapshot-features :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-devel agl-netboot agl-archiver agl-pipewire agl-buildstats agl-ptest ) agl-ci-snapshot-features-nogfx :( agl-demo agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework agl-devel agl-netboot agl-archiver agl-pipewire agl-buildstats agl-ptest ) - agl-compositor agl-devel - agl-egvirt agl-fossdriver agl-gplv2 agl-hmi-framework agl-netboot + agl-pipewire agl-profile-cluster :( agl-profile-graphical ) agl-profile-cluster-qt5 :( agl-profile-graphical-qt5 agl-profile-graphical ) agl-profile-graphical + agl-profile-graphical-html5 :( agl-profile-graphical ) agl-profile-graphical-qt5 :( agl-profile-graphical ) agl-profile-hud agl-profile-telematics agl-ptest + agl-sign-wgts agl-sota agl-virt + agl-virt-guest-xen agl-virt-xen :( agl-virt ) + agl-weston-remoting :( agl-profile-graphical ) [meta-agl-cluster-demo] agl-cluster-demo :( agl-profile-cluster-qt5 agl-profile-graphical-qt5 agl-profile-graphical agl-hmi-framework ) agl-cluster-demo-preload [meta-agl-demo] - agl-cluster-demo-support :( agl-gstrecorder ) + agl-cloudproxy + agl-cluster-demo-support :( agl-weston-remoting agl-profile-graphical ) agl-demo :( agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-pipewire agl-speech-framework ) agl-demo-preload agl-demo-soundmanager :( agl-appfw-smack agl-hmi-framework agl-profile-graphical-qt5 agl-profile-graphical agl-audio-soundmanager-framework ) - agl-sdl [meta-agl-devel] - agl-audio-soundmanager-framework - agl-gstrecorder - agl-oem-extra-libs - agl-pipewire - agl-profile-graphical-html5 :( agl-profile-graphical ) + agl-jailhouse agl-speech-framework agl-voiceagent-alexa :( agl-speech-framework ) agl-voiceagent-alexa-wakeword :( agl-voiceagent-alexa agl-speech-framework ) [meta-agl-extra] agl-localdev - blsched [meta-agl-telematics-demo] agl-telematics-demo :( agl-profile-telematics ) ``` @@ -150,7 +143,7 @@ Following are brief descriptions of the AGL features you can specify on the * **agl-ci**: Flags used for Continuous Integration (CI). Using this feature changes the value of the - [`IMAGE_FSTYPES`](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#var-IMAGE_FSTYPES) + [`IMAGE_FSTYPES`](https://yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#var-IMAGE_FSTYPES) variable. * **agl-ci-change-features**: Enables features for CI builds for Gerrit changes. @@ -186,15 +179,15 @@ Following are brief descriptions of the AGL features you can specify on the agl-profile-telematics **NOTE:** For information on Package Groups, see the - "[Customizing Images Using Custom Package Groups](https://www.yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks)" + "[Customizing Images Using Custom Package Groups](https://www.yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks)" section in the Yocto Project Development Tasks Manual. You can also find general information about Layers in the - "[Layers](https://www.yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#yocto-project-layers)" + "[Layers](https://www.yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html#yocto-project-layers)" section in that same manual. --> * **agl-ptest**: Enables - [Ptest](https://yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#testing-packages-with-ptest) + [Ptest](https://yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html#testing-packages-with-ptest) as part of the build. * **agl-sota**: Enables Software Over-the-Air (SOTA) components and dependencies. @@ -222,8 +215,8 @@ Following is an example that initializes the build environment, selects "beagleb for the machine, and chooses the "agl-demo" feature, which also includes the "agl-appfw-smack", "agl-devel", and "agl-hmi-framework" features: -``` -$ source meta-agl/scripts/aglsetup.sh -m qemux86-64 agl-demo agl-devel +```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 @@ -241,11 +234,8 @@ Generating configuration files: 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 @@ -261,13 +251,12 @@ Common targets are: agl-demo-platform (* default demo target) agl-demo-platform-qa agl-demo-platform-crosssdk - agl-demo-platform-html5 -$ ``` Running the script creates the Build Directory if it does not already exist. -For this example, the Build Directory is "$AGL_TOP/workspace_agl/build". +The 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. @@ -291,10 +280,10 @@ You can find lots of information on configuring builds in the Yocto Project documentation set. Here are some references if you want to dig into configuration further: -* [Customizing Images Using local.conf](https://yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconf) -* [Local](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#ref-varlocality-config-local) -* [build/conf/local.conf](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#structure-build-conf-local.conf) -* [build/conf/bblayers.conf](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf) -* [BBLAYERS](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#var-BBLAYERS) -* [User Configuration](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#user-configuration) -* [Enabling Your Layer](https://yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#enabling-your-layer) +* [Customizing Images Using local.conf](https://yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconf) +* [Local](https://yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#ref-varlocality-config-local) +* [build/conf/local.conf](https://yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#structure-build-conf-local.conf) +* [build/conf/bblayers.conf](https://yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf) +* [BBLAYERS](https://yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#var-BBLAYERS) +* [User Configuration](https://yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#user-configuration) +* [Enabling Your Layer](https://yoctoproject.org/docs/3.1.2/dev-manual/dev-manual.html#enabling-your-layer) diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/4_Customizing_Your_Build.md b/docs/0_Getting_Started/2_Building_AGL_Image/4_Customizing_Your_Build.md index 103feeb..2fec0de 100644 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/4_Customizing_Your_Build.md +++ b/docs/0_Getting_Started/2_Building_AGL_Image/4_Customizing_Your_Build.md @@ -1,14 +1,7 @@ --- -edit_link: '' title: Customizing Your Build -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/image-workflow-cust-build.md --- -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 4. 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. @@ -24,11 +17,11 @@ various variables accomplish. To view and customize the `local.conf` file, use any text editor: -```bash -$ vi $AGL_TOP/build/conf/local.conf +```sh +$ vim $AGL_TOP/<release-branch-name>/<build-dir>/conf/local.conf ``` -As mentioned in the "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment.html)" section, +As mentioned in the "[Initializing Your Build Environment](./3_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. @@ -48,13 +41,13 @@ That information is committed to a local Git repository where you can examine it To enable build history, make sure the following two lines are in your `local.conf` file: -```bash +```sh INHERIT += "buildhistory" BUILDHISTORY_COMMIT = "1" ``` See the -"[Maintaining Build Output Quality](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#maintaining-build-output-quality)" +"[Maintaining Build Output Quality](https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#maintaining-build-output-quality)" section in the Yocto Project Reference Manual for a complete discussion on build history. @@ -66,12 +59,12 @@ to remove temporary workspace. You need to inherit the `rm_work` class by using this statement in the `local.conf` file: -```bash +```sh INHERIT += "rm_work" ``` You can read about the class in the -"[rm_work.bbclass](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#ref-classes-rm-work)" +"[rm_work.bbclass](https://www.yoctoproject.org/docs/3.1.2/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 @@ -87,24 +80,23 @@ would not be different as compared to a re-built module. For the AGL build, you can specify the location for sstate files by including the following in the `local.conf` file: -```bash -SSTATE_DIR = "${HOME}/workspace_agl/sstate-cache" +```sh +SSTATE_DIR = "${AGL_TOP}/sstate-cache" ``` -also, in the `local.conf` file, you can specify additional directories in which the build +Also, in the `local.conf` file, you can specify additional directories in which the build system can look for shared state information. Use the following form in your file to list out the directories you want the build process to look at for sstate information: - -```bash +```sh SSTATE_MIRRORS ?= "\ - file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ - file://.* file:///some/local/dir/sstate/PATH" + file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ + file://.* file:///some/local/dir/sstate/PATH" ``` If you want to know more about the Yocto Project sstate mechanism, see the -"[Shared State Cache](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#shared-state-cache)" +"[Shared State Cache](https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#shared-state-cache)" section in the Yocto Project Reference Manual. ## Preserving the Download Directory @@ -114,7 +106,7 @@ from various upstream projects. Downloading these files can take a while, particularly if your network connection is slow. The process downloads files into a -"[download directory](https://www.yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#var-DL_DIR)". +"[download directory](https://www.yoctoproject.org/docs/3.1.2/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. @@ -123,8 +115,8 @@ The default download directory is in a folder named "downloads". For the AGL build you can set the download directory by adding the following to your `local.conf` file: -```bash -DL_DIR = "${HOME}/workspace_agl/downloads" +```sh +DL_DIR = "${AGL_TOP}/downloads" ``` ## Using a Shared State (sstate) Mirror @@ -135,11 +127,25 @@ 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/2.4.4/ref-manual/ref-manual.html#shared-state-cache)" +"[Shared State Cache](https://yoctoproject.org/docs/3.1.2/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/0_Getting_Started/2_Developing_an_AGL_Image/5_Building_the_AGL_Image.md b/docs/0_Getting_Started/2_Building_AGL_Image/5_0_Building_the_AGL_Image.md index b6207f4..a891ef1 100644 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/5_Building_the_AGL_Image.md +++ b/docs/0_Getting_Started/2_Building_AGL_Image/5_0_Building_the_AGL_Image.md @@ -1,14 +1,7 @@ --- -edit_link: '' title: Building the AGL Image -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/image-workflow-build.md --- -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 5. 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. @@ -16,12 +9,13 @@ 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. +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 using Quick EMUlator (QEMU) or VirtualBox: -* [Most Intel-based 64-Bit Boards](./machines/intel.html) -* [Emulation](./machines/qemu.html) -* [R Car Starter Kit Gen3 Board](./machines/renesas.html) -* [Raspberry PI 2 or 3](./machines/raspberrypi.html) +* [x86 (Emulation and Hardware)](./5_1_x86_Emulation_and_Hardware.md) +* [Raspberry Pi 4](./5_2_Raspberry_Pi_4.md) +* [R Car Gen 3](./5_3_RCar_Gen_3.md) + diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/5_1_x86_Emulation_and_Hardware.md b/docs/0_Getting_Started/2_Building_AGL_Image/5_1_x86_Emulation_and_Hardware.md new file mode 100644 index 0000000..0f2121c --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/5_1_x86_Emulation_and_Hardware.md @@ -0,0 +1,216 @@ +--- +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](./3_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: + +**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/ +``` + +**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/ +``` + +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. + +**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 +``` + +**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 +``` + +## 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. + +**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.
\ No newline at end of file diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/5_2_Raspberry_Pi_4.md b/docs/0_Getting_Started/2_Building_AGL_Image/5_2_Raspberry_Pi_4.md new file mode 100644 index 0000000..736666b --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/5_2_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](./3_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](./4_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).
\ No newline at end of file diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/5_3_RCar_Gen_3.md b/docs/0_Getting_Started/2_Building_AGL_Image/5_3_RCar_Gen_3.md new file mode 100644 index 0000000..dc89aaa --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/5_3_RCar_Gen_3.md @@ -0,0 +1,643 @@ +--- +title: Building for R Car Gen 3 +--- + +AGL supports building for several automotive +[Renesas](https://www.renesas.com/us/en/solutions/automotive.html) board kits. +Renesas is the number one supplier of vehicle control microcontrollers and +System on a Chip (SoC) products for the automotive industry. + +This section provides the build and deploy steps you need to create an +image for the following Renesas platforms: + +* [Renesas R-Car Starter Kit Pro Board](https://www.elinux.org/R-Car/Boards/M3SK) +* [Renesas R-Car Starter Kit Premier Board](https://www.elinux.org/R-Car/Boards/H3SK) +* [Renesas Salvator-X Board](https://www.elinux.org/R-Car/Boards/Salvator-X) +* [Renesas Kingfisher Infotainment Board](https://elinux.org/R-Car/Boards/Kingfisher) + +**NOTE:** You can find similar information for the Pro and Premier board kits on the +[R-Car/Boards/Yocto-Gen3](https://elinux.org/R-Car/Boards/Yocto-Gen3) page. +The information on this page describes setup and build procedures for both these +Renesas development kits. + +## 1. Downloading 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. + +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. + + ```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/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. + + | AGL Version| Renesas Version | + | AGL master | 3.21.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/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. + + ```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. + + ```sh + $ chmod a+r $XDG_DOWNLOAD_DIR/*.zip + ``` + +## 2. 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. + +## 3. Making Sure Your Build Environment is Correct + + The + "[Initializing Your Build Environment](./3_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` | + |:-:|:-:| + | Renesas RCar H3 | `MACHINE`= h3ulcb | + | Renesas RCar H3 w Kingfisher Board | `MACHINE`= h3ulcb-kf | + | Renesas RCar H3 w/o gfx blobs | `MACHINE`= h3ulcb-nogfx | + | Renesas RCar Salvator/H3 | `MACHINE`= h3-salvator-x | + | Renesas RCar M3 | `MACHINE`= m3ulcb | + | Renesas RCar M3 w Kingfisher Board | `MACHINE`= m3ulcb-kf | + | Renesas RCar M3 w/o gfx blobs | `MACHINE`= m3ulcb-nogfx | + | Renesas RCar Salvator/M3 | `MACHINE`= m3-salvator-x | + + + For example, the following command defines and exports the `MACHINE` variable + for the Starter Kit Pro/H3 Board: + + ```sh + $ export MACHINE=h3ulcb + ``` + + 2. **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-$MACHINE agl-devel agl-demo + which expands to : + $ source meta-agl/scripts/aglsetup.sh -m h3ulcb -b build-h3ulcb agl-devel agl-demo + ``` + + 3. **Examine the Script's Log:** + + Running the `aglsetup.sh` script creates the `setup.log` file, which is in + the `build-h3ulcb/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. + +## 4. 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. + + For this example, the target is "agl-demo-platform": + + ``` sh + $ time bitbake agl-demo-platform + ``` + + The build process puts the resulting image in the Build Directory: + ``` sh + build-h3ulcb/tmp/deploy/images/$MACHINE + ``` + +## 5. 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 **[R-car h3ulcb firmware update](http://elinux.org/R-Car/Boards/H3SK#Flashing_firmware)** + or **[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. + + * **Preparing the MicroSD Card** + + ```sh + $ lsblk + $ sudo umount <boot_device_name> + $ xzcat agl-image-ivi-crosssdk-h3ulcb.wic.xz | sudo dd of=<boot_device_name> 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. + +## 6. 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 + + Brief about each process : + + 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), and [Minicom](https://en.wikipedia.org/wiki/Minicom). Of these three, "picocom" has less 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. + + ```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: + + ```sh + 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: + + ```sh + 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 + ``` + +## 7. 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 + ``` + + Here is a second example using the **m3ulcb** 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 + filesize=cdeb + initrd_high=0xffffffffffffffff + load_dtb=ext4load mmc 0:1 0x48000000 /boot/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. 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 : + + * **H3SK v2.0(DDR 4GB)** : `$ setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-h3ulcb.dtb` + + * **H3SK v2.0(DDR 8GB)/v3.0(DDR 8GB)** : `$ setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-h3ulcb-4x2g.dtb` + + * **M3SK v1.0** : `$ setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7796-m3ulcb.dtb` + + * **M3SK v3.0** : `$ setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7796-m3ulcb-2x4g.dtb` + + * **H3SK with a Kingfisher board** : `$ setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-h3ulcb-kf.dtb` + + * **M3SK with a Kingfisher board** : `$ setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7796-m3ulcb-kf.dtb` + + 4. Set Correct Environment : + + 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 + ``` + + 5. Save the boot environment: `$ saveenv` + + 6. Boot the board: `$ run bootcmd` + +## 8. 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**: + ```sh + Automotive Grade Linux ${AGL_VERSION} h3ulcb ttySC0 + + h3ulcb login: root + ``` + + **m3ulcb**: + ```sh + 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: + + ```sh + m3ulcb login: root + 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 + ``` + + In the previous example, IP address is 10.0.0.27. + Once you know the address, you can use `ssh` to login. + + ```sh + $ ssh root@10.0.0.27 + ``` + +## 9. Supplementary Information + + * R-Car Generation 3 Information + + Refer to the following for more information from [eLinux website](https://elinux.org/R-Car). + + * Proprietary libraries for meta-rcar-gen3 + + The meta-rcar-gen3 layer of meta-renesas is supported Graphic GLES(GSX) + libraries, proprietary library of multimedia, and ICCOM software. + + 1. 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** + + ```sh + " 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 + ``` + + Ex: + + ```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" + ``` + + 2. 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 local.conf the following. + + ```sh + DISTRO_FEATURES_append = "iccom" + ``` + + diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png Binary files differnew file mode 100644 index 0000000..f4374d0 --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/RaspberryPi2-ModelB-debug-serial-cable.png diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/image-developer-workflow.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/image-developer-workflow.png Binary files differnew file mode 100644 index 0000000..a185dc6 --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/image-developer-workflow.png diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-1.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-1.png Binary files differnew file mode 100644 index 0000000..a43c111 --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-1.png diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-2.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-2.png Binary files differnew file mode 100644 index 0000000..d4e1dd0 --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-2.png diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-3.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-3.png Binary files differnew file mode 100644 index 0000000..f6389f1 --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-3.png diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-4.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-4.png Binary files differnew file mode 100644 index 0000000..09f7f0b --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-4.png diff --git a/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-5.png b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-5.png Binary files differnew file mode 100644 index 0000000..0c3f51b --- /dev/null +++ b/docs/0_Getting_Started/2_Building_AGL_Image/images/vbox-5.png diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/2_Downloading_AGL_Software.md b/docs/0_Getting_Started/2_Developing_an_AGL_Image/2_Downloading_AGL_Software.md deleted file mode 100644 index 2e934a7..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/2_Downloading_AGL_Software.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -edit_link: '' -title: Downloading AGL Software -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/image-workflow-download-sw.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - - - diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/6_Building_for_Most_Intel_64-Bit_Hardware-Platforms.md b/docs/0_Getting_Started/2_Developing_an_AGL_Image/6_Building_for_Most_Intel_64-Bit_Hardware-Platforms.md deleted file mode 100644 index 71eb398..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/6_Building_for_Most_Intel_64-Bit_Hardware-Platforms.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -edit_link: '' -title: Building for Most Intel 64-Bit Hardware Platforms -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/machines/intel.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - - - diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/7_Building_for_Emulation.md b/docs/0_Getting_Started/2_Developing_an_AGL_Image/7_Building_for_Emulation.md deleted file mode 100644 index eabd501..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/7_Building_for_Emulation.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -edit_link: '' -title: Building for Emulation -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/machines/qemu.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Building for Emulation - -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 -``` - -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: - -``` -<build_directory>/tmp/deploy/images/qemux86-64/ - -e.g. - -<build_directory>/tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz -``` - -**Note:** - -If you built your image with bitbake, you can now just use the ``runqemu`` wrapper. - -**Note:** -If you need to run it outside of the bitbake environment or need special settings for -hardware pass-through or the like, read on: - - -## 3. Deploying the AGL Demo Image - -Deploying the image consists of decompressing the image and then -booting it using either QEMU or VirtualBox. - -### 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 -``` - -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. - -### Boot the Image: - -The following steps show you how to boot the image with QEMU or VirtualBox. - -#### QEMU - -Depending on your Linux distribution, use these commands to install 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: - -```bash -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: - -```bash -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: - -```bash -sudo yum install qemu qemu-kvm edk2-ovmf -export OVMF_PATH=/usr/share/edk2/ovmf/OVMF_CODE.fd -``` - -Once QEMU is installed, boot the image with KVM support: - -```bash -qemu-system-x86_64 -enable-kvm -m 2048 \ - -bios ${OVMF_PATH} \ - -hda agl-demo-platform-qemux86-64.wic.vmdk \ - -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. - -#### VirtualBox - -Start by downloading and installing [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 5.2.0 or later. - -Once VirtualBox is installed, follow these steps to boot the image: - -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. Select the newly created **AGL QEMU** machine and click **Settings** -10. Go to the **System** tab and ensure **Enable EFI (special OSes only)** is enabled then click **OK** -11. With the **AGL QEMU** machine still selected, click **Start** to boot the virtual machine diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/8_Build_for_R_Car_Starter_Kit_gen3_board.md b/docs/0_Getting_Started/2_Developing_an_AGL_Image/8_Build_for_R_Car_Starter_Kit_gen3_board.md deleted file mode 100644 index 97f0d84..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/8_Build_for_R_Car_Starter_Kit_gen3_board.md +++ /dev/null @@ -1,912 +0,0 @@ ---- -edit_link: '' -title: Build for R Car Starter Kit gen3 board -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/machines/renesas.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 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. - -## 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 - ``` - - 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. - Use the following table to map the Renesas version to your AGL software: - - | AGL Version| Renesas version | - |:-:|:-:| - | AGL master | 3.21.0 | - | AGL icefish 9.0.0 9.0.1 9.0.2 | 3.21.0 | - | AGL halibut 8.0.2 8.0.3 8.0.4 8.0.5 8.0.6 | 3.21.0 | - | AGL halibut 8.0.1 | 3.19.0 | - | AGL halibut 8.0.0 | 3.15.0 | - | AGL guppy 7.0.4 | 3.21.0 | - | AGL guppy 7.0.3 | 3.19.0 | - | AGL guppy 7.0.0 7.0.1 7.0.2 | 3.9.0 | - | AGL flounder 6.0.3, 6.0.4 6.0.5 | 3.9.0 | - | AGL flounder 6.0.0, 6.0.1, 6.0.2 | 3.7.0 | - | AGL eel 5.0.x, 5.1.0| 2.23.1 | - | AGL dab 4.0.x |2.19.0 | - - **NOTE:** - 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. - -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+r $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-r--r-- 1 iot bzh 5431245 sept. 16 21:07 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston5-20190802.zip - -rw-r--r-- 1 iot bzh 3442158 sept. 16 21:07 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston5-20190802.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. - -## 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. - -<details> - <summary> In case of missing graphics drivers, you could notice an error message - similar to the following:</summary> - <pre> - <code> -[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-weston5-20190802.zip - R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston5-20190802.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] - </code> - </pre> -</details> - - 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. - -<details> - <summary>Here is another example that indicates the driver files could not be extracted from the downloads directory:</summary> - <pre> - <code> -[snip] - -~/workspace_agl/build/conf $ cat setup.log ---- beginning of setup script ---- fragment /home/iotbzh/workspace_agl/meta-agl/templates/base/01_setup_EULAfunc.sh ---- fragment /home/iotbzh/workspace_agl/meta-agl/templates/machine/m3ulcb/50_setup.sh -~/workspace_agl ~/workspace_agl/build -ERROR: FILES "+/home/iotbzh/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston5-20190802.zip+" NOT EXTRACTING CORRECTLY -ERROR: FILES "+/home/iotbzh/Downloads/R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston5-20190802.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/iotbzh/Downloads' directory. - R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-weston5-20190802.zip - R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-weston5-20190802.zip -ERROR: Script /home/iotbzh/workspace_agl/build/conf/setup.sh failed -[snip] - </code> - </pre> -</details> - -## 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: - -```bash -<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: - -```bash -<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 - -<details> - <summary> - Plug the MicroSD card into your Build Host. - After plugging in the device, use the `dmesg` command as follows to - discover the device name: - </summary> - <pre> - <code> -$ 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 - </code> - </pre> -</details> - -In the previous example, the MicroSD card is attached to the device `/dev/sdc`. - -<details> - <summary> - You can also use the `lsblk` command to show all your devices. - Here is an example that shows the MicroSD card as `/dev/sdc`: - </summary> - <pre> - <code> -$ 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 - </code> - </pre> -</details> - -**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. - -<details> - <summary> - 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: - </summary> - <pre> - <code> -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 - </code> - </pre> -</details> - -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: - -<details> - <summary> - h3ulcb: - </summary> - <pre> - <code> - -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 -=> - </code> - </pre> -</details> - -<details> - <summary> - m3ulcb: - </summary> - <pre> - <code> -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 -=> - </code> - </pre> -</details> - -## 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: - -<ol> - <li>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. - </li> - - <li>Once the autoboot process is interrupted, use the board's serial console to - enter <b>printenv</b> to check if you have correct parameters for booting your board: -<details> - <summary> - Here is an example using the <b>h3ulcb</b> board: - </summary> - <pre> - <code> - -=> 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 - </code> - </pre> -</details> -<details> - <summary> - Here is a second example using the <b>m3ulcb</b> board: - </summary> - <pre> - <code> -=> 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/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 - </code> - </pre> -</details> - </li> - - <li>To boot your board using the MicroSD card, be sure your environment is set up - as follows: - - <pre> - <code> - 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 - </code> - </pre> - </li> - - <li>Depending on the board type, the BSP version, and the existence of - a Kingfisher board, make sure your ``load_dtb`` is set as follows:<br> - - <b>h3ulcb with BSP version greater than or equal to 2.19</b>: - - <pre> - <code> - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-es1-h3ulcb.dtb - </code> - </pre> - - <b>h3ulcb with BSP version less than 2.19</b>: - - <pre> - <code> - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-h3ulcb.dtb - </code> - </pre> - - <b>m3ulcb</b>: - <pre> - <code> - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7796-m3ulcb.dtb - </code> - </pre> - - <b>m3ulcb with a Kingfisher board</b>: - <pre> - <code> - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7796-m3ulcb-kf.dtb - </code> - </pre> - - <b>h3ulcb with a Kingfisher board</b>: - <pre> - <code> - setenv load_dtb ext4load mmc 0:1 0x48000000 /boot/r8a7795-es1-h3ulcb-kf.dtb - </code> - </pre> - </li> - - <li>Save the boot environment:<br> - <code> - saveenv - </code> - </li> - - <li>Boot the board:<br> - <code> - run bootcmd - </code> - </li> -</ol> - -## 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`. - -<details> - <summary> - Here is an example for the m3ulcb board: - </summary> - <pre> - <code> - 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:~# - </code> - </pre> -</details> - -<details> - <summary> - 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: - </summary> - <pre> - <code> - $ 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)" - </code> - </pre> -</details> - -**NOTE:** More generics troubleshooting can be found here : [Generic issues](../troubleshooting.html)
\ No newline at end of file diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/9_Building_for_Raspberry_Pi_3_or_4.md b/docs/0_Getting_Started/2_Developing_an_AGL_Image/9_Building_for_Raspberry_Pi_3_or_4.md deleted file mode 100644 index 534f644..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/9_Building_for_Raspberry_Pi_3_or_4.md +++ /dev/null @@ -1,293 +0,0 @@ ---- -edit_link: '' -title: Build for Raspberry PI 3/4 -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/machines/raspberrypi.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Building for Raspberry Pi 3 or 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 3](https://www.raspberrypi.org/products/raspberry-pi-3-model-a-plus/) and the -[Raspberry Pi 4](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/) 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. - -This section describes the steps you need to take to build the -AGL demo image for both the Raspberry Pi 4 and 3 boards. Raspberry Pi 4 is recommended. - -## 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 4 (recommended) or 3: - -**Raspberry Pi 4**: - -```bash -$ source meta-agl/scripts/aglsetup.sh -m raspberrypi4 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/* -``` - - -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. -Here is example for the Raspberry Pi 4 board: - -``` -<build_directory>/tmp/deploy/images/raspberrypi4/agl-demo-platform-raspberrypi4.wic.xz -``` - -If you build for the Raspberry Pi 3 board, the location uses "raspberrypi3" 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 3 or 4 board: - -1. Plug your MicroSD card into your Build Host (i.e. the system that has your build output). - -2. Be sure you know the MicroSD device name. - - Use the `dmesg` command as follows to discover the device name: - - ```bash - $ dmesg | tail -4 - [ 1971.462160] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 - [ 1971.462277] sd 6:0:0:0: [sdc] No Caching mode page found - [ 1971.462278] sd 6:0:0:0: [sdc] Assuming drive cache: write through - [ 1971.463870] sdc: sdc1 sdc2 - ``` - - In the previous example, the MicroSD card is attached to the device `/dev/sdc`. - - You can also use the `lsblk` command to show all your devices. - Here is an example that shows the MicroSD card as `/dev/sdc`: - - ```bash - $ lsblk - NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT - sda 8:0 0 167,7G 0 disk - ├─sda1 8:1 0 512M 0 part /boot/efi - ├─sda2 8:2 0 159,3G 0 part / - └─sda3 8:3 0 7,9G 0 part [SWAP] - sdb 8:16 0 931,5G 0 disk - └─sdb1 8:17 0 931,5G 0 part /media/storage - sdc 8:32 1 14,9G 0 disk - ├─sdc1 8:33 1 40M 0 part - └─sdc2 8:34 1 788M 0 part - ``` - - **IMPORTANT NOTE:** Before re-writing any device on your Build Host, you need to - be sure you are actually writing to the removable MicroSD card and not some other - device. - Each computer is different and removable devices can change from time to time. - Consequently, you should repeat the previous operation with the MicroSD card to - confirm the device name every time you write to the card. - - To summarize this example so far, we have the following: - - * The first SATA drive is `/dev/sda`. - - * `/dev/sdc` corresponds to the MicroSD card, and is also marked as a removable device. - You can see this in the output of the `lsblk` command where "1" appears in the "RM" column - for that device. - -3. Now that you know the device name, unmount the device and use the - `xzcat` command to copy the image to the MicroSD card. - - **NOTE:** For Raspberry Pi 3, the image is at `build/tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.wic.xz`. - For Raspberry Pi 4, the image is at `build/tmp/deploy/images/raspberrypi4/agl-demo-platform-raspberrypi4.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 -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 -``` - -## 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 - ``` - -## 7. 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/0_Getting_Started/2_Developing_an_AGL_Image/images/image-developer-workflow.png b/docs/0_Getting_Started/2_Developing_an_AGL_Image/images/image-developer-workflow.png Binary files differdeleted file mode 100644 index c4f6853..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/images/image-developer-workflow.png +++ /dev/null diff --git a/docs/0_Getting_Started/2_Developing_an_AGL_Image/under-construction.png b/docs/0_Getting_Started/2_Developing_an_AGL_Image/under-construction.png Binary files differdeleted file mode 100644 index 0c514ff..0000000 --- a/docs/0_Getting_Started/2_Developing_an_AGL_Image/under-construction.png +++ /dev/null diff --git a/docs/0_Getting_Started/3_ HomeScreen/Overview.md b/docs/0_Getting_Started/3_ HomeScreen/Overview.md deleted file mode 100644 index f7c8d04..0000000 --- a/docs/0_Getting_Started/3_ HomeScreen/Overview.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -edit_link: '' -title: Overview -origin_url: >- - https://git.automotivelinux.org/apps/homescreen/plain/homescreen/docs/index.md?h=master ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/apps-homescreen-homescreen-book.yml --> - -# Welcome to your AGL system! -When booting up an AGL system, the first thing that your eyes will spot is this: - - - -**The AGL HomeScreen!** - -Intended to be used with touch presses, the reference HMI provides access to all pre-installed AGL demo applications as well as in the future access to user installed apps. The list of demo apps contains some automotive applications like HVAC-control, Navigation or Dashboard, as well as some infotainment apps. Radio, Multimedia, Phone... -This applications are already available and were presented at CES 2017. - -## Here are some screenshots of the pre-installed demo applications: - -## HVAC - - - -## Phone - - - -## Dashboard - - - -## Settings - - - -#### Note: -* All current demos (including HomeScreen) are optimized for landscape full HD resolution (1080x1920). - diff --git a/docs/0_Getting_Started/3_ HomeScreen/pictures/dashboard.png b/docs/0_Getting_Started/3_ HomeScreen/pictures/dashboard.png Binary files differdeleted file mode 100644 index 527386d..0000000 --- a/docs/0_Getting_Started/3_ HomeScreen/pictures/dashboard.png +++ /dev/null diff --git a/docs/0_Getting_Started/3_ HomeScreen/pictures/homescreen_applauncher.png b/docs/0_Getting_Started/3_ HomeScreen/pictures/homescreen_applauncher.png Binary files differdeleted file mode 100644 index e168668..0000000 --- a/docs/0_Getting_Started/3_ HomeScreen/pictures/homescreen_applauncher.png +++ /dev/null diff --git a/docs/0_Getting_Started/3_ HomeScreen/pictures/hvac.png b/docs/0_Getting_Started/3_ HomeScreen/pictures/hvac.png Binary files differdeleted file mode 100644 index f9a6030..0000000 --- a/docs/0_Getting_Started/3_ HomeScreen/pictures/hvac.png +++ /dev/null diff --git a/docs/0_Getting_Started/3_ HomeScreen/pictures/phone.png b/docs/0_Getting_Started/3_ HomeScreen/pictures/phone.png Binary files differdeleted file mode 100644 index e087594..0000000 --- a/docs/0_Getting_Started/3_ HomeScreen/pictures/phone.png +++ /dev/null diff --git a/docs/0_Getting_Started/3_ HomeScreen/pictures/settings.png b/docs/0_Getting_Started/3_ HomeScreen/pictures/settings.png Binary files differdeleted file mode 100644 index c92d835..0000000 --- a/docs/0_Getting_Started/3_ HomeScreen/pictures/settings.png +++ /dev/null diff --git a/docs/0_Getting_Started/4_Troubleshooting/Generic_issues.md b/docs/0_Getting_Started/4_Troubleshooting/Generic_issues.md deleted file mode 100644 index fd84c2f..0000000 --- a/docs/0_Getting_Started/4_Troubleshooting/Generic_issues.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -edit_link: '' -title: Generic issues -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/troubleshooting.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Troubleshooting - -This topic describes various areas that could cause you problems. - -## Including Extended Attributes - -The -[Extended Attributes Set (`xattrs`)](https://linux-audit.com/using-xattrs-extended-attributes-on-linux/) -associated with the image during its construction must be copied to -the bootable media. -The `xattrs` supports -[Smack](https://en.wikipedia.org/wiki/Smack_(software)), which is a -Simplified Mandatory Access Control kernel. - -**NOTE:** See - [https://www.kernel.org/doc/Documentation/security/Smack.txt](https://www.kernel.org/doc/Documentation/security/Smack.txt). - for detailed information on Smack. - -**NOTE:** SMACK is a required feature for the AGL Application Framework. - -Many methods exist that allow you to create bootable media (e.g. `dd`, `bmaptools`, -`tar`). -It is recommended that you do not use `tar` to create bootable media. -However, if you do, you must take these steps to copy `xattrs` to the media: - -1. Verify your `tar` version is 1.28 or newer: - - ```bash - $ tar --version - tar (GNU tar) 1.28 - [snip] - ``` - -2. Optionally update `tar` if required. - Most systems come with `tar` installed. - If you need to install it, see the - "[Installing tar](https://www.howtoforge.com/tutorial/linux-tar-command/#installing-tar)" - section for instructions. - - When you build an AGL distribution, a native up-to-date version of - `tar` is created. - Use the following command to see that version: - - ```bash - $ tmp/sysroots/x86_64-linux/usr/bin/tar-native/tar --version - tar (GNU tar) 1.28 - [snip] - ``` - -3. Copy the AGL files and Extended Attributes Set to your bootable media: - - ```bash - $ tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --totals \ - --xattrs-include='*' --directory=DESTINATION_DIRECTORY --file=agl-demo-platform.....tar.xz - ``` - -## Screen orientation for Splash and in Weston - -Depending of your scren mounting the default orientation of the UI an/or splash screen might be incorrect. -To change the orientation of the splash screen patch - -```bash -File: /etc/systemd/system/sysinit.target.wants/psplash-start.service -Line: ExecStart=/usr/bin/psplash -n -a 90 -``` - -To change the orientation of the UI in Weston patch - -```bash -File: /etc/xdg/weston/weston.ini -Line: transform=90 -``` - -## Adding media files to play with MediaPlayer - -AGL include the default MediaPlayer sample app which can be used to play music. The `lightmediascanner.service` by default will search for media under the `/media` folder. So if you plug in any USB stick containing music, they would be recognized and showed in the playlist of the MediaPlayer app menu. - -The current supported format is OGG. Please convert your files to ogg to play with MediaPlayer. - -**NOTE**: mp3 is not found by default. For this you need to enable the flags for mp3 support. - -In case you want to store music in another place, modify the `/usr/lib/systemd/user/lightmediascanner.service` file and change the `--directory` parameter to the path of that folder. - -If you don’t want to touch the ligthmediascanner service, you can also add a folder named "Music" under `/home/1001/Music` and put your music files there. - -## Configuring the Audio hardware - -AGL uses alsa as Audio configuration master. If the correct HW is not setup, the Audio system will fail to start what will also fails the demo Home Screen launch. -You need to configure Audio in - -* pipewire - -### pipewire - -AGL does use the new pipewire infrastructure for sound. -The configuration is in: - -* `/etc/pipewire/` -and -* `/etc/wireplumber/` - -Please see https://git.automotivelinux.org/AGL/meta-agl-devel/tree/meta-pipewire/recipes-multimedia/wireplumber/wireplumber-board-config-agl . diff --git a/docs/0_Getting_Started/5_Setting_Up_a_Docker_Container/Docker_Container_Setup.md b/docs/0_Getting_Started/5_Setting_Up_a_Docker_Container/Docker_Container_Setup.md deleted file mode 100644 index 80eb271..0000000 --- a/docs/0_Getting_Started/5_Setting_Up_a_Docker_Container/Docker_Container_Setup.md +++ /dev/null @@ -1,285 +0,0 @@ ---- -edit_link: '' -title: Overview -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/docker-container-setup.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Overview - -This section explains how to quickly setup a Docker container environment -suitable for using the Yocto Project build system. -Within the container environment you can build images using BitBake -and create and package AGL applications with a Software Development -Kit (SDK) specifically tailored for your target hardware. - -Docker is an open source tool designed to make it easier to create, deploy, -and run applications by using containers. -Containers allow a developer to package up an application with all -the parts it needs, such as libraries and other dependencies, and ship -it all out as one package. - -The container you set up here is configured for Yocto Project and AGL. -This configuration means you do not have to have a native Linux build -host. -You can use a system running Microsoft or MacOS. - -You can learn more about Docker on the -[Docker Documentation](https://docs.docker.com/) site. - -**NOTE:** The information in this section has been tested using a Linux -system. -However, as previously mentioned, you could set up a Docker container -that works using Windows or MacOS. - -## 1. Installing Docker Community Edition (CE) - -If your build host does not already have -[Docker CE](https://docs.docker.com/install/) installed, you must install it. - -You can find general instructions for installing Docker CE on a Linux system -on the [Docker Site](https://docs.docker.com/engine/installation/linux/). - -You need to download the Docker CE version particular to your operating system. -For example, if you are running the Ubuntu 16.04 Linux distribution, you can -click the appropriate -[Supported Platform](https://docs.docker.com/install/#supported-platforms) checkmark -and see the instructions you need to install Docker CE on that platform. - -Follow the steps to install Docker CE for your particular distribution. -For example, the -[Get Docker CE for Ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/) -page describes how to install Docker CE on a build host running the Ubuntu -distribution. - -Successful Docker installation is measured by the results of running a "hello world" -application: - -```bash -$ sudo docker run hello-world -Hello from Docker! -This message shows that your installation appears to be working correctly. - -To generate this message, Docker took the following steps: - 1. The Docker client contacted the Docker daemon. - 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. - (amd64) - 3. The Docker daemon created a new container from that image which runs the - executable that produces the output you are currently reading. - 4. The Docker daemon streamed that output to the Docker client, which sent it - to your terminal. - -To try something more ambitious, you can run an Ubuntu container with: - $ docker run -it ubuntu bash - -Share images, automate workflows, and more with a free Docker ID: - https://hub.docker.com/ - -For more examples and ideas, visit: - https://docs.docker.com/get-started/ -``` - -## 2. Setting Up to Use Docker as a Non-Root User - -For Linux machines, Docker runs as a root user by default. -You can create a docker group and add yourself to it so that you do not -have to preface every `docker` command with `sudo`, for example. - -Follow the instructions on the -[Post-installation steps for Linux](https://docs.docker.com/install/linux/linux-postinstall/) -page for information on how to create a Docker group and add yourself to the group. - -Once you have set up to use Docker as a non-root user, you can log out of your -system, log back in, and run the "hello world" application again to verify you -do not have to use root: - -```bash -$ docker run hello-world -Hello from Docker! -This message shows that your installation appears to be working correctly. - -To generate this message, Docker took the following steps: - 1. The Docker client contacted the Docker daemon. - 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. - (amd64) - 3. The Docker daemon created a new container from that image which runs the - executable that produces the output you are currently reading. - 4. The Docker daemon streamed that output to the Docker client, which sent it - to your terminal. - -To try something more ambitious, you can run an Ubuntu container with: - $ docker run -it ubuntu bash - -Share images, automate workflows, and more with a free Docker ID: - https://hub.docker.com/ - -For more examples and ideas, visit: - https://docs.docker.com/get-started/ -``` - -## 3. Setting Up a Persistent Workspace - -Docker images are pre-configured to use a particular User Identifier (uid) and -Group Identifier (gid) that allow the Container to use the Yocto Project -build system. -The `uid:gid` provides a dedicated user account *devel*, -which belongs to `uid=1664(devel)` and `gid=1664(devel)`. - -**NOTE:** The password is `devel`. - -The `create_container.sh` script as shown in the following -section instantiates a new container and shares the following -volumes with the build host: - -* **/xdt:** - The build directory inside the container. - This directory is stored in **~/ssd/xdt_$ID**, which is specific to - the container's instance ID. - -* **/home/devel/mirror:** - A development mirror stored in **~/ssd/localmirror_$ID**, - which is specific to the container's instance ID. - -* **/home/devel/share:** - A development share at **~/devel/docker/share**, which is shared - by all containers. - -These shared volumes need the proper permissions in order form them -to be accessible from the container environment. -You can make sure permissions are in order using the following commands: - -```bash -$ mkdir ~/ssd ~/devel -$ chmod a+w ~/ssd ~/devel -``` - -**Note**: - -* To gain access from your host on files created within the container, your - host account requires to be added to group id 1664. - -## 4. Getting the Generic AGL Worker Docker Image - -You can either locate and install a pre-built image or rebuild the image. - -### Using a Pre-Built Image - -Use the `wget` command to download the latest pre-built Docker image -into your local Docker instance. -Here is an example: - -```bash -$ wget -O - https://download.automotivelinux.org/AGL/snapshots/sdk/docker/docker_agl_worker-latest.tar.xz | docker load -$ docker images - REPOSITORY TAG IMAGE ID CREATED SIZE - docker.automotivelinux.org/agl/worker-generic 5.99-95 6fcc19b4e0d7 2 weeks ago 1.56GB - jenkins latest 55720d63e328 5 weeks ago 711.9 MB - hello-world latest c54a2cc56cbb 5 months ago 1.848 kB -``` - -After loading the image, identify and export the `IMAGE_ID`. -For example, the `IMAGE_ID` given the previous command is "6fcc19b4e0d7". - -```bash -$ export IMAGE_ID=6fcc19b4e0d7 -``` - -### Building an Image - -You can build the Docker image using the -[docker-worker-generator](https://git.automotivelinux.org/AGL/docker-worker-generator/) -scripts. - -## 5. Starting the Container - -After you have the image available, use the -`create_container` script to start a new, fresh container that is -based on the AGL Worker image: - -**NOTE:** -The password for the ID "devel" inside the docker image is "devel". - -```bash -$ git clone https://git.automotivelinux.org/AGL/docker-worker-generator -$ cd docker-worker-generator -$ ./contrib/create_container 0 $IMAGE_ID -$ docker ps -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -4fb7c550ad75 6fcc19b4e0d7 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx -``` - -## 6. Installing the AGL SDK for Your Target - -Once you have a new container that is based on the AGL Worker Image, you -can copy the SDK Installer to the container and then install -the target-specific AGL SDK. -With an SDK installed, you are able to develop AGL applications -using the SDK. - -For this section, assume that the SDK is `agl-demo-platform-crosssdk` and was built -according to the instructions in the -"[Download or Build Your SDK Installer](./app-workflow-sdk.html)" -section. - -Follow these steps: - -1. **Copy the SDK Installer to the Shared Volume: - -<!-- - -This is part of the example from the original file. -It shows building out the SDK from a container. - -For example, we could have built the SDK from another worker container listening with SSH on port 2223: - -```bash -create_container 1; -ssh -p 2223 devel@mybuilder.local; -... [ prepare build environment ] ... -bitbake agl-demo-platform-crosssdk; -... [ build happens in /xdt/build ] ... -``` ---> - - ``` - $ cp /xdt/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh ~/share - ``` - -2. Log into your "SDK Container" and install the SDK: - - ```bash - $ ssh -p 2222 devel@mysdk.local - $ install_sdk ~/share/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf-neon-toolchain-3.0.0+snapshot.sh - ``` - -## 7. Build Your Application - -Once you have the SDK installed in your container, you are ready -to develop your application. -See the -"[Create and Build the Application](./app-workflow-build-app.html)" -section for more information. - - -<!-- - -This stuff is leftover from the original file. -It is pretty generic and I don't think we need to retain it. - -First, you must source the SDK environment you wish to use (you MUST repeat this step each time you open a new shell): - -```bash -source /xdt/sdk/environment-setup-<your_target> -``` - -You're then ready to go: get the sources, run the builds ... - -```bash -git clone <your repo for your app>; -cd <your app>; -cmake; make; make package; -``` - ---> diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /0_Overview.md b/docs/0_Getting_Started/6_ Developing_an_Application /0_Overview.md deleted file mode 100644 index d085937..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /0_Overview.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -edit_link: '' -title: Overview -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-intro.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Overview # - -The application development workflow begins with securing the image -that runs on your hardware and finishes with debugging the application -as it runs on that hardware. - -The following figure and list overview the application development -process. -You can learn about the steps in the process by reading through the -remaining sections. - -**NOTE:** This procedure uses information from many other procedures -in the AGL Documentation set. -Links are provided when a set of steps is required that is documented -elsewhere. - -{:: style="margin:auto; display:flex"} - -1. Download or build the image you are going to run on the hardware device. - -2. Download or build the Software Development Kit (SDK) you use to create your application. - -3. Create bootable media using your image. - -4. Boot your hardware device with the media. - -5. Prepare your environment so that you can develop an application. - You can develop the application using XDS or using a stand-alone SDK. - -6. Create your application. - -7. Deploy the application to your hardware. - -8. Debug the application. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md b/docs/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md deleted file mode 100644 index a4d4303..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /1_Download_or_Build_Your_Image.md +++ /dev/null @@ -1,172 +0,0 @@ ---- -edit_link: '' -title: Download or Build Your Image -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-image.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 1. Download or Build Your Image # - -You need to have an image that you can run on your hardware device. -You can either build that image from scratch or, if you are going to use -hardware supported by AGL, you can download a ready-made image from the -[AGL Download Website](https://download.automotivelinux.org/AGL/release/) site. - -## Downloading an image ## - -For a look at the supported images, go to the -[AGL Download Website](https://download.automotivelinux.org/AGL/release/). -You can explore that hierarchy and locate images based on the AGL release and the supported hardware. - -The following list summarizes the pre-built image support: - -* **[Quick EMUlator (QEMU)](https://www.qemu.org/):** -QEMU is a generic, open source machine emulator and virtualizer. -You can use QEMU as your "hardware" when you run an image built for -the emulator. -AGL supports QEMU images for ARM 32/64bit and Intel 64bit -devices. - -* **[R-Car Gen3 Ultra Low-Cost Board](https://www.elinux.org/R-Car/Boards/M3SK , https://www.elinux.org/R-Car/Boards/H3SK):** -The M3ULCB/H3ULCB is a Renesas R-Car Gen3 SOC development board. -Depending on the SOC specialization, Renesas provides several classes -of these boards. -The "M" classification is for the "middle-end" version as compared to the -"H" classification, which is a "high-end" version. - -* **[Raspberry Pi 4](https://www.raspberrypi.org/products/):** -The Raspberry Pi 4 uses a 64-bit quad-core processor. -The board features dual-band wireless LAN, Bluetooth 4.2/BLE, -faster Ethernet, and Power-over-Ethernet support with separate PoE HAT. - -* **[x86-64]:** -Any x86-64 hardware is supported. We recommend e.g. the Up² board. - -* **[DRA7xx Evaluation Module Platform](http://www.ti.com/tool/J6EVM5777):** -Texas Instruments Jacinto™ DRA7xx evaluation module platform helps speed up -development efforts and reduces time-to-market for applications -such as infotainment, reconfigurable digital cluster, or integrated digital -cockpit. - - - -If you want to use QEMU or you are developing an application for one the -supported hardware board types, you might consider skipping the build -step, which is described below, and just download your image. - -As an example, suppose you want to download the 64-bit ARM-based image -that you can emulate using QEMU. -Go to the [AGL Download Website](https://download.automotivelinux.org/AGL/release/) -site and follow these links: - -``` -icefish -> 9.0.0 -> qemuarm64 -> deploy -> images -> qemuarm64 -``` - -From the list, you could download the ``Image-qemuarm64.bin`` Kernel and the -``agl-demo-platform-crosssdk-qemuarm64.ext4.xz``Image file. - - -## Building an image ## - -Building the image from scratch requires system preparation, build configuration, and then the build itself. -Building an image for the first time can take many hours. - -The following procedure describes how to build your image: - -1. **Prepare Your System:** Your system, known as a "build host" needs to meet some requirements - in order to build images in the AGL environment. - The "[Preparing Your Build Host](./image-workflow-prep-host.html)" - section describes in detail how to make sure your system meets - these requirements. - - In summary, do the following to prepare your system: - - * Be sure that your build system runs a modern version of a supported Linux Distribution. - For a list of supported distributions, see the - "[Supported Linux Distributions](https://yoctoproject.org/docs/2.4.4/ref-manual/ref-manual.html#detailed-supported-distros)" - section in the Yocto Project Reference Manual. - - **NOTE:** Building images using AGL software leverages off the - [Yocto Project](https://www.yoctoproject.org/), which is an Open Source project used to create small, embedded distributions. - - * Be sure that you have updated versions of Tar, Git, Python, and the GNU Compiler Collection (GCC). - - * Install required packages on the build host. - This list of packages depends on the particular Linux Distribution your build host uses. - See the - "[Preparing Your Build Host](./image-workflow-prep-host.html)" - section for the packages you need to install for your specific - distribution. - - **NOTE:** The definitive package requirements are documented in the - "[Required Packages for the Host Development System](https://yoctoproject.org/docs/latest/ref-manual/ref-manual.html#required-packages-for-the-host-development-system)" - section of the Yocto Project Reference Manual. - -2. **Download the AGL source code:** Getting the AGL source code involves creating an - isolated work directory, securing the "repo" tool, and finally - using Git to download the source code into a cloned local repository. - - Be sure to consider the source code version before downloading the source. - If you want the cutting edge version of the AGL source code, download the "master" branch. - Otherwise, download the latest stable AGL release. - - You can see example steps in the - "[Download AGL source code](./image-workflow-download-sw.html)" - section. - -3. **Initialize the build environment:** The build process assumes many environment - variable settings, tools, tool locations, and file hierarchies. - Once the AGL software is on your local system, you need to run the build - setup script (i.e. ``aglsetup.sh``) to establish environment variables - and paths used during the build process. - - Because the script accepts options that define the features used in your - build environment, you need to understand what features you want - before running the script. - For information on running the script and on the features you can choose, - see the - "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html)" - section. - -4. **Customize your build configuration:** Aside from environment variables - and parameters, build parameters and variables need to be defined before - you start the build process. - These parameters (configurations) are defined in the ``local.conf`` - configuration file. - In general, the defaults in that file are good enough. - However, you can customize aspects by editing the ``local.conf`` file. - See the - "[Customizing Your Build](./image-workflow-cust-build.html)" - section for the location of the file and a list of common customizations. - - **NOTE:** For detailed explanations of the configurations you can make - in the ``local.conf`` file, consult the - [Yocto Project Documentation](https://www.yoctoproject.org/docs/). - -5. **Building the image:** You use - [BitBake](https://yoctoproject.org/docs/2.4.4/bitbake-user-manual/bitbake-user-manual.html) - to build the image. - BitBake is the engine used by the Yocto Project when building images. - The command used to build the image is ``bitbake``. - - For example, the following command builds the image for the AGL demo platform, - which is an image you can emulate using QEMU: - - ``` - $ bitbake agl-demo-platform - ``` - - As previously mentioned, building a new image can take a long time. - An initial build could take hours. - Once the image has been initially built, re-builds are much quicker as - BitBake takes advantage of cached artifacts. - - The build image resides in the deployment area of the build directory. - For example, Assuming your top-level AGL directory is ``~/workspace_agl``, you find the image here: - - ``` - ~/workspace_agl/build/tmp/deploy/images/qemux86-64/ - ``` diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /2_Download_or_Build_Your_SDK_Installer.md b/docs/0_Getting_Started/6_ Developing_an_Application /2_Download_or_Build_Your_SDK_Installer.md deleted file mode 100644 index ef29bf2..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /2_Download_or_Build_Your_SDK_Installer.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -edit_link: '' -title: Download or Build Your SDK Installer -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-sdk.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 2. Download or Build Your SDK Installer # - -The Software Development Kit (SDK) allows you to use your build host -to develop an application specific to your target hardware. -SDKs are installed onto your build host by running an SDK installer -file (``*.sh``). - -You must either download a pre-built installer file for your SDK or -build an installer file. -If you are developing an application for a board supported by the AGL software, you might -want to just download a pre-built SDK installer file. -If your hardware is not supported by AGL, you need to build the SDK installer file. - -## Downloading a pre-built SDK Installer ## - -For a look at the SDK installers for supported boards, go to the -[AGL Download Website](https://download.automotivelinux.org/AGL/release/). -From there, you can explore to find the SDK installer you want to download. -As an example, consider using a pre-built SDK to develop applications suited for a 64-bit -ARM-based board that you want to emulate using QEMU. -Furthermore, you are using the 8.0.0 "Halibut" release of the AGL software. -Follow these links: - -``` -halibut -> 8.0.0 -> qemuarm64 -> deploy -> sdk -``` - -From the list, you download the ``*.sh`` file, which is an installation script for the SDK. -Running the SDK installer script installs the SDK onto your build host. - -SDK installation scripts have long names that reflect the platform specifics. -For example, the following file installs the SDK given the specifics earlier: - -``poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-aarch64-toolchain-8.0.0.sh`` - -**NOTE:** If you want to know more about SDK installer file naming, which is a result of -BitBake and the Yocto Project, see the -"[Locating Pre-Built SDK Installers](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html#sdk-locating-pre-built-sdk-installers)" -section in the Yocto Project documentation. - -## Building an SDK Installer ## - -If you cannot find a pre-built SDK installer for your hardware, you need to build one. -In this case, use BitBake in a similar manner used to build the image. -See the -"[Building an image](./app-workflow-image.html#building-an-image)" -section for information on building an image with BitBake. - -The only difference between building the image and the SDK installer -is the target you give BitBake on the command line and the final location of -the ``*.sh`` file. -Following is the command that you use to build the SDK installer for ``agl-demo-platform``: - -``` -$ bitbake agl-demo-platform-crosssdk -``` - -The SDK installer file (``*.sh``) is placed in the build directory. -Assuming your top-level workspace is ``~/workspace_agl``, here is an example location -and SDK installer file: - -``` -~/workspace_agl/build/tmp/deploy/sdk/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-aarch64-toolchain-8.0.0.sh -``` diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /3_Create_Bootable_Media.md b/docs/0_Getting_Started/6_ Developing_an_Application /3_Create_Bootable_Media.md deleted file mode 100644 index c801253..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /3_Create_Bootable_Media.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -edit_link: '' -title: Create Bootable Media -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-bootables.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 3. Create Bootable Media # - -In order to test an application, your device must be running the image and, of course, -the application. -To run the image, you need to create a bootable image that can be launched -from an external device such as an SD card or USB stick. - -The following list overviews the process. - -1. Insert your media into the appropriate build host interface (e.g. USB port). -2. Determine the device name of your portable media (e.g. ``sdb``). -3. Write out the image using e.g. ``etcher`` , ``bmaptool`` or ``dd``. - -You can detailed steps for creating bootable images for several types of images -in the following sections: - -* "[Deploying the AGL Demo Image](./machines/qemu.html#3-deploying-the-agl-demo-image)" for emulation images -* "[Booting the Image Using a MicroSD Card](./machines/renesas.html#7-booting-the-image-using-a-microsd-card) for supported Renesas boards -* "[Booting the Image on Raspberry Pi](./machines/raspberrypi.html#2-booting-the-image-on-raspberrypi) for Raspberry Pi 4 board diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /4_Boot_the_Image_on_the_Board.md b/docs/0_Getting_Started/6_ Developing_an_Application /4_Boot_the_Image_on_the_Board.md deleted file mode 100644 index 0e0b744..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /4_Boot_the_Image_on_the_Board.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -edit_link: '' -title: Boot the Image on the Board -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-boot.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 4. Boot the Image on the Board # - -You must have your image booted and running on your target device at some -point before deploying your application for testing. - -Steps exist for booting the following devices: - -1. **Intel Devices:** See the - "[Booting the Image on the Target Device](./machines/intel.html#4-booting-the-image-on-the-target-device)" - section. - -2. **QEMU:** See the - "[Deploying the AGL Demo Image](./machines/qemu.html#3-deploying-the-agl-demo-image)" - section. - -3. **R Car Starter Kit:** See the - "[Booting the Image Using a MicroSD Card](./machines/renesas.html#7-booting-the-image-using-a-microsd-card)" - section. - -4. **Raspberry PI:** See the - "[Booting the Image on Raspberry Pi](./machines/raspberrypi.html#2-booting-the-image-on-raspberry-pi)" - section. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /5_Get_Ready_to_Create_Your_Application.md b/docs/0_Getting_Started/6_ Developing_an_Application /5_Get_Ready_to_Create_Your_Application.md deleted file mode 100644 index 38e6b36..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /5_Get_Ready_to_Create_Your_Application.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -edit_link: '' -title: Get Ready to Create Your Application -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-prep-app.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 5. Get Ready to Create Your Application # - -Multiple methods exist that allow you to create your application. -You can use the X(cross) Development System (XDS), or you can use -a stand-alone Software Development Kit (SDK). -The preferred method is to use XDS. - -## Using XDS ## - -It is recommended that you develop your application using XDS, -which allows you to build, deploy, and execute personal projects on a target -either through the XDS dashboard or the XDS command line. - -To use XDS, you need to install server and client parts -and then use XDS to install the SDK: - -1. **Install the XDS Server:** You might not have to install the XDS Server. - If, for example, you are using an existing XDS server running on your local network - or in the Cloud, you can use that server. - - If you do not have an existing XDS server, you need to install one. - Three install types exist: container, virtual machine, or native. - Follow the steps from the appropriate section to install and start an XDS server: - - * **Container:** [Docker Container](../../../devguides/reference/xds/part-1/server-part.html#docker-container) - - * **Virtual Machine:** [VirtualBox Appliance](../../../devguides/reference/xds/part-1/server-part.html#virtualbox-appliance) - - * **Native:** [Native](../../../devguides/reference/xds/part-1/server-part.html#native) - -2. **Install the XDS Client Tools** The XDS Agent (``xds-agent``) needs to run on your build host. - The agent interfaces with a Command-line Interpretor (CLI) tool (``xds-cli``) and an - XDS Dashboard through a browser. - Installation involves making sure you have the correct packages installed on the - build host. - Follow the steps in the - "[Client Part](../../../devguides/reference/xds/part-1/client-part.html)" - section to install the XDS client tools and learn how to start the agent. - -3. **Install the SDK:** Once you have XDS up, you need to install the - SDK using either the command line or the Dashboard. - See the - "[AGL SDKs](../../../devguides/reference/xds/part-1/install-sdk.html)" - section for information on using both. - -## Installing a Stand-Alone SDK ## - -If you do not want to use XDS, you can install the SDK by itself. -For information, see the -"[App development SDK for Intel Minnowboard](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps)" -Wiki article. -You can also visit the -[Yocto Project Application Development and the Extensible Software Development Kit (eSDK)](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html) -Manual. - -**NOTE:** The AGL Project is not compatible with the eSDK. -You must use the Standard SDK. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /6_Create_and_Build_the_Application.md b/docs/0_Getting_Started/6_ Developing_an_Application /6_Create_and_Build_the_Application.md deleted file mode 100644 index 27d861d..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /6_Create_and_Build_the_Application.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -edit_link: '' -title: Create and Build the Application -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-build-app.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# 6. Create and Build the Application # - -In general, you can create and build an application many different ways. -Tools and Integrated Development Environments (IDEs) exist in various -scenarios that allow you to pick from whatever methodology or workflow -with which you are comfortable. - -A simple application you can experiment with is the standard -"hello world" application. -For information on how to get set up and then clone the Git repository -for the "Hello World" application, see the -"[Get the Source Files](../../../devguides/reference/xds/part-1/create-app-get-source-files.html)" -section. - -Key to developing an application suited for your target hardware is the -Standard Software Development Kit (SDK) mentioned in the -"[Get Ready to Create Your Application](./app-workflow-prep-app.html)" -section. -For information on the Standard SDK used with the Yocto Project and with -the AGL Project, see the -"[Yocto Project Application Development and Extensible Software Development Kit (eSDK)](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html) Manual". - -You can develop your application a number of ways. -The following list describes several: - -* **Build the Application Using XDS:** - You can use the AGL X(cross) Development System (XDS) - to build your application: - - * Use the XDS command line tool. - For information on how to build the "Hello World" application using the XDS - command line, see the - "[Build Using the Command Line](../../../devguides/reference/xds/part-1/create-app-build-cmd-line.html)" - section. - - * Use the XDS Dashboard. - For information on how to build the application using the XDS Dashboard, see the - "[Build Using the XDS Dashboard](../../../devguides/reference/xds/part-1/create-app-build-dashboard.html)" - section. - -* **Build the Application Using a Stand-Alone SDK:** - Nothing prevents you from using a Standard SDK completely outside of the - AGL Project development environment to build your application. - Here are a couple of methods: - - * Install Docker and create a container that has your SDK installed. - The container is a stable environment where you can build applications. - See the - "[Setting Up a Docker Container](./docker-container-setup.html)" - section for information on how to install Docker and create a container - that has your SDK installed. - - * Use the popular Eclipse IDE configured to work with the Yocto Project. - See the - "[Developing Applications Using Eclipse](https://yoctoproject.org/docs/2.4.4/sdk-manual/sdk-manual.html#sdk-eclipse-project)" - section in the Yocto Project Application Development and Extensible - Software Development Kit (eSDK) Manual. - - * Using Qt Creator / qmake and want to use the same .pro / .pri file to build for desktop or AGL? Put AGL-specific definitions inside a `linux-oe-*` block in your .pro and .pri files, e.g.: - ``` - linux-oe-* { - PKGCONFIG += qlibwindowmanager qtappfw - DEFINES += AGL - QMAKE_LFLAGS += "-Wl,--hash-style=gnu -Wl,--as-needed" - load(configure) - qtCompileTest(libhomescreen) - - config_libhomescreen { - CONFIG += link_pkgconfig - PKGCONFIG += homescreen - DEFINES += HAVE_LIBHOMESCREEN - } - - DESTDIR = $${OUT_PWD}/../package/root/bin - } - ``` - -* **Build the Application Using Your Own Methodology:** - Use any method you are familiar with to create your application. - Many development tools and workflows exist that allow you to - create applications. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /7_Deploy_the_Application_to_the_Board.md b/docs/0_Getting_Started/6_ Developing_an_Application /7_Deploy_the_Application_to_the_Board.md deleted file mode 100644 index ee9d6f8..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /7_Deploy_the_Application_to_the_Board.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -edit_link: '' -title: Deploy the Application to the Board -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-deploy-app.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Deploy the Application to the Board # - - -Many options exist for controlling your target and copying your compiled application to the target. -Details are target-specific and cannot be explained in detail here. - -Suffice it to say that if you compile your application on your build host and you have -an image running on your target hardware, you must employ some method to copy the application -to the target. -Several general methods exist: - - * Write the application to a storage device that both the build host and - the target hardware support. - This could be an SD card or a flash drive. - Be sure to format the drive as FAT32 to eliminate file ownership and permission issues. - - * Remotely mount the target's file system on the build host with the Network File System - (NFS) or Samba. - - * Commit compiled code from the build host to a shared repository and update the - target from that repository. - - * Use remote commands from a host over a network, such as `scp` (i.e. secure copy). - - * You can set up your build environment to leverage a procedure's - [application template](../../../devguides/reference/cmakeafbtemplates/dev_guide/using-cmake.html) - (app-template). - An app-template is an application framework that contains - [CMake](https://cmake.org/) macros that abstract deploying the application. - For example, with a proper build environment, you can run the following - to deploy your application: - - ``` - $ make widget-target-install - ``` - - **NOTE:** - The previous command uses `scp` to copy and install the widget to a pre-defined target board. - -Once you have the application copied to the target, it must provide a way to -initiate operating system commands. -To initiate operating system commands, you can do one of the following: - - * Connect a keyboard and display directly to the target. - - * Use ``ssh`` from a network-connected host to run commands on the target remotely. - - * Use a network for communication between the build host and the target. - This method works nicely when the build host and the target hardware are geographically apart. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /8_Debug_the_Application.md b/docs/0_Getting_Started/6_ Developing_an_Application /8_Debug_the_Application.md deleted file mode 100644 index 04d79e6..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /8_Debug_the_Application.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -edit_link: '' -title: Debug the Application -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/getting-started/app-workflow-debug-app.md ---- - -<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/getting_started/master/image-development-workflow-getting-started-book.yml --> - -# Debug the Application # - -You can debug your application many ways. -The method depends on factors such as the component you are debugging, -whether or not you are doing a post-mortem analysis, and your debugging -skills and productivity. -For example, do you know how to use the -[GNU Project Debugger](https://www.gnu.org/software/gdb/) (`gdb`) from a -console? -Or, is it better for you to use a remote user interface that is part of -an Integrated Development Environment (IDE) such as Eclipse? - -For general information on debugging an application, see the -"[Overview](../../../devguides/reference/xds/part-1/debug-overview.html)" -topic under "Debugging Your First AGL Application". - -Three methods exist: - - * Use `gdb` on the target. - - <!--section-note--> - **NOTE:** - - How to use `gdb` and other debugging tools such as `valgrind`, `strace`, - and so forth is beyond the scope of the AGL Documentation. - See the appropriate documentation for third-party debugging tools. - <!--end-section-note--> - - * Use Core Dumps if you have set the `agl-devel` feature. - Core Dumps are obviously more suited for post-mortem analysis. - For features, see the - "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment)" - topic. - - <!--section-note--> - **NOTE:** - - Core Dumps are available only with the "Flunky Flounder" release (i.e. 6.x). - <!--end-section-note--> - - * Use XDS remotely, which is based on `gdb` and - [`gdbserver`](https://en.wikipedia.org/wiki/Gdbserver). - See the - "[Using the XDS Command Line](../../../devguides/reference/xds/part-1/debug-cmd-line.html#xds-remote-debugging-mode)" - topic for more information. - - For information on how to remotely debug the application using XDS from within an IDE, see the - "[Using an IDE](../../../devguides/reference/xds/part-1/debug-ide.html)" - section. - - In order to use third-party debugging tools, you need to include the tools in the target image. - You gain access to the tools by enabling the `agl-devel` feature when you run the - `aglsetup.sh` script as described in the - "[Initializing Your Build Environment](./image-workflow-initialize-build-environment.html#initializing-your-build-environment)" - section. diff --git a/docs/0_Getting_Started/6_ Developing_an_Application /images/app-developer-workflow.png b/docs/0_Getting_Started/6_ Developing_an_Application /images/app-developer-workflow.png Binary files differdeleted file mode 100644 index 3b14272..0000000 --- a/docs/0_Getting_Started/6_ Developing_an_Application /images/app-developer-workflow.png +++ /dev/null |
