agl application sdk - kickstart for renesas porter board€¦ · agl application sdk - kickstart...

AGL Application SDK - Kickstartfor Renesas Porter Board

Version 1.0

January 2016

AGL Application SDK - Kickstart for Renesas Porter Board

Abstract

This document explains step by step how to setup the development environment for Porter board with AGL distribution and latest Renesas BSP.

The following topics are covered:• instructions to setup the SDK environment based on AGL 1.0 and

Renesas BSP• build a cross-platform C/C++ application• deploy the application on a target board• run and debug the application remotely

Document revisions

Date Version Designation Author

15 Dec. 2015 0.1 Initial release S. Desneux [ Iot.bzh ]Y. Gicquel [ Iot.bzh ]

04 Jan 2016 0.2 Remote debug sections addition S. Desneux [ Iot.bzh ]Y. Gicquel [ Iot.bzh ]

12 Jan 2016 0.3 Add Windows & OS X sections S. Desneux [ Iot.bzh ]M.Bachmann [Iot.bzh ]

22 Jan 2016 0.4 Add screen shots in part II S. Desneux [ Iot.bzh ]

24 Jan 2016 0.5 Review S. Desneux [ Iot.bzh ]

26 Jan 2016 1.0 Release S. Desneux [ Iot.bzh ]

Version 1.0 January 2016 – 2 / 33 –


Table of contents

1.Deploy a SDK using containers..............................................................41.1.Motivation....................................................................................41.2.Prerequisites.................................................................................4

Part I – AGL Application SDK Setup...........................................................52.Setting up your operating system...........................................................5

2.1.Ubuntu and Debian........................................................................52.2.Windows© (7, 8, 8.1, 10).................................................................72.3.Mac OS X©....................................................................................9

3.Install AGL SDK Container using Docker................................................113.1.Overview....................................................................................113.2.Download the image from the registry.............................................113.3.Start the SDK container................................................................123.4.Connect to SDK container through RDP...........................................13

3.4.1.Linux....................................................................................133.4.2.Windows©.............................................................................133.4.3.Mac OS X©............................................................................14

3.5.SDK Session................................................................................153.6.Optional: get a persistent workspace..............................................17

3.6.1.From Linux host using a shared directory...................................173.6.2.From Windows© host using a shared directory............................183.6.3.From the container using a remote directory (SSHFS).................18

4.Inside the container...........................................................................194.1.Features.....................................................................................194.2.File system organization and shared volume....................................19

Part II – AGL Application SDK use cases...................................................205.Porter board setup.............................................................................206.Development of a C/C++ application....................................................21

6.1.Toolchain registration....................................................................216.2.Create a new Autotools C program.................................................226.3.Configure a connection to the target...............................................256.4.Build the binary...........................................................................286.5.Launch the binary on the remote target...........................................296.6.Debug using SSH and GdbServer....................................................316.7.Create a new CMake C program.....................................................33



1. Deploy a SDK using containers

1.1. Motivation

The Yocto build environment is subject to many variations depending on:

• Yocto/Poky/OpenEmbedded versions and revisions

• Specific layers required for building either the BSP or the whole distribution

• Host distribution and version1

• User environment

In particular, most of the recent Linux host distributions (Ubuntu 15.04, Debian 8.2, OpenSuse 42.1, CentOS 7.x) do not officially support building with Yocto 1.7. Unfortunately, there's no easy solution to solve this kind of problem: we will still observe for quite a long time a significant gap between the latest OS versions and a fully certified build environment.

To circumvent those drawbacks and get more deterministic results amongst the AGL community of developers and integrators, using virtualization is a good workaround. A Docker image is now available for AGL SDK: it is faster, easier and less error-prone to use a prepared Docker container because the image contains all necessary components to build and deploy an AGL image, including a validated base OS, independent of the user’s host OS. Moreover, light virtualization mechanisms used by Docker do not add much overhead when building: performances are nearly equal to native mode.

1.2. Prerequisites

To run an AGL SDK Docker image, the following prerequisites must be fulfilled:

• You must run a 64-bit operating system, with administrative rights,

• Docker engine v1.8 or greater must be installed,

• An internet connection must be available to download the Docker image to your

local host.

1 The list of validated host distros is defined in the Poky distro, in the file meta-yocto/conf/distro/poky.conf and also at http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#detailed-supported-distros



Part I – AGL Application SDK Setup

This first part of the document will prepare your local host to use a pre-installed AGL SDK to enable building and debugging on a Renesas Porter board target.

2. Setting up your operating system

In this section, we describe the Docker installation procedure depending on your host system. We will be focusing on the most popular systems; for a full list of supported operating systems, please refer to Docker online documentation: http://docs.master.dockerproject.org/

2.1. Ubuntu and Debian

At the time of writing, Docker project supports these Ubuntu/Debian releases:

• Ubuntu Trusty 14.04 LTS;

• Ubuntu Precise 12.04 LTS;

• Ubuntu Saucy 13.10;

• Debian 8.0 (64-bit);

• Debian 7.7 (64-bit);

For an updated list of supported distributions, you can refer to the Docker project website, at these locations:

• http://docs.master.dockerproject.org/installation/debian/

• http://docs.master.dockerproject.org/installation/ubuntulinux/

Here are the commands needed to install the Docker engine on your local host:

sudo apt-get updatesudo apt-get install wget curlwget -qO- https://get.docker.com/ | sh


http://docs.master.dockerproject.org/installation/ubuntulinux/

http://docs.master.dockerproject.org/installation/debian/

http://docs.master.dockerproject.org/


This will register a new location in your “sources.list” file and install the “docker.io” package and its dependencies:

cat /etc/apt/sources.list.d/docker.listdeb https://apt.dockerproject.org/repo ubuntu-trusty maindocker --versionDocker version 1.9.1, build a34a1d5

It is then recommended to add your user to the new “docker” system group:

sudo usermod -aG docker <your-login>

… and after that, to log out and log in again to have these credentials applied.

If everything went right, you should be able to list all locally available images using:

docker imagesREPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE

In our case, no image is available yet, but the environment is ready to go on.

You can reboot your system or start the Docker daemon using:

sudo service docker start

An RDP client must also be installed. Multiple RDP clients are available but we can simply install the Freerdp client:

sudo apt-get install freerdp



2.2. Windows© (7, 8, 8.1, 10)

We will be downloading the latest Docker Toolbox at the following location:

https://www.docker.com/docker-toolbox

and by clicking on the “Download (Windows)” button:

We will answer “Yes”, “Next” and “Install” in the next dialog boxes.




We can then start it by double-clicking on the “Docker Quickstart Terminal” icon:

It will take a certain amount time to setup everything, then this banner appears:

We will then prepare the virtual machine by typing the following commands:

docker-machine ssh default “echo mkdir /sys/fs/cgroup/systemd | \ sudo tee /var/lib/boot2docker/bootlocal.sh”docker-machine stop default/c/Program\ Files/Oracle/VirtualBox/VboxManage.exe modifyvm default \ --natpf1 rdp,tcp,127.0.0.1,33890,,3389docker-machine start default



2.3. Mac OS X©

We will be downloading the latest Docker Toolbox at the following location:


and by clicking on the “Download (Mac)” button:

We will answer “Continue” and “Install” in the next dialog boxes:

Then, when we go to our “Applications” folder, we now have a “Docker” subfolder where we can start “Docker Quickstart Terminal”:




It will take a certain amount of time to setup everything, then this banner appears:

We will then prepare the virtual machine by typing the following commands:

docker-machine ssh default “echo mkdir /sys/fs/cgroup/systemd | \ sudo tee /var/lib/boot2docker/bootlocal.sh”docker-machine stop defaultVboxManage modifyvm default --natpf1 rdp,tcp,127.0.0.1,33890,,3389docker-machine start default

We'll also need a RDP client. Mac OSX does not provide a RDP client out-of-the-box, but you can download the offical RDP client from the Apple Store by following this link:

https://itunes.apple.com/app/microsoft-remote-desktop/id715768417?mt=12

then “View in Mac App Store” and “Install App”.

→

If needed, an older version of the RDP client is also available at:

https://www.microsoft.com/en-US/download/details.aspx?id=18140

but it may not be compatible with newest systems.

Version 1.0 January 2016 – 10 / 33 –

https://www.microsoft.com/en-US/download/details.aspx?id=18140

https://itunes.apple.com/app/microsoft-remote-desktop/id715768417?mt=12


3. Install AGL SDK Container using Docker

3.1. Overview

This section gives details on a procedure which allows application developers to set up a pre-installed “ready-to-code” SDK on their local host.

The prepared environment is deployed and available thanks to lightweight virtualization containers using Docker technology2. The pre-installed SDK for AGL development activities is currently designed to be accessed using Remote Desktop Protocol. This first technology integration may change in the future and will probably leverage web technologies.

3.2. Download the image from the registry

To download the image, you can enter:

docker pull docker.iot.bzh/agl/snapshot-stable-sdk:1.01.0: Pulling from agl/snapshot-stable-sdkc1990f04dc6d: Downloading 4.227 MB/131 MBa6d8aa0ae117: Download complete 114c42cb1c64: Download complete b5c4e463fbfd: Downloading 3.7 MB/80.39 MB10b73ed5af0f: Download complete a9b6d05d59a0: Download complete d1c1d277b792: Download complete 2384d0ef9426: Downloading 2.114 MB/969 MBa48d7b1c87f9: Download complete 41ad8301437e: Download complete 1361747b71f9: Downloading 2.114 MB/1.025 GB

This operation will take some time as around 2.0GB of file system layers need to be pulled from the remote repository (for AGL-1.0 “Albacore”).

Please note: these Docker filesystem layers are designed in a way users can pull the latest SDK layer without the need to download all the previous layers related to IDE or tools. For a description of image content, please refer to section 4.

Alternatively, we also distribute the image as a compressed archive which can be downloaded faster, then imported into Docker with the following command:

curl http://iot.bzh/download/public/2016/sdk/porter_images/1.0/docker_agl_snapshot-curl http://iot.bzh/download/public/2016/sdk/porter_images/1.0/docker_agl_snapshot-stable-sdk-1.0.tar.bz2 | docker loadstable-sdk-1.0.tar.bz2 | docker load

2 See https://www.docker.com/

Version 1.0 January 2016 – 11 / 33 –

https://www.docker.com/


Whatever the download method, the new Docker image should be available. This can be checked by running 'docker images':

docker imagesREPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEdocker.iot.bzh/agl/snapshot-stable-sdk 1.0 8901a7cc3b46 2 days ago 2.109 GB

3.3. Start the SDK container

Once the image is available on your local host, you can start the SDK and the RDP service using the following command:

docker run --publish=3389:3389 --detach=true --privileged \ --hostname=aglsdk --name=aglsdk \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ docker.iot.bzh/agl/snapshot-stable-sdk:1.0

Then, you can check that the image is running with the following command:

docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES2304f51e1887 docker.iot.bzh/agl/snapshot-stable-sdk "/usr/bin/wait_for_ne" 1 minutes ago Up 1 minutes 0.0.0.0:3389->3389/tcp aglsdk

The container is now ready to be used.

A dedicated user has been declared: devel

The associated password is: devel

Version 1.0 January 2016 – 12 / 33 –


3.4. Connect to SDK container through RDP

The SDK image provides a pre-installed set of tools which can be accessed through the Remote Desktop Protocol (RDP).

3.4.1. LinuxOn Linux-based systems, you may need to install an RDP client. As already mentioned, multiple RDP clients are available; here below we illustrate a setup using FreeRDP3 client.

To launch the RDP session, you can enter the following:

xfreerdp -u devel -p devel -g 1200x700 localhost &

In the previous command, a session for user “devel” with password “devel” is launched using a 1200x700 virtual desktop geometry. “devel” is the main user account of the AGL SDK.

3.4.2. Windows©

This protocol is natively supported on Microsoft Windows related operating systems. To run it, maintain [Win]+[R], and type “mstsc” [Enter].→

Then, to launch the RDP session, we will connect to localhost:33890:

Credentials are the same as for Linux: user is “devel” with password “devel”.

3 http://www.freerdp.com/

Version 1.0 January 2016 – 13 / 33 –

http://www.freerdp.com/


3.4.3. Mac OS X©

The RDP client setup process is described above in 2.3.

It should then be available in your “Applications” folder under the name “Microsoft Remote Desktop”.

You can then click on “New” and specify an AGL connection to localhost:33890 with the devel user and devel password.

Double-clicking on the new AGL entry will then initiate the connection.

Version 1.0 January 2016 – 14 / 33 –


3.5. SDK Session

The XRDP session starts and the window manager (OpenBox) appears.

Then Eclipse IDE starts automatically:

Version 1.0 January 2016 – 15 / 33 –


A desktop menu is available when the Eclipse window is iconified, by clicking on the root window with the right mouse button (this is OpenBox default):

From there, you can start other applications which are installed in the container, like a terminal emulator or access to the virtual desktops:

Version 1.0 January 2016 – 16 / 33 –


3.6. Optional: get a persistent workspace

AGL SDK image brings a set of tools and here we describe a way to prepare a “shared directory” on your local host accessible from the container. The aim of this shared directory is to allow your ongoing developments to stay independent from the SDK upgrades.

3.6.1. From Linux host using a shared directoryCurrent stable docker implementation (1.9) has a limitation about UID:GID mapping between hosts and containers. In the long run, the planned mechanism is to use the “user namespace” feature. But for now, we propose another approach unfortunately less flexible.

We can use a directory on the local host with a dedicated Unix group using a common GID between the host and the container. This GID has been fixed to “1664”4 and can be created on your linux host using the following commands:

sudo groupadd --gid 1664 agl-sdksudo usermod -aG agl-sdk <your-login>

If this GID is already used on your local host, you will have to use it for this sharing purpose as well. In case this is not possible, another option to exchange workspace data can be the use of a network service (like SSH, FTP) of the container and from your local host.

Once the GID is ready to use, we can create a shared directory (not as 'root', but as your normal user):

cdmkdir $HOME/agl-workspacechgrp agl-sdk $HOME/agl-workspacechmod ug+w $HOME/agl-workspace

And run the Docker image with the new highlighted switch:

docker run --publish=3389:3389 --detach=true --privileged \ --hostname=aglsdk --name=aglsdk \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ -v $HOME/agl-workspace:/xdt/workspace \ docker.iot.bzh/agl/snapshot-stable-sdk:1.0

4 https://en.wikipedia.org/wiki/Beer_in_France

Version 1.0 January 2016 – 17 / 33 –

https://en.wikipedia.org/wiki/Beer_in_France


3.6.2. From Windows© host using a shared directoryWe will create a shared directory for our user:

mkdir $HOME/agl-workspace

And run the Docker image with the new highlighted switch:

docker run --publish=3389:3389 --detach=true --privileged \ --hostname=aglsdk --name=aglsdk \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ -v /c/Users/$USERNAME/agl-workspace:/xdt/workspace \ docker.iot.bzh/agl/snapshot-stable-sdk:1.0

3.6.3. From the container using a remote directory (SSHFS)It's also possible to mount a remote directory inside the container if the source host is running a ssh server.

Start the container normally as described in 3.3, open a RDP session then inside the container, open a terminal and run the following commands to install the package “sshfs”:

sudo apt-get updatesudo apt-get install -y sshfs

NB: sudo will ask for the password of the user “devel”, which is “devel”.

Now, close Eclipse IDE to leave the workspace inside the container and mount a remote directory at the same location using the SSH convention.

For example, if we want to mount the remote dir '/data/workspace' with user 'alice' on host 'computer42', then we would run:

sshfs alice@computer42:/data/workspace -o nonempty $XDT_WORKSPACE…Password: <enter alice password on computer42>

NB: the directory on the remote machine must be owned by the remote user

Verify that the mount is effective:

df /xdt/workspaceFilesystem 1K-blocks Used Available Use% Mounted onalice@computer42:/data/workspace 103081248 7138276 95612016 7% /xdt/workspace

Restart Eclipse from the desktop menu: the files created inside the container in /xdt/workspace are now stored 'outside', in the shared directory with proper uid/gid.

To unmount the shared directory, stop Eclipse IDE then run:

sudo umount $XDT_WORKSPACE

Version 1.0 January 2016 – 18 / 33 –


4. Inside the container

4.1. Features

Container features:

• a Debian 8.0 based system with an XRDP server listening on tcp/3389,

• a pre-installed Eclipse IDE (Kepler),

• a set of pre-configured Eclipse plugins: Yocto ADT, Remote Target, CDT, jsbuild.

• a pre-installed AGL SDK including ARM Cortex-A15 toolchain.

• a dedicated user is defined to run the SDK session and Eclipse IDE: devel

4.2. File system organization and shared volume

The SDK has been designed with a dedicated file-system hierarchy. Here it is:

devel@hostname:/$ tree -L 2 /xdt/xdt|-- build|-- ccache|-- downloads|-- meta|-- sdk| |-- environment-setup-cortexa15hf-vfp-neon-poky-linux-gnueabi| |-- site-config-cortexa15hf-vfp-neon-poky-linux-gnueabi| |-- sysroots| `-- version-cortexa15hf-vfp-neon-poky-linux-gnueabi|-- sources|-- sstate-cache`-- workspace

Noticeably, the AGL related features are located in the dedicated “/xdt” directory.

This directory contains sub-directories, and in particular the following:

• sdk: contains the pre-installed Yocto AGL SDK, containing in particular a cross-

compiler and a debugger.

• workspace: a directory which can be used by developers to store their

applications and projects while using Eclipse IDE.

Version 1.0 January 2016 – 19 / 33 –


Part II – AGL Application SDK use cases

The first part of the document prepared your local host to use a pre-installed AGL SDK for building and debugging on a target.

Here we describe the requirements on the Porter board target side, and explain some typical use cases of the SDK.

5. Porter board setup

We are not going through details about the target software image generation. Here, we just want to highlight the point that the target image must have been built with some extra features activated, with the following in the Yocto “local.conf” build setup:

EXTRA_IMAGE_FEATURES = "debug-tweaks eclipse-debug tools-debug tools-profile"

Also, if you want to start using the SDK with a quick installation, a minimal SD-Card image for Renesas Porter board – aligned with AGL 1.0 image – is available for download at this location: http://iot.bzh/download/public/2016/sdk/porter_images/.

For more details on image generation, please refer to chapter §3 of the document “AGL Kickstart on Renesas Porter Board” publicly available here:

http://iot.bzh/download/public/2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf

Version 1.0 January 2016 – 20 / 33 –


http://iot.bzh/download/public/2016/sdk/porter_images/


6. Development of a C/C++ application

6.1. Toolchain registration

To perform cross-compilation from Eclipse IDE, we need to register the cross-platform toolchain inside the IDE. For this, you can select the “Window/Preferences” menu entry then go to “Yocto Project ADT” section:

In the “Cross Compiler Options”, we should configure the following points:

• Select “Standalone pre-build toolchain”,

• Set “Toolchain Root Location” to: /xdt/sdk,

• Set “Sysroot Location” to:

/xdt/sdk/sysroots/cortexa15hf-vfp-neon-poky-linux-gnueabi,

Please note that the “Target architecture” selection box should detect the pre-installed toolchain and pre-select “cortexa15hf-vfp-neon-poky-linux-gnueabi”.

Version 1.0 January 2016 – 21 / 33 –


Validate the settings by clicking on the OK button.

At this point, Eclipse is configured to use the SDK cross-compiler to generate binaries with the architecture that matches the target board (ARM / Cortex A15 with hardware floating point and Neon extended instructions set).

The next step is to create a project in Eclipse workspace.

6.2. Create a new Autotools C program

Following is an example of a new C application to be deployed on the Porter board. As usual, the “Hello world” basic application is presented.

To create a new autotools project, select “File/New/C Project” menu entry:

Version 1.0 January 2016 – 22 / 33 –


The following dialog appears:

Complete the following fields:

Project name: helloworld_01

Project type: Yocto Project ADT Autotools Project/Hello World ANSI C Autotools

Then click on the “Next” button.

Version 1.0 January 2016 – 23 / 33 –


A new dialog appears. Fill the author name and other fields according to your needs:

Finally, select “Finish” to create a new project then go into Workbench in your Eclipse workspace:

Version 1.0 January 2016 – 24 / 33 –


6.3. Configure a connection to the target

Here, we're assuming that a Porter Board is booted with the AGL 1.0 image and is reachable through the local network.

Select the menu entry: “Run/Run Configurations…”. A dialog box will appears, with two main parts on its interface:

On the left pane of the dialog box, we can see a list of configurations. In “C/C++ Remote Application” a “helloworld_01_gdb_arm-poky-linux-gnueabi” should be present.

If you select it, on the right part of the dialog box some settings should be pre-configured and some others may be adjusted.

First, we need to configure a target connection: click on “New...” button to create a new “Connection”.

Version 1.0 January 2016 – 25 / 33 –


The following dialog appears:

Select “SSH Only”, hit Next then:

Enter the target IP address, name the connection (“porter” in our example), add a description, then hit Finish.

Please note that by default on AGL release 1.0, there is no network link ready to use. On Porter board, you need to activate the network Ethernet link using the console terminal, and using the following commands on the target:

root@porter:~# dhclient eth0sh-eth ee700000.ethernet eth0: attached PHY 1 (IRQ 416) to driver Micrel KSZ8041RNLIlibphy: ee700000.etherne:01 - Link is Up – 100/Full

Version 1.0 January 2016 – 26 / 33 –


Then, you can check the target IP address for interface eth0:

root@porter:~# ip addr show dev eth03: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2e:09:0a:00:87:bd brd ff:ff:ff:ff:ff:ff inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::2c09:aff:fe00:87bd/64 scope link valid_lft forever preferred_lft foreverroot@porter:~#

… which is 10.0.0.115 in our example.

For more details, the network activation on Porter board is described more extensively in the document “AGL Kickstart on Renesas Porter Board”, chapter §3.2.

Back to the “Run Configurations” dialog, the next step is to configure the remote path of the binary to be run.

Thus in the “Remote Absolute File Path for C/C++ Application”, we can set: /tmp/helloworld

At this point, Remote execution of the application is now ready and the dialog looks like this:

We can then apply and close this dialog.

Version 1.0 January 2016 – 27 / 33 –



6.4. Build the binary

To build the binary, simply hit the Build button (or menu Project/Build Project):

The ARM binary is built and ready to be deployed.

Version 1.0 January 2016 – 28 / 33 –


6.5. Launch the binary on the remote target

Select the item “Run/Run As…/Remote Application” in the menu.

Then in the next dialog, choose the proper item and click on the “Run” button:

Given the previous Run Configuration in §6.3, the following will occur:• the binary will be copied onto the target board through SSH in the “Remote

Absolute File Path for C/C++ Application”• it will be remotely launched and its standard output will be displayed in the

“Console” bottom panel

Version 1.0 January 2016 – 29 / 33 –


At first connection, a dialog appears to ask for credentials: user ID is 'root', without any password.

Other dialogs related to master password (to keep credentials in Eclipse) or first connection to remote target may pop-up: set the master password then simply accept the other pop ups.

Then the binary is copied and executed and the console in the main perspective reports the output:

In this example, we see the string “Hello Porter” displayed on the console and that shows that the binary has been executed on the target board.

Version 1.0 January 2016 – 30 / 33 –


6.6. Debug using SSH and GdbServer

As for a remote binary execution session, the requirement to start a remote debug session is also the configuration of a control link on the target (please refer to section 6.3).

To remotely debug a binary, we can place some breakpoints and use the item “Run/Debug As/Remote Application” in the menu:

Version 1.0 January 2016 – 31 / 33 –


This will open the “Debug perspective” of the Eclipse IDE, showing:

• watched variables and variables on the stack,

• breakpoints list,

• stack frame, ...

Click on the “Terminate” button to end the debug session.

Version 1.0 January 2016 – 32 / 33 –


6.7. Create a new CMake C program

As an alternative to autotools, we can also create a project based on the CMake tool.

Steps are similar to §6.2, but this time we'll choose “Hello World C CMake Project”:

The created project can then be built, run and debug as described in the previous chapters.

Version 1.0 January 2016 – 33 / 33 –

agl application sdk - kickstart for renesas porter board€¦ · agl application sdk - kickstart...

Documents