How to Run IoTivity on ARTIK with Yocto

Samsung ARTIK is described by its developers as an end-to-end, integrated IoT platform that transforms the process of building, launching, and managing IoT products. I first saw one a year ago at the Samsung VIPEvent 2015 in Paris, but now there is an ARTIK10 on my desk and I would like to share some of my experiences of it with you.

In this post, I will show how to build a whole GNU/Linux system using Yocto, a project that provides great flexibility in mixing and matching components and customizing an environment to support new hardware or interesting software like IoTivity. If you’re looking for Tizen support, it’s already here (check at bottom of this article), but this post will focus on a generic Linux build.

Many of the board’s features I will be covering in this article are briefly introduced in the following video:

There are 3 ARTIK models on the market: ARTIK 1 is MIPS based system with 1MB of RAM while ARTIK 5 and 10 are powerful ARM systems based on Exynos System on Module. This article covers the ARTIK 10 and it can easily be adapted to the ARTIK 5, but not the ARTIK 1.

According to the specifications, the ARTIK 10 has an 8 Core CPU (4 Cortex-A7 and 4 Cortex-A15), 2GB of RAM, and a GPU (Mali T628) for multimedia needs. Since the ARTIK family is targeted for Internet of Things use cases, there are also a lot of connectivity controllers (Wired Ethernet, Wi-Fi : IEEE802.11a/b/g/n/ac, Bluetooth 4.1 + LE, Zigbee/Thread) as well as security elements (ARM TrustZone, TEE) which are mandatory for a safe IoT.

Unboxing and Booting the ARTIK 10

In the box you’ll find 4 antennas, a micro USB cable, and power supply (5V*5A with center positive plug). Warning: some devices like Intel NUC use the same 5.5 x 2.1mm power supply barrel, but at 12V. It’s a good idea to label power supply connectors if you have a bunch lying around because plugging in 12V+ will probably brick your ARTIK.

Setup the Debug Port

Once you plug the USB cable into the ARTIK, 2 blue lights will turn on and on your host side a serial port device will appear (even if device is powered off):

$ lsusb
Bus 002 Device 012: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

dmesg | tail
usb 2-1.5.2: new full-speed USB device number 12 using ehci-pci
usb 2-1.5.2: New USB device found, idVendor=0403, idProduct=6001
usb 2-1.5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.5.2: Product: FT232R USB UART
usb 2-1.5.2: Manufacturer: FTDI
usb 2-1.5.2: SerialNumber: ????????
ftdi_sio 2-1.5.2:1.0: FTDI USB Serial Device converter detected
usb 2-1.5.2: Detected FT232RL
usb 2-1.5.2: FTDI USB Serial Device converter now attached to ttyUSB0

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun  2 15:11 /dev/ttyUSB0

As you can see the device is owned by root and belongs to the dialout group, so check if your user is in this group too (groups | grep dialout), then you can use your favorite serial terminal (minicom, picocom) or GNUscreen.

screen /dev/ttyUSB0 115200

That’s it!. If you’re on Windows, enjoy this Cybercode twins’ video to learn a bit about how to get setup.

Ready For Your First Boot

Turn off the device by pressing on the left side of the “POWER SW” 2 states button. Then, connect the power supply, wait about 10 seconds, and hold the SW3 POWER switch for a couple of seconds. After this, U-Boot’s log should be printed in the terminal.

Mine came loaded with the reference system based on Fedora 22. To use this, you can login as root:root and you’ll have at least 13G free (of 16G) to work. Here is a reference file from the flashed OS on the eMMC:

# cat /etc/artik_release

RELEASE_VERSION=1020GC0F-3AF-01Q0
RELEASE_DATE=20160308.225306
RELEASE_UBOOT=U-Boot 2012.07
RELEASE_KERNEL=3.10.93

Since we’ll be setting up a different operating system, I prefer to avoid touching this supported system and I’ll leave it to use as a reference to compare hardware support. The plan is to work on a removable microSD card and not change the eMMC at all.

Boot From an SD Card

Like many other SoC’s like the ODROID devices, booting from a microSD card is supported, but it requires a bit of manual intervention. You first need to configure it using micro switches “SW2” on the left, located between the debug and USB3 ports.

The switch block may be covered with tiny piece of plastic tape, remove it carefully with a toothpick and move both switches from the left (OFF) position to the right where “ON” is printed.

To try my experimental, compressed image, download demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2 (md5:12c64d6631482f90d45a0d015bea5980) from our file server and copy to your microSD card using qemu-utils:

# lsblk
disk=/dev/sdTODO
file=demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2
# time qemu-img convert -p "${file}" "${disk}"

As you did earlier, power the device off, connect the USB cable, insert the microSD card, switch it on, wait for a few seconds, and finally hold the micro switch for a couple of seconds. U-Boot should run through its configuration and some verbose output should be printed on the serial console:

U-Boot 2012.07 (Jun 06 2016 - 10:42:48) for ARTIK10

CPU: Exynos5422 Rev0.1 [Samsung SOC on SMP Platform Base on ARM CortexA7]
APLL = 800MHz, KPLL = 800MHz
MPLL = 532MHz, BPLL = 825MHz

Board: ARTIK10
DRAM:  2 GiB
WARNING: Caches not enabled

TrustZone Enabled BSP
BL1 version: ?/???
VDD_KFC: 0x44
LDO19: 0x28

Checking Boot Mode ... SDMMC
MMC:   S5P_MSHC2: 0, S5P_MSHC0: 1
MMC Device 0: 7.4 GiB
MMC Device 1: 14.6 GiB
MMC Device 2: MMC Device 2 not found
In:    serial   
Out:   serial   
Err:   serial   
rst_stat : 0x100
Net:   No ethernet found.
Hit any key to stop autoboot:  0
[Fusing Image from SD Card.]
(...)
reading zImage
5030144 bytes read in 32570 ms (150.4 KiB/s)
reading exynos5422-artik10.dtb
71014 bytes read in 31067 ms (2 KiB/s)
## Flattened Device Tree blob at 40800000
   Booting using the fdt blob at 0x40800000
   Loading Device Tree to 4ffeb000, end 4ffff565 ... OK

Starting kernel ..
(...)

And in the end you’ll get a login prompt for root without password:

Poky (Yocto Project Reference Distro) 2.0.2 artik10 /dev/ttySAC3

artik10 login: root

root@artik10:~# cat /proc/version 
Linux version 3.10.93 (philippe@WSF-1127) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Mon Jun 6 10:39:42 CEST 2016

root@artik10:~# cat /proc/cmdline 
console=ttySAC3,115200n8 root=/dev/mmcblk1p2 rw rootfstype=ext4 loglevel=4 rootdelay=3

Now you are ready for the section on building your own image, but if you really want to make sure everything is working, Canonical supports ARTIK so you can use an Ubuntu snappy image. For reference, I tested artik10-snappy-20160317.img.tar.xz and it reported the following for its Kernel:

Linux version 3.10.9-00008-gb745981-dirty (u@u-ThinkPad-T450) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #7 SMP PREEMPT Thu Mar 10 10:06:16 CST 2016

Build Your Own Image with meta-artik

First we start with Poky: the Yocto reference distro, because it’s the quickest way to reach today’s goal. As with all Yocto targets, you first need to identify a Board Support Package (BSP) layer that collects all the special software needed for this family of hardware. As far as I know there is no official Yocto layer for ARTIK.

I’ve known about meta-exynos but I also noticed the meta-artik community layer from ResinIo; they spoke about ARTIK BSP at the latest Samsung Developer Conference (SDC2016):

What really matters in this set is the u-boot-artik and linux-exynos recipes to fetch sources. So we’re going to make use of my small contribution to produce standalone bootable sdcard images in meta-artik’s master branch.
The patch adds a new class for SD card output; the black magic is that U-Boot params should be dumped to different places (0x00080e00 (1031*512) for ARTIK5 and 0x00099e00 (1231*512) for ARTIK10), if not done I’ll try to adapt this for Tizen too.

Let’s clone Poky, add the layer to your conf file, and build a regular image.

$ git clone -b jethro http://git.yoctoproject.org/git/poky
$ cd poky
$ git clone -b master https://github.com/resin-os/meta-artik
$ . ./oe-init-build-env

With the recipe in place, you need to tell the environment to look for it. For this, edit the bblayers.conf file from the base setup (this file will be in build/conf/ underneath your top level directory) and add a line to the BBLAYERS stanza (there’s no need to add to BBLAYERS_NON_REMOVABLE, that doesn’t apply to this build). Using the format of the base post, the line would look like this:

$ cat conf/bblayers.conf

RELATIVE_DIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../../..')}"
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${RELATIVE_DIR}/poky/meta \
  ${RELATIVE_DIR}/poky/meta-yocto \
  ${RELATIVE_DIR}/poky/meta-yocto-bsp \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  ${RELATIVE_DIR}/poky/meta \
  ${RELATIVE_DIR}/poky/meta-yocto \
  "

BBLAYERS += "${RELATIVE_DIR}/poky/meta-artik"

Then, build the image:

$ MACHINE=artik10 bitbake core-image-minimal

When this finishes, write the image to the SD card:

lsusb # list of disks devices
disk=/dev/sdTODO # update device for sdcard
dd if=tmp/deploy/images/artik10/core-image-minimal-artik10.artik-sdimg bs=32M oflag=sync of=$disk

Adding IoTivity

IoTivity is an open source framework that enables effective device-to-device connectivity for the Internet of Things. It implements the emerging standards from the Open Connectivity Foundation (OCF was formerly known as OIC, and the specified protocols still use the oic name, as does the layer described below).

The layered approach of Yocto makes it easy to add components, as long as descriptions exist for them. Otherwise you need to write your own descriptions, which is not too hard. To add IoTivity, add the meta-oic layer:

$ cd ../../poky
$ git clone -b 1.1.0 http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic

Next, add it to previous file (./build/conf/bblayers.conf)

BBLAYERS += "${RELATIVE_DIR}/poky/meta-oic"

We also want to add some of the IoTivity packages into the built image; edit build/conf/local.conf to add these:

# IoTivity
IMAGE_INSTALL_append = " iotivity iotivity-resource iotivity-service"
# To get the example apps, include these as well:
IMAGE_INSTALL_append = " iotivity-resource-samples iotivity-service-samples"

Finally, build it :

MACHINE=artik10 bitbake core-image-mininal

Like before, copy this image to the SD card and boot it up the normal way.

Trying out IoTivity

Once you have installed the example packages, you can find apps to try things out. This is probably more interesting with two machines running IoTivity, so you can have a distinct client and server device, but it is possible to run both on the same machine.

In /opt/iotivity/examples/resource/cpp/ you will see these files, which make up client/server pairs – the names are descriptive:

ls /opt/iotivity/examples/resource/cpp/

OICMiddle              groupclient            simpleclient
devicediscoveryclient  groupserver            simpleclientHQ
devicediscoveryserver  lightserver            simpleclientserver
fridgeclient           presenceclient         simpleserver
fridgeserver           presenceserver         simpleserverHQ
garageclient           roomclient             threadingsample
garageserver           roomserver

Start the simple server, which will emulate an OCF/OIC device, and in this case, a light:

$ cd /opt/iotivity/examples/resource/cpp/ ; ./simpleserver

Usage : simpleserver 
    Default - Non-secure resource and notify all observers
    1 - Non-secure resource and notify list of observers

    2 - Secure resource and notify all observers
    3 - Secure resource and notify list of observers

    4 - Non-secure resource, GET slow response, notify all observers
Created resource.
Added Interface and Type
Waiting

Now start the simple client in the another shell session:

$ cd /opt/iotivity/examples/resource/cpp/ ; ./simpleclient

---------------------------------------------------------------------
Usage : simpleclient 
   ObserveType : 1 - Observe
   ObserveType : 2 - ObserveAll
---------------------------------------------------------------------



Finding Resource...
Finding Resource for second time...
In foundResource
In foundResource
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774In foundResource
/oic/d for the first time on server with ID: 4126ec5c-16ce-4b9b-84e6-15ad6e268774
DISCOVERED Resource:
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774/oic/p for the first time on server with ID:         URI of the resource: /oic/d4126ec5c-16ce-4b9b-84e6-15ad6e268774

DISCOVERED Resource:
        URI of the resource: /oic/p
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774/a/light for the first time on server with ID:       Host address of the resource: coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:
        Host address of the resource:           oic.wk.d
        List of resource interfaces:
4126ec5c-16ce-4b9b-84e6-15ad6e268774            oic.if.baseline
                oic.if.r
coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:

                oic.wk.p
        List of resource interfaces:
DISCOVERED Resource:            oic.if.baseline
        URI of the resource: /a/light

                oic.if.r
        Host address of the resource: coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:
                core.light
                core.brightlight
        List of resource interfaces:
                oic.if.baseline
                oic.if.ll
Getting Light Representation...

The OIC specifications describe a RESTful model of communications, where everything is modeled as resources and web-style commands are used to operate on representations of these resources, such as GET, POST, PUT, etc. The communication model is called CRUDN (Create, Retrieve, Update, Delete, Notify). In this example, the IoTivity server sets up resources to describe the (emulated) OIC device. Once the client starts, it tries to discover if there are interesting resources on the network using a multicast GET; the server responds to this with the resources it is hosting. In our example, there is a light resource and a brightlight resource (meaning the light that can have brightness controlled). At this point, the two can speak to each other with the client driving the conversation.

We can see the client getting a representation of the state of the emulated light:

GET request was successful
Resource URI: /a/light
        state: false
        power: 0
        name: John's light

It then creates a state on the server that has a power value of 15.

Putting light representation...
PUT request was successful
        state: true
        power: 15
        name: John's light

Next the client tries to update the light state to a value of 55:

Posting light representation...
POST request was successful
        Uri of the created resource: /a/light1
Posting light representation...
POST request was successful
        state: true
        power: 55
        name: John's light

After this, the client sets up an observe on the server so it will be notified of state changes.

Observe is used.

Observe registration action is successful

The light power is updated in steps of 10, with the client reporting to via prints every time it receives a notification. A typical event looks like:

OBSERVE RESULT:
        SequenceNumber: 0
        state: true
        power: 55
        name: John's light

Meanwhile, we can watch the server report the requests it receives and the actions it takes. Once the light power reaches a certain level and the client sees that the last change has been observed, the connection is shut down.

This is just a basic sample of IoTivity in operation, have fun experimenting with this brand new technology for the Internet of Things! There is more to be done from this state, specifically on the connectivity domain such as adding Bluetooth, BTLE, or LPWAN, since these are what matter the most for IoTivity.

What’s Next?

We can expect that Tizen support will improve soon as it’s becoming one of the reference board.

IoT applications have an incredibly wide range of uses; here is an example of work we’ve done within the automotive context:

Feedback is also welcome if you’d like us to explain anything with more depth, such as Tizen support, Tizen OBS/GBS images, or Tizen Yocto, feel free to keep in touch.

[wp_biographia user="pcoval"]

[wp_biographia user="mats"]

ARTIK is a registered trademark of Samsung.

Author: Phil Coval

Philippe is committed to free software and open hardware and is deeply involved in the Tizen and IoTivity communities.

9 thoughts on “How to Run IoTivity on ARTIK with Yocto”

  1. i tried this post, and successful. i use this :
    ARTIK : run simpleserver
    UBUNTU : run simpleclient
    ARTIK use ethernet

    but i want use WiFi on ARTIK
    i did not found wpa_supplicant on ARTIK
    but i found it on ‘meta’ layer
    what happen this?
    please i need yours help

  2. Thank you for your information, that I am finding. But is it possible to build it on ARTIK710? And Can I build Qt environment to implement my apps on ARTIK710?

    Thank you in advance

  3. Thx for sharing, another question that I have. IoTivity supposes to be an framework. How can I write my own application using IoTivity? I only see several tutorials on the web where they point out how to clone the IoTivity packages, include them to images, compile them and run some sample applications. But when I try to compile my own application, it fails all the time. Can´t figure out why. I have troubles including the right directories.

    Let´t put it that way, I want to applications where I have defined my own resources, both should operate as Client and as Server simultanously and should trigger actions by changing a ressource. How can I do that?

    I appreciate your help. Thanks in advance. Can´t see the forest for the trees, somehow ;)

Comments are closed.