Connecting sensors to Mozilla’s IoT Gateway

Here is a 1st post about Mozilla’s IoT effort, and specifically the gateway project which is illustrating “Web Of Things” concept to create a decentralized Internet of Things, using Web technologies.

Today we will focus on the gateway, as it is the core component of the whole framework. Version 0.4.0 was just released, so you can try it your own on Raspberry Pi 3.  The Raspberry Pi 3 is the reference platform, but it should be possible to port to other single board computers (like ARTIK, etc).

The post will explain how to get started and how to establish basic automation using I2C sensors and actuators on gateway’s device (without any cloud connectivity).

To get started, first install the gateway according to these straightforward instructions:

Prepare SD Card

You need to download the Raspbian based gateway-0.4.0.img.zip (1GB archive) and dump it to SD card (2.6GB min).

lsblk # Identify your sdcard adapter ie:
disk=/dev/disk/by-id/usb-Generic-TODO
url=https://github.com/mozilla-iot/gateway/releases/download/0.4.0/gateway-0.4.0.img.zip
wget -O- $url | funzip | sudo dd of=$disk bs=8M oflag=dsync

If you only want to use the gateway and not hack on it, you can skip this next part which enables a developer shell though SSH.  However, if you do want access to a developer shell, mount the 1st partition called “boot” (you may need to replug your SD card adapter) and add a file to enable SSH:

sudo touch /media/$USER/boot/ssh
sudo umount /media/$USER/*

First boot

Next, install the SD card in your Raspberry PI 3 (Older RPis could work too, particularly if you have a wifi adapter).

When it has completed the first boot, you can check that the Avahi daemon is registering “gateway.local” using mDNS (multicast DNS)

ping gateway.local
ssh pi@gateway.local # Raspbian default password for pi user is "raspberry"

Let’s also track local changes to /etc by installing etckeeper, and change the default password.

sudo apt-get install etckeeper
sudo passwd pi

Logging in

You should now be able to access the web server, which is running on port 8080 (earlier version used 80):

http://gateway.local:8080/

It will redirect you to a page to configure wifi:

URL: http://gateway.local:8080/
Welcome
Connect to a WiFi network?
FreeWifi_secure
FreeWifi
OpenBar
...
(skip)

We can skip it for now:

URL: http://gateway.local:8080/connecting
WiFi setup skipped
The gateway is now being started. Navigate to gateway.local in your web browser while connected to same network as the gateway to continue setup.
Skip

After a short delay, the user should be able to reconnect to the entry page:

http://gateway.local:8080/

The gateway can be registered on mozilla.org for remote management, but we can skip this for now.

Then administrator is now welcome to register new users:

URL: http://gateway.local:8080/signup/
Mozilla IoT
Welcome
Create your first user account:
user: user
email: user@localhost
password: password
password: password
Next

And we’re ready to use it:

URL: http://gateway.local:8080/things
Mozilla IoT
No devices yet. Click + to scan for available devices.
Things
Rules
Floorplan
Settings
Log out

Filling dashboard

You can start filling your dashboard with Virtual Resources,

First hit the “burger menu” icon, go to settings page, and then go to the addons page.

Here you can enable a “Virtual Things” adapter:

URL: http://gateway.local:8080/settings/addons/
virtual-things-adapter 0.1.4
Mozilla IoT Virtual Things Adapter
by Mozilla IoT

Once enabled It should be listed along ThingURLAdapter on the adapters page:

URL: http://gateway.local:8080/settings/adapters
VirtualThingsAdapter
virtual-things
ThingURLAdapter
thing-url-adapter

You can then go back to the 1st Things page (it’s the first entry in the menu):

We can start adding “things” by pressing the bottom menu.

URL: http://gateway.local:8080/things
Virtual On/Off Color Light
Color Light
Save

Then press “Done” at bottom.

From this point, you can decide to control a virtual lamp from the UI, and even establish some basic rules (second entry in menu) with more virtual resources.

Sensing Reality

Because IoT is not about virtual worlds, let’s see how to deal with the physical world using sensors and actuators.

For sensors, there are many way to connect them to computers using analog or digital inputs on different buses.  To make it easier for applications developers, this can be abstracted using W3C’s generic sensors API.

While working on IoT.js‘s modules, I made a “generic-sensors-lite” module that abstracted a couple of I2C drivers from the NPM repository.  To verify the concept, I have made an adapter for Mozilla’s IoT Gateway (which is running Node.js), so I published the generic-sensors-lite NPM module first.

Before using the mozilla-iot-generic-sensors-adapter, you need to enable the I2C bus on the gateway (version 0.4.0, master has I2C enabled by default).

sudo raspi-config
Raspberry Pi Software Configuration Tool (raspi-config)
5 Interfacing Options Configure connections to peripherals
P5 I2C Enable/Disable automatic loading of I2C kernel module
Would you like the ARM I2C interface to be enabled?
Yes
The ARM I2C interface is enabled
ls -l /dev/i2c-1
lsmod | grep i2c
i2c_dev 16384 0
i2c_bcm2835 16384 0

Of course you’ll need at least one real sensor attached to the I2C pin of the board.  Today only 2 modules are supported:

You can double check if addresses are present on I2C the bus:

sudo apt-get install i2c-tools
/usr/sbin/i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77

Install mozilla-iot-generic-sensors-adapter

Until sensors adapter is officially supported by the mozilla iot gateway, you’ll need to install it on the device (and rebuild dependencies on the target) using:

url=https://github.com/rzr/mozilla-iot-generic-sensors-adapter
dir=~/.mozilla-iot/addons/generic-sensors-adapter
git clone --depth 1 -b 0.0.1 $url $dir
cd $dir
npm install

Restart gateway (or reboot)
sudo systemctl restart mozilla-iot-gateway.service
tail -F /home/pi/.mozilla-iot/log/run-app.log

Then the sensors addon can be enabled by pressing the “enable” button on the addons page:

URL: http://gateway.local:8080/settings/addons
generic-sensors-adapter 0.0.1
Generic Sensors for Mozilla IoT Gateway

It will appear on the adapters page too:

URL: https://gateway.local/settings/adapters
VirtualThingsAdapter
virtual-things
ThingURLAdapter
thing-url-adapter
GenericSensorsAdapter
generic-sensors-adapter

Now we can add those sensors as new things (Save and done buttons):

URL: http://gateway.local:8080/things
Ambient Light Sensor
Unknown device type
Save
Temperature Sensor
Unknown device type
Save

Then they will appear as:

  • http://gateway.local:8080/things/0 (for Ambient Light Sensor)
  • http://gateway.local:8080/things/1 (for Temperature Sensor)

To get value updated in the UI, they need to turned on first (try again if you find a big, and file tickets I will forward to drivers authors).

A GPIO adapter can be also used for actuators, as shown in this demo video.

If you have other sensors, check if the community has shared a JS driver, and please let me know about integrating new sensors drivers in generic-sensors-lite

How to Run IoT.js on the Raspberry PI 0

IoT.js is a lightweight JavaScript platform for building Internet of Things devices; this article will show you how to run it on a few dollars worth of hardware. The First version of it was released last year for various platforms including Linux, Tizen, and NuttX (the base of Tizen:RT). The Raspberry Pi 2 is one of the reference targets, but for demo purposes we also tried to build for the Raspberry Pi Zero, which is the most limited and cheapest device of the family. The main difference is the CPU architecture, which is ARMv6 (like the Pi 1), while the Pi 2 is ARMv7, and the Pi 3 is ARMv8 (aka ARM64).

IoT.js upstream uses a python helper script to crossbuild for supported devices, but instead of adding support to new device I tried to build on the device using native tools with cmake and the default compiler options; it simply worked! While working on this, I decided to package iotjs for debian to see how well it will support other architectures (MIPS, PPC, etc), we will see.

Unfortunately, Debian armel isn’t optimized for ARMv6 and FPU, both of which are present on the Pi 1 and Pi 0, so the Raspbian project had to rebuild Debian for the ARMv6+VFP2 ARM variant to support all Raspberry Pi SBC’s.

In this article, I’ll share hints for running IoT.js on Raspbian: the OS officially supported by the Raspberry foundation; the following instructions will work on any Pi device since a portability strategy was preferred over optimization. I’ll demonstrate three separate ways to do this: from packages, by building on the device, and by building in a virtual machine. By the way, an alternative to consider is to rebuild Tizen Yocto for  the Pi 0, but I’ll leave that as an exercise for the reader, you can accomplish this with a bitbake recipe, or you can ask for more hints in the comments section.

How to Run IoT.js on the Raspberry PI 0 - tizen-pizero

Install from Packages

iotjs landed in Debian’s sid, and until it is in testing branch (and subsequently Raspbian and Ubuntu), the fastest way is to download it is via precompiled packages from my personal Raspbian repo

url='https://dl.bintray.com/rzr/raspbian-9-armhf'
source="/etc/apt/sources.list.d/bintray-rzr-raspbian-9-armhf.list"
echo "deb $url raspbian main" | sudo tee "$source"
sudo apt-get update
apt-cache search iotjs
sudo apt-get install iotjs
/usr/bin/iotjs
Usage: iotjs [options] {script | script.js} [arguments]

Use it

Usage is pretty straightforward, start with a hello world source:

echo 'console.log("Hello IoT.js !");' > example.js
iotjs  example.js 
Hello IoT.js !

More details about the current environment can be used (this is for iotjs-1.0 with the default built-in modules):

echo 'console.log(JSON.stringify(process));' > example.js
iotjs  example.js 
{"env":{"HOME":"/home/user","IOTJS_PATH":"","IOTJS_ENV":""},"native_sources":{"assert":true,"buffer":true,"console":true,"constants":true,"dns":true,"events":true,"fs":true,"http":true,"http_client":true,"http_common":true,"http_incoming":true,"http_outgoing":true,"http_server":true,"iotjs":true,"module":true,"net":true,"stream":true,"stream_duplex":true,"stream_readable":true,"stream_writable":true,"testdriver":true,"timers":true,"util":true},"platform":"linux","arch":"arm","iotjs":{"board":"\"unknown\""},"argv":["iotjs","example.js"],"_events":{},"exitCode":0,"_exiting":false} null 2

From here, you can look to use other built-in modules like http, fs, net, timer, etc.

Need More Features?

More modules can be enabled in the master branch, so I also built snapshot packages that can be installed to enable more key features like GPIO, I2C, and more. For your convenience, the snapshot package can be installed to replace the latest release:

root@raspberrypi:/home/user$ apt-get remove iotjs iotjs-dev iotjs-dbgsym iotjs-snapshot
root@raspberrypi:/home/user$ aptitude install iotjs-snapshot
The following NEW packages will be installed:
  iotjs-snapshot{b}
(...)
The following packages have unmet dependencies:
 iotjs-snapshot : Depends: iotjs (= 0.0~1.0+373+gda75913-0~rzr1) but it is not going to be installed
The following actions will resolve these dependencies:
     Keep the following packages at their current version:
1)     iotjs-snapshot [Not Installed]                     
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

     Install the following packages:                 
1)     iotjs [0.0~1.0+373+gda75913-0~rzr1 (raspbian)]
Accept this solution? [Y/n/q/?] y
The following NEW packages will be installed:
  iotjs{a} iotjs-snapshot 
(...)
Do you want to continue? [Y/n/?] y
(...)
  iotjs-snapshot https://dl.bintray.com/rzr/raspbian-9-armhf/iotjs-snapshot_0.0~1.0+373+gda75913-0~rzr1_armhf.deb
  iotjs https://dl.bintray.com/rzr/raspbian-9-armhf/iotjs_0.0~1.0+373+gda75913-0~rzr1_armhf.deb

Do you want to ignore this warning and proceed anyway?
To continue, enter "yes"; to abort, enter "no": yes
Get: 1 https://dl.bintray.com/rzr/raspbian-9-armhf raspbian/main armhf iotjs armhf 0.0~1.0+373+gda75913-0~rzr1 [199 kB]
Get: 2 https://dl.bintray.com/rzr/raspbian-9-armhf raspbian/main armhf iotjs-snapshot armhf 0.0~1.0+373+gda75913-0~rzr1 [4344 B]
(...)

If you the run console.log(process) again, you’ll see more interesting modules to use, like gpio, i2c, uart and more, and external modules can be also used; check on the work in progress for sharing modules to the IoT.js community. Of course, this can be reverted to the latest release by simply installing the iotjs package because it has higher priority than the snapshot version.

root@raspberrypi:/home/user$ apt-get install iotjs
(...)
The following packages will be REMOVED:
  iotjs-snapshot
The following packages will be upgraded:
  iotjs
(...)
Do you want to continue? [Y/n] y
(...)

Build on the Device

It’s also possible to build the snapshot package from source with extra packaging patches, found in the community branch of IoT.js (which can be rebased on upstream anytime).

sudo apt-get install git time sudo
git clone https://github.com/tizenteam/iotjs
cd iotjs
./debian/rules
sudo debi

On the Pi 0, it took less than 30 minutes over NFS for this to finish. If you want to learn more you can follow similar instructions for building IoTivity on ARTIK;
it might be slower, but it will extend life span of your SD Cards.

Build on a Virtual Machine

A faster alternative that’s somewhere between building on the device and setting up a cross build environment (which always has a risk of inconsistencies) is to rebuild IoT.js with QEMU, Docker, and binfmt.

First install docker (I used 17.05.0-ce and 1.13.1-0ubuntu6), then install the remaining tools:

sudo apt-get install qemu qemu-user-static binfmt-support time
sudo update-binfmts --enable qemu-arm

docker build 'http://github.com/tizenteam/iotjs.git'

It’s much faster this way, and took me less than five minutes. The files are inside the container, so they need to be copied back to host. I made a helper script for setup and to get the deb packages ready to be deployed on the device (sudo dpkg -i *.deb) :

curl -sL https://rawgit.com/tizenteam/iotjs/master/run.sh | bash -x -
./tmp/out/iotjs/iotjs-dbgsym_0.0-0_armhf.deb
./tmp/out/iotjs/iotjs-dev_0.0-0_armhf.deb
./tmp/out/iotjs/iotjs_0.0-0_armhf.deb

I used the Resin/rpi-raspbian docker image (thanks again Resin!). Finally, I want to also thank my coworker Stefan Schmidt for the idea after he setup a similar trick for EFL’s CI.

Further Reading

If you want to learn more, here are some additional resources to take your understanding further.

Raspberry Pi is a trademark of the Raspberry Pi Foundation\

Building IoTivity for ARM on ARTIK Devices

There are several options to build IoTivity for ARM targets or any non x86 hardware, but first you have to decide which operating system you want to use. In this article, I won’t compare OS or devices; instead, I’ll give a couple of hints that apply to ARTIK 5, 7, and 10 devices (not the ARTIK 0 family, which run TizenRT). These steps can also be applied to other single board computers like the Raspberry PI.

Build for Tizen with GBS

The first and easiest way to build IoTivity is for Tizen, using GBS. This process was explained in a previous article.

For your knowledge, GBS was inspired by Debian’s git-build-package and uses an ARM toolchain that runs in a chrooted ARM environment using QEMU. Both ARTIK boards and the Raspberry Pi are used as Tizen reference platforms.

Build for Yocto with Bitbake

The second option is to crossbuild with the Yocto toolchain. Theoretically, it should be the fastest way, but in practice it might be the opposite because external packages will be rebuilt from scratch if the project doesn’t provide a Yocto SDK; this can be a long, resource consuming process.

Anyway, this is what is used in some OSS automotive projects (like AGL or GENIVI); the following slides provide a tutorial to get familiar with bitbake and OE layers (like meta-oic for IoTivity).

This can then be deployed to ARTIK 5 or 10 using meta-artik (ARTIK7 might need extra patches).

Cross Building Manually

Another option is to setup your toolchain with the scons environment, but I would not recommend it because you’ll probably lack tracking or control (output binaries will not be packaged) and risk consistency issues. If you choose this method, refer to IoTivity’s wiki page about crossbuilding.

Build on the Device

The last and most obvious option is to build on the device itself; this takes a bit longer, but is totally possible assuming your device has the resources (it worked for me on the RPI3 and ARTIK10). For this to work cleanly I suggest you build system package if your distro is supports it it (.rpm, .deb etc). This way you can track the different build configurations and avoid mistakes caused by manual operations.

Build on ARTIK10

ARTIK 10 supports building with Fedora 22, RPM packages can be built from Tizen’s spec file plus a handful of patches (I needed to use scons install and avoid duplication of packaging efforts). This work is still under review in the master branch, and will be backported to 1.3-rel branch once 1.3.1 is released. Meanwhile, you can clone my sandbox branch.

mkdir -p ${HOME}/rpmbuild/SOURCES/
git clone http://github.com/tizenteam/iotivity -b sandbox/pcoval/on/next/fedora
cd iotivity
git archive HEAD | gzip - > ${HOME}/rpmbuild/SOURCES/iotivity-1.3.1.tar.gz
rpmbuild -ba tools/tizen/iotivity.spec -D "_smp_mflags -j1" 

This is easy because the ARTIK10 has a lot of eMMC and RAM. The 8-core CPU is nice, but it won’t help because parallelizing too much will eat all of the device’s RAM. To be ensure reproductibility use -j1, but if you’re in a hurry you can try -j2 or more.

Build on ARTIK7

The next challenge is the ARITK710 which less powerful than ARTIK10 (RAM=1GB , eMMC=4GB) and uses Fedora 24. This is a slightly less favorable case because there are some extra steps due to the RAM and disk space being more limited. We’ll use extra storage to add a memory swap and mock: a nice Fedora tool to build RPM from git sources (it’s very similar to pbuilder for Debian). Extra storage can be connected to the board via SD or USB bus, but I prefer to use NFS; it’s not optimal, but it works.

Setup NFS

First, setup NFS on your development host and share a directory on the LAN; mine is Debian based:

sudo apt-get install nfs-kernel-server
mkdir -p /tmp/srv/nfs
ifconfig # Note interface IP to be used later

cat /etc/exports
# TODO: LAN's IP might be adjusted here:
/tmp/srv/nfs 192.0.0.0/255.0.0.0(rw,sync,no_root_squash,no_subtree_check)

Use NFS

Now, login to the target and install NFS and the other tools we’ll use:

dnf remove iotivity # Uninstall previous version if present
dnf install nfs-utils mock-scm mock rpm-build screen

Mount a directory for the device:

mnt=/tmp/mnt/nfs/host/$(hostname)/
host=192.168.0.2 # TODO adjust with IP of your host
mkdir -p $mnt ; mount $host:/tmp/srv/nfs $mnt

Attach a swap file:

file="$mnt/swap.tmp"
dd if=/dev/zero of=$file bs=1k count=2097152 # 2GB

losetup /dev/loop0 "$file"
mkswap /dev/loop0
swapon /dev/loop0

Because the eMMC is also limited, the build will be done in remote storage too. This won’t use an NFS shared folder directly because mock doesn’t support it, so let’s cheat it by mounting an ext4 partition file over NFS, the same way we did above:

file="$mnt/ext4.tmp"
dd if=/dev/zero of=$file bs=1k count=2097152 # 2GB

losetup /dev/loop1 "$file"
mkfs.ext4 /dev/loop1

src=/dev/loop1
dst=/var/lib/mock/
mount $src $dst

Build IoTivity

Create a user to run mock on remote filesystem:

user=abuild # TODO change if needed
adduser $user
home="/home/$user"
mnt=/tmp/mnt/nfs/host/$(hostname)/
mkdir -p "$home" "$mnt$home"
chown -Rv $user $s "$home" "$mnt$home"
mount --bind "$mnt$home" "$home"

su -l $user

Mock is pretty straightforward, but here is an example of the upcoming 1.3.1 release with the patches I mentioned above. If necessary, you can rebase your own private repo on it.

package=iotivity
url="https://github.com/TizenTeam/iotivity.git"
branch="sandbox/pcoval/on/next/fedora"
conf="fedora-24-armhfp"
spec=./tools/tizen/iotivity.spec
  
time mock -r "$conf" \
    --scm-enable \
    --scm-option method=git \
    --scm-option package="${package}" \
    --scm-option git_get=set \
    --scm-option write_tar=True \
    --scm-option branch="${branch}" \
    --scm-option git_get="git clone $url" \
    --scm-option spec="${spec}" \
    --resultdir=${HOME}/mock \
    --define "_smp_mflags -j1" \
    #eol

Now wait and check log trace:

You are attempting to run "mock" which requires administrative
privileges, but more information is needed in order to do so.
Authenticating as "root"
Password: 
INFO: mock.py version 1.3.4 starting (python version = 3.5.3)...
(...)
Start: run
(... time to clone and build iotivity repo ...)
Finish: rpmbuild iotivity-1.3.1-0.src.rpm
Finish: build phase for iotivity-1.3.1-0.src.rpm
INFO: Done(/home/abuild/mock/iotivity-1.3.1-0.src.rpm) Config(fedora-24-armhfp) 116 minutes 1 seconds
INFO: Results and/or logs in: /home/abuild/mock
INFO: Cleaning up build root ('cleanup_on_success=True')
Start: clean chroot
Finish: clean chroot
Finish: run

Depending on network bandwidth, RPMs will be produced in a reasonable time (less than a night for sure).

You can now validate reference examples:

su root -c "dnf remove -y iotivity"
su root -c "dnf install -y --allowerasing ${HOME}/mock/iotivity*.arm*.rpm"

rpm -ql iotivity-test

cd /usr/lib/iotivity/resource/examples ; ./simpleserver 2 
# 2 is needed to enable security node.

In other session:

cd /usr/lib/iotivity/resource/examples ; ./simpleclient
GET request was successful
Resource URI: /a/light
Server format in GET response:10000
Server version in GET response:2048

Bringing it all Together

There has been one major relevant change since 1.2.x, the default build configuration is using secured mode (Tizen had it enabled for longer). For developers, this means that if your application is not configured to support security ACL, it won’t work, and you might expect this OC_STACK_UNAUTHORIZED_REQ error:

onGET Response error: 46

The following presentation provides some insight on the IoTivity security features.

The fall back option is to rebuild IoTivity without SECURITY enabled (using –define SECURED 0), but this won’t be certified as OCF compliant. Finally, these build steps can be replicated for other projects using IoTivity.

RPi2: Getting Smart on Tizen

This article is part of a series on Tizen on the Raspberry Pi 2.

Once you’ve got Tizen running on your Raspberry PI 2 (RPi2) using the procedures described in Tizen on RPi2: Now Supporting 3D Acceleration, you will probably want to be able to dynamically add/remove packages. It’s a pain to be required to rebuild and flash your OS every time you want to change the included software, so following this tutorial will help make this much easier. This small tutorial shows how to install the smart tool that is shipped on Tizen, but is not installed by default.

1) Add Smart to the RPi2 Image

The first step is to add the Smart Package Manager (python-smartpm) to the RPi2 Tizen image. This is the same package manager used on Yocto, and Tizen has its own patches for it.

In order to install it, you should apply the following simple patch on your Tizen repository:

--- a/meta-tizen/meta-tizen-common-base/recipes-image/images/tizen-core-image-minimal.bb
+++ b/meta-tizen/meta-tizen-common-base/recipes-image/images/tizen-core-image-minimal.bb
@@ -66,0 +67,2 @@ CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-libav"
+# Package management
+CORE_IMAGE_BASE_INSTALL += "python-smartpm"

If you are unfamiliar with the patching process in linux, create a file that contains the above information, and use patch to apply the patch to: meta-tizen/meta-tizen-common-base/recipes-image/images/tizen-core-image-minimal.bb

Once patched, re-build the image as described on the previous tutorials and copy it to an SD card.

NOTE: You should replace /dev/sdz on the commands below and on the next sections of this article, in order to point to your specific disk that it is mapped. Otherwise you may damage your system!

As shown at Tizen on RPi2: Now Supporting 3D Acceleration, the build and install procedure is:

source ./tizen-common-init-build-env build
bitbake tizen-common-core-image-crosswalk-dev
dd if=tmp-glibc/deploy/images/raspberrypi2/tizen-common-core-image-crosswalk-dev.rpi-sdimg of=/dev/sdz bs=256M && sync

2) Resize the RPi2 Root Image to the Disk Size

By default, the RPi image size is minimal and does not fill the entire SD disk. We likely need to extend it to use all your SD card space, in order to have space to install new rpm packages on it.

Check the first sector number of the second partition of the disk, remember it, and use it to re-create the partition using the maximum sector number as the end of the partition.

In the example below, the first sector is 90112, and the last sector is 15564799. Delete partition 2 and make a new one from 90112 to 15564799. Note this is a slightly dangerous operation – you are deleting the sector with the important data on it. As long as you don’t do anything else in between it should be fine. The usual cautions about making sure which device’s partition table you are changing of course apply.

# fdisk /dev/sdz
Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sdz: 7.4 GiB, 7969177600 bytes, 15564800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000ceb8d

Device      Boot Start     End    Sectors   Size  Id Type
/dev/sdz1   *     8192   90111      81920    40M   c FAT32 W95 (LBA)
/dev/sdz2        90112 1810431    1720320   840M  83 Linux

Command (m for help): d
Partition number (1,2, default 2):

Partition 2 has been deleted.

Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-15564799, default 2048): 90112
Last sector, +sectors or +size{K,M,G,T,P} (90112-15564799, default 15564799):

Created a new partition 2 of type 'Linux' and of size 7.4 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Now, we’ll use the resize2fs command to extend the ext4 filesystem to fill the entire partition. Before that, the partition should be checked with e2fsck. Resize2fs may complain that you need to check again using “e2fsck -f”; if so, follow those instructions.

Those steps are shown below:

# e2fsck /dev/sdz2
e2fsck 1.42.12 (29-Aug-2014)
/dev/sdz2: clean, 16253/215040 files, 174308/215040 blocks
# resize2fs /dev/sdz2
resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on /dev/sdz2 to 1934336 (4k) blocks.
The filesystem on /dev/sdz2 is now 1933312 (4k) blocks long.

3) Put the rpm Files on a Web Server

After the bitbake build completes, you will find RPM packages in the directory build/tmp-glibc/deploy/rpm/. Copy the contents to your apache (or similar) web server root into a suitable directory (if you intend to use the same machine to do the builds and serve the packages, you can also make a symbolic link instead of copying).

The next step assumes that the server is at address 192.168.1.1 and that the files were copied under the rpm directory.

4) Add Smart Repositories to the RPi2 rootfs

Boot the RPi2 Tizen image, and log in as root (the default password is root). Then run the following command to create the package distribution channels on smart:

for i in all cortexa7t2hf_vfp_vfpv4_neon raspberrypi2; do smart channel --add $i type=rpm-md baseurl=http://192.168.1.1/rpm/$i; done

And update the channels with smart update:

# smart update
Loading cache...
Updating cache...        ############################### [100%]

Fetching information for 'all'...
-> http://192.168.1.1/rpm/all/repodata/repomd.xml                
repomd.xml               ############################### [ 16%]
-> http://192.168.1.1/rpm/all/repodata/primary.xml.gz
-> http://192.168.1.1/rpm/all/repodata/filelists.xml.gz
filelists.xml.gz         ############################### [ 25%]
primary.xml.gz           ############################### [ 33%]

Fetching information for 'cortexa7t2hf_vfp_vfpv4_neon'...
-> http://192.168.1.1/rpm/cortexa7t2hf_vfp_vfpv4_neon/repodata/repomd.xml
repomd.xml               ############################## [ 50%]
-> http://192.168.1.1/rpm/cortexa7t2hf_vfp_vfpv4_neon/repodata/primary.xml.gz
primary.xml.gz           ############################## [ 58%]
-> http://192.168.1.1/rpm/cortexa7t2hf_vfp_vfpv4_neon/repodata/filelists.xml.gz
filelists.xml.gz         ############################## [ 66%]

Fetching information for 'raspberrypi2'...
-> http://192.168.1.1/rpm/raspberrypi2/repodata/repomd.xml
repomd.xml               ############################## [ 83%]
-> http://192.168.1.1/rpm/raspberrypi2/repodata/primary.xml.gz
primary.xml.gz           ############################## [ 91%]
-> http://192.168.1.1/rpm/raspberrypi2/repodata/filelists.xml.gz
filelists.xml.gz         ############################## [100%]

Updating cache...        ############################## [100%]

Channels have 5310 new packages.
Saving cache...

5) Install Packages on RPi2!

Now, installing a new package is no more complicated than this simple command:

# smart install crosswalk-thirdparty
Loading cache...
Updating cache...  #################################### [100%]
Computing transaction...
Installing packages (1):
 crosswalk-thirdparty-11.40.277.0-r0@cortexa7t2hf_vfp_vfpv4_neon
917.7MB of package files are needed. 932.1MB will be used.
Confirm changes? (Y/n): y

Fetching packages...
-> http://192.168.1.1/rpm/cortexa7t2hf_vfp_vfpv4_neon/crosswalk-thirdparty-11.40.277.0-r0.cortexa7t2hf_vfp_vfpv4_neon.rpm
crosswalk-thirdparty-11.40.277.0-r0.cortexa7t2hf_vfp_vfpv4_neon.rpm           ########## [100%]

Committing transaction...
Preparing...                                 ########## [  0%]
   1:Installing crosswalk-thirdparty         ########## [100%]

Once you’ve successfully completed these steps, you should be able to install new versions of packages as they are developed without being required to flash your device every time. This seemingly minor change should help save time for anyone trying to build things for Tizen on the RPi2.

Get Involved

If you want to learn more or get involved, you can join us in the Tizen IRC chatroom, or subscribe to the Tizen Community mailing list. Lastly, you can also stay tuned to this blog to catch more articles about building things on Tizen and Raspberry Pi.

Have fun!

Raspberry Pi is a trademark of the Raspberry Pi Foundation

Tizen on RPi2: Now Supporting 3D Acceleration

This article is part of a series on Tizen on the Raspberry Pi 2.

In Bringing Tizen to a Raspberry PI 2 Near You… I described the work we completed to port Tizen to Raspberry Pi 2 (RPi2). Since then, the Samsung Open Source Group has worked hard to add support for 3D acceleration.

UPDATES:

  • Added the -dev images, as they’re now supported.
  • Added bitbake command for building the crosswalk-dev image
  • Added command line for ddrescue
  • The Kernel was updated to Vanilla Tizen Kernel 4.4

This is an update to our original guide that describes how to build a custom Tizen image for the RPi2, and it now includes instructions to enable 3D acceleration. This is based mostly on work completed by our own Derek Foreman. Please note that this uses a driver that is still under development (VC4), written by Eric Anholt from Broadcom, so we don’t recommend its use in production situations.

If you don’t want to wait through the build process (it can take a few hours or more), you can download the latest version of this image here. Once it has downloaded, you can skip to the section titled “Use the Image.”

Step-By-Step Process for Building a Tizen Image for the RPi2

BEFORE STARTING: As a Yocto build needs to download lots of packages and git trees, you should ensure that your firewall policy allows  ftp, http, https and git protocols, otherwise the build may fail. If git:// is blocked, the recipes can be modified to use http – details are beyond the scope of this blog, see the Yocto bitbake documentation.

1) Create a Local Copy of tizen-distro

The first step is to clone the Tizen distro tree. We actually use an alternate version of the already existing tizen.org tizen-distro tree.

Our variant has some patches on the top of the tree that allows building Tizen for ARM CPUs. It also disables the usage of the Open Source mesa/gallium 3D driver, since the Broadcom GPU used on Raspberry PI2 is not currently supported by this open source driver. The plan is to rework these patches to submit them to Tizen upstream, without breaking anything for x86.

To create the clone, do the following from any terminal window:

git clone git://git.s-osg.org/tizen-distro.git
cd tizen-distro
git checkout 3d_accel_vc4

2) Add Raspberry PI 2 BSP Meta Repository

Yocto works with several layers of software. The BSP (Board Supported Package) layer provides support for the board, and writing a BSP can consume a lot of time. Fortunately, there’s already a Yocto BSP for Raspbery PI 2, and the only extra requirement is to adjust the BSP to work with Tizen. Again, we opted to create a fork of the tree, to avoid interfering with other distros supported by this BSP, but the plan is to rework these patches in order to submit them to Yocto upstream in a way that would not affect builds for other distros.

The steps to create the clone are (starting in the tizen-distro directory created above):

git clone git://git.s-osg.org/meta-raspberrypi.git
cd meta-raspberrypi
git checkout 3d_accel_vc4
cd ..

3) Initialize the Environment to Prepare for Build

Now that we have a copy of both the Tizen and BSP Yocto bits, we need to set up the build environment in order to use bitbake. It should be noted that some packages may need to be installed, depending on the distribution you’re using on the build machine. The Yocto builder (bitbake) requires Python 2.7.3 or greater. So, we don’t recommend using an LTS distro for the build, as it may have packages that are too old. Here, we used Fedora 21, as it provides recent packages while being stable enough for desktop needs.

The command to initialize the build environment is:

source ./tizen-common-init-build-env build

4) Modify Config Files to Point to Build for Raspberry PI2

The Tizen build is controlled by configuration files. Assuming Tizen was installed at ~/tizen-distro the previous steps would have changed the working directory to the new build directory. So, the current directory should be ~/tizen-distro/build and the configuration files are in the ./conf directory.

From the build directory, you’ll need to edit the conf/local.conf with your favorite editor. You should comment out any existing line that starts with “MACHINE”, and add the line bellow:

MACHINE ??= "raspberrypi2"

This will tell bitbake that it should compile for the Raspberry PI 2 board.

Now, we need to add the BSP meta-raspberrypi layer to the conf/bblayers.conf file, at both BBLAYERS and BBLAYERS_NON_REMOVABLE. Again, use your favorite editor.

After the changes, the file contents should look like the one below, with your home directory instead of /home/mchehab:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

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

BBLAYERS ?= " \
  /home/mchehab/tizen-distro/meta \
  /home/mchehab/tizen-distro/meta-raspberrypi \
  /home/mchehab/tizen-distro/meta-openembedded/meta-oe \
  /home/mchehab/tizen-distro/meta-openembedded/meta-multimedia \
  /home/mchehab/tizen-distro/meta-openembedded/meta-ruby \
  /home/mchehab/tizen-distro/meta-openembedded/meta-systemd \
  /home/mchehab/tizen-distro/meta-openembedded/meta-gnome \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation/meta \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation/meta-oe \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-base \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-share \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-devtools \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-demo \
"

BBLAYERS_NON_REMOVABLE ?= " \
  /home/mchehab/tizen-distro/meta \
  /home/mchehab/tizen-distro/meta-raspberrypi \
  /home/mchehab/tizen-distro/meta-openembedded/meta-oe \
  /home/mchehab/tizen-distro/meta-openembedded/meta-multimedia \
  /home/mchehab/tizen-distro/meta-openembedded/meta-ruby \
  /home/mchehab/tizen-distro/meta-openembedded/meta-systemd \
  /home/mchehab/tizen-distro/meta-openembedded/meta-gnome \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation-oe-core \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation-meta-oe \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-base \
"

Notice the new entry for “~/tizen-distro/meta-raspberrypi \” in each of the sections.

5) Start Building

Now that everything is set, it is time to start the build. This is the step that will take a considerable amount of time, and will require a good Internet connection because it will download thousands of packages and/or clone upstream git trees for several packages.

Do this by running the bitbake command to generate an image. Currently, the following images are supported:

Image name Details
rpi-hwup-image Raspberry PI2 minimal image plus gstreamer
tizen-common-core-image-minimal Tizen common core image with the bare minimum Tizen packages
tizen-core-image-minimal Tizen minimal image – has application launchers for test apps
tizen-common-core-image-crosswalk Tizen image with crosswalk HTML application runtime
tizen-core-image-minimal-dev Same as tizen-core-image-minimal plus some additional development packages
tizen-common-core-image-crosswalk-dev Same as tizen-common-core-image-crosswalk plus some additional development packages

NOTE: Those images are the minimal images. They can incremented by adding more packages at the bitbake recipe. For example, if you want to add gstreamer to tizen-core-image-minimal, you could edit ./meta-tizen/meta-tizen-common-base/recipes-image/images/tizen-core-image-minimal.bb and add there the following lines:

CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-meta-base"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-meta-audio"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-meta-video"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-meta-debug"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-plugins-good-meta"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-plugins-base-meta"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-plugins-ugly-meta"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-plugins-bad-meta"
CORE_IMAGE_BASE_INSTALL += "gstreamer1.0-libav"

So, for example, in order to build the most complete image, you can run the command:

$ bitbake tizen-common-core-image-crosswalk-dev

If everything goes well with bitbake, the images will be located in the tmp-glibc/deploy/images/raspberrypi2 directory, and will look like the ones below:

$ ls tmp-glibc/deploy/images/raspberrypi2/
bcm2835-bootfiles
Image
Image--4.1.0+git07009cab090ade3dd180e8a55d590b1a00072eed-r0-bcm2708-rpi-b-20150710122011.dtb
Image--4.1.0+git07009cab090ade3dd180e8a55d590b1a00072eed-r0-bcm2708-rpi-b-plus-20150710122011.dtb
Image--4.1.0+git07009cab090ade3dd180e8a55d590b1a00072eed-r0-bcm2709-rpi-2-b-20150710122011.dtb
Image--4.1.0+git07009cab090ade3dd180e8a55d590b1a00072eed-r0-raspberrypi2-20150710122011.bin
Image-bcm2708-rpi-b.dtb
Image-bcm2708-rpi-b-plus.dtb
Image-bcm2709-rpi-2-b.dtb
Image-raspberrypi2.bin
modules--4.1.0+git07009cab090ade3dd180e8a55d590b1a00072eed-r0-raspberrypi2-20150710122011.tgz
modules-raspberrypi2.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
rpi-hwup-image-raspberrypi2-20150710132847.rootfs.ext3
rpi-hwup-image-raspberrypi2-20150710132847.rootfs.manifest
rpi-hwup-image-raspberrypi2-20150710132847.rootfs.rpi-sdimg
rpi-hwup-image-raspberrypi2-20150710132847.rootfs.tar.bz2
rpi-hwup-image-raspberrypi2.ext3
rpi-hwup-image-raspberrypi2.manifest
rpi-hwup-image-raspberrypi2.rpi-sdimg
rpi-hwup-image-raspberrypi2.tar.bz2

Use the Image

Be careful at this point, because the steps below should be run as root, and will rewrite a disk image. If you do something wrong at this point, you may end by damaging what’s stored on your disks! Let’s assume that the SD card will be mapped as /dev/sdc. Replace /dev/sdc with the device where your SD card is stored. To find out where your device is mapped, you can run the command:

$ df -aTh

WARNING: In the next section, be sure to change any instance of /dev/sdc to your specific disk that it is mapped. Otherwise you may damage your system!

1) Fill the SD Card With the Image

Insert an SD card into your computer using an SD->USB adapter and check if it was mapped at /dev/sdc.

The current image size is about 620 MB. Be sure to have an SD card big enough to fit the size of the generated image.

Now, write the image with the following command:

# dd if=tmp-glibc/deploy/images/raspberrypi2/tizen-common-core-image-crosswalk-dev-raspberrypi2.rpi-sdimg of=/dev/sdc bs=256M; sync
3+1 records in
3+1 records out
935329792 bytes (935 MB) copied, 91.798 s, 6.7 MB/s

NOTE: the actual image size may vary, as we add more packages to the build image.

Please notice that the above is for the rpi-hwup-image. If the selected bitbake target is different, you need to change the above accordingly.

You may, instead use ddrescue:

# ddrescue tmp-glibc/deploy/images/raspberrypi2/tizen-common-core-image-crosswalk-dev-raspberrypi2.rpi-sdimg /dev/sdc -Df
GNU ddrescue 1.20
Press Ctrl-C to interrupt
rescued:   935329 kB,   errsize:         0 B,    current rate:   4325 kB/s
   ipos:   935264 kB,    errors:         0,      average rate:  11991 kB/s
   opos:   935264 kB,  run time:      1m 18s,  remaining time:         n/a
time since last successful read:          0s
Finished                                     

The image is now created and you can use it to boot into Tizen.

NOTE: The root password used on this image will be “root”.

Get Involved

Now, You’re ready to use Tizen on your Raspberry PI 2 with 3D acceleration. Please notice that this uses a WIP GPU driver. So, I don’t recommend using it in production. If you want to learn more or get involved, you can join us in the Tizen IRC chatroom, or subscribe to the Tizen Community mailing list. Lastly, you can also stay tuned to this blog to catch more articles about building things on Tizen and Raspberry Pi. Have fun!

Raspberry Pi is a trademark of the Raspberry Pi Foundation

Bringing Tizen to a Raspberry PI 2 Near You…

This article is part of a series on Tizen on the Raspberry Pi 2.

The Raspberry Pi is the most popular single-board computer with more than 5 million sold. While there are numerous Linux Distributions that run on RPI including Raspbian, Pidora, Ubuntu, OSMC, and OpenElec, the Tizen OS does not currently run on it. Since Tizen is being positioned as an important player within the growing Internet of Things (IoT) ecosystem, providing a Raspberry PI 2 port can help developers gain more Tizen experience. For this reason, the Samsung Open Source group decided to work on such port. This article will go over how to build a bootable Tizen image for Raspberry Pi from a computer running Linux.

The Raspberry Pi 2 has several advantages over the first version. Among them:

  • It has a quad-core CPU
  • It runs at 900 MHz
  • It uses an ARM Cortex-A7 CPU

The ARM Cortex-A7 CPU is very nice since most distributions are compiled to use the arm instruction set found on ARMv7 processors.

Initial Tests

Before doing a native Tizen build, we needed to determine if the new Raspberry PI2 was capable of running Tizen. To do this, we used a small trick: we downloaded a pre-built Tizen image found at tizen.org and borrowed a Debian boot image. Since the Tizen root image was built for ARMv7, the image ran properly on Raspberry Pi 2, except for a few issues related to graphics. That gave us enough confidence to go to step 2: building the boot image and root machine targeted for Raspberry Pi2.

Building Images on Tizen

Currently, as described on the Tizen Wiki, there are two ways used to build a Tizen image:

  • Via GBS: The “traditional” way, which requires setting up a GBS server to compile several packages
  • Via Yocto: The “new” way, which uses OpenEmbedded bitbake recipes to generate the image. This can easily be done on a user’s machine, provided a good Internet link is available.

GBS would require a lot of time, and we would need to allocate a dedicated build server, because of this, we decided to use Yocto to produce the images.

Creating a Tizen image for Raspberry PI2

BEFORE STARTING: As Yocto build will download lots of packages, you should ensure that your firewall policy won’t be blocking ftp, http, https and git protocols, as otherwise the build may fail.

1) Create a Local Copy of tizen-distro

The first step is to clone the Tizen distro tree. We actually use an alternate version of the already existing tizen.org tizen-distro tree.

Our variant has some patches on the top of the tree that allows building Tizen for ARM CPUs. It also disables the usage of the Open Source mesa/gallium 3D driver, since the Broadcom GPU used on Raspberry PI2 is not currently supported by this open source driver. The plan is to rework these patches to submit them to Tizen upstream, without breaking anything for x86.

To create the clone, do the following from any terminal window:

git clone git://git.s-osg.org/tizen-distro.git

2) Add Raspberry PI 2 BSP Meta Repository

Yocto works with several layers of software. The BSP (Board Supported Package) layer provides support for the board, and writing a BSP can consume a lot of time. Fortunately, there’s already a Yocto BSP for Raspbery PI 2, and the only extra requirement is to adjust the BSP to work with Tizen. Again, we opted to create a fork of the tree, to avoid interfering with other distros supported by this BSP, but the plan is to rework these patches in order to submit them to Yocto upstream in a way that would not affect builds for other distros.

The steps to create the clone is:

cd tizen-distro
git clone git://git.s-osg.org/meta-raspberrypi.git

3) Initialize the Environment to Prepare for Build

Now that we have a copy of both the Tizen and BSP Yocto bits, we need to setup the build environment in order to use bitbake. It should be noted that some packages may be needed to be installed, depending on the distribution you’re using at the build machine. The Yocto builder (bitbake) requires Python 2.7.3 or greater. So, we don’t recommend using an LTS distro for the build, as it may have packages that are too old. Here, we used Fedora 21, as it provides recent packages, while being stable enough for desktop needs.

The command to initialize the build environment is:

source ./tizen-common-init-build-env build

4) Modify Config Files to Point to Build for Raspberry PI2

The Tizen build is controlled by configuration files. Assuming Tizen was installed at ~/tizen-distro the previous steps would have changed the working directory to the new build directory. So, the current directory should be ~/tizen-distro/build and the configuration files are in the ./conf directory.

From the build directory, you’ll need to edit the conf/local.conf with your favorite editor. You should comment out any existing line that starts with “MACHINE”, and add the line bellow:

MACHINE ??= "raspberrypi2"

This will tell bitbake that it should compile for Raspberry PI 2 board.

Now, we need to add the BSP meta-raspberrypi layer to the conf/bblayers.conf file, at both BBLAYERS and BBLAYERS_NON_REMOVABLE. Again, use your favorite editor.

After the changes, the file contents should look like the one below, with your home directory instead of /home/mchehab:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

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

BBLAYERS ?= " \
  /home/mchehab/tizen-distro/meta \
  /home/mchehab/tizen-distro/meta-raspberrypi \
  /home/mchehab/tizen-distro/meta-openembedded/meta-oe \
  /home/mchehab/tizen-distro/meta-openembedded/meta-multimedia \
  /home/mchehab/tizen-distro/meta-openembedded/meta-ruby \
  /home/mchehab/tizen-distro/meta-openembedded/meta-systemd \
  /home/mchehab/tizen-distro/meta-openembedded/meta-gnome \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation/meta \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation/meta-oe \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-base \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-share \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-devtools \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-demo \
"

BBLAYERS_NON_REMOVABLE ?= " \
  /home/mchehab/tizen-distro/meta \
  /home/mchehab/tizen-distro/meta-raspberrypi \
  /home/mchehab/tizen-distro/meta-openembedded/meta-oe \
  /home/mchehab/tizen-distro/meta-openembedded/meta-multimedia \
  /home/mchehab/tizen-distro/meta-openembedded/meta-ruby \
  /home/mchehab/tizen-distro/meta-openembedded/meta-systemd \
  /home/mchehab/tizen-distro/meta-openembedded/meta-gnome \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation-oe-core \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-adaptation-meta-oe \
  /home/mchehab/tizen-distro/meta-tizen/meta-tizen-common-base \
"

Notice the new entry for “~/tizen-distro/meta-raspberrypi \” in each of the sections.

5) Start building

Now that everything is set, it is time to start the build. This is the step that will take a considerable amount of time, and will require a good Internet connection because it will download thousands of packages and/or clone upstream git trees for several packages.

Do this by running the following command:

bitbake rpi-hwup-image

NOTE: On some distros, this step will cause an error (this has been confirmed on multiple Debian-based distros):

ERROR: Task 400 (/tizen-distro/meta-tizen/meta-tizen-common-base/recipes-extended/pam/pam_git.bb, do_compile) failed with exit code '1'

If such an error happens, just pull an extra patch, and re-run bitbake with the following commands:

git pull . origin/tizen-debianhost
bitbake rpi-hwup-image

If everything goes well, the images will be located in the tmp-glibc/deploy/images/raspberrypi2 directory, and will look like the ones below:

$ ls tmp-glibc/deploy/images/raspberrypi2/
bcm2835-bootfiles
Image
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-bcm2708-rpi-b-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-bcm2708-rpi-b-plus-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-bcm2709-rpi-2-b-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-ds1307-rtc-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-hifiberry-amp-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-hifiberry-dac-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-hifiberry-dacplus-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-hifiberry-digi-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-iqaudio-dac-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-iqaudio-dacplus-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-lirc-rpi-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-pcf8523-rtc-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-pps-gpio-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-raspberrypi2-20150409151425.bin
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-w1-gpio-overlay-20150409151425.dtb
Image--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-w1-gpio-pullup-overlay-20150409151425.dtb
Image-bcm2708-rpi-b.dtb
Image-bcm2708-rpi-b-plus.dtb
Image-bcm2709-rpi-2-b.dtb
Image-ds1307-rtc-overlay.dtb
Image-hifiberry-amp-overlay.dtb
Image-hifiberry-dac-overlay.dtb
Image-hifiberry-dacplus-overlay.dtb
Image-hifiberry-digi-overlay.dtb
Image-iqaudio-dac-overlay.dtb
Image-iqaudio-dacplus-overlay.dtb
Image-lirc-rpi-overlay.dtb
Image-pcf8523-rtc-overlay.dtb
Image-pps-gpio-overlay.dtb
Image-raspberrypi2.bin
Image-w1-gpio-overlay.dtb
Image-w1-gpio-pullup-overlay.dtb
modules--3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0-raspberrypi2-20150409151425.tgz
modules-raspberrypi2.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
rpi-hwup-image-raspberrypi2-20150409151425.rootfs.ext3
rpi-hwup-image-raspberrypi2-20150409151425.rootfs.manifest
rpi-hwup-image-raspberrypi2-20150409151425.rootfs.rpi-sdimg
rpi-hwup-image-raspberrypi2-20150409151425.rootfs.tar.bz2
rpi-hwup-image-raspberrypi2.ext3
rpi-hwup-image-raspberrypi2.manifest
rpi-hwup-image-raspberrypi2.rpi-sdimg
rpi-hwup-image-raspberrypi2.tar.bz2

Use the Image

Be careful at this point, because the steps below should be run as root, and will rewrite a disk image. If you do something wrong at this point, you may end by damaging what’s stored on your disks!

Let’s assume that the SD card will be mapped as /dev/sdc. Replace /dev/sdc with the device where your SD card is stored. To find out where your device is mapped, you can run the command:

$ df -aTh

WARNING: In the next section, be sure to change any instance of /dev/sdc to your specific disk that it is mapped. Otherwise you may damage your system!

1) Fill the SD Card With the Image

Insert an SD card on your computer using an SD->USB adapter and check if it was mapped at /dev/sdc.

The current image size is about 620 MB. Be sure to have an SD card big enough to fit the size of the generated image.

Now, write the image with the following command:

# dd if=tmp-glibc/deploy/images/raspberrypi2/rpi-hwup-image-raspberrypi2.rpi-sdimg of=/dev/sdc bs=128M && sync
4+1 records in
4+1 records out
616562688 bytes (617 MB) copied, 91.798 s, 6.7 MB/s

NOTE: the actual image size may vary, as we add more packages to the build image.

The image is now created and you can use it to boot into Tizen.

NOTE: The root password used on this image will be “root”.

2) Optional: Resize the Root Image to the Disk Size

By default, the image size doesn’t fill the entire SD disk. If you want to extend it to use all your SD card space, you can check what’s the first sector of the second partition of the disk.

Assuming that the first sector is 49152, you should delete it and re-create, using the maximum SD size as the last sector, as shown below:

# fdisk /dev/sdc
Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sdc: 7.4 GiB, 7969177600 bytes, 15564800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000ceb8d

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 8192 49151 40960 20M c W95 FAT32 (LBA)
/dev/sdc2 49152 1204223 1155072 564M 83 Linux

Command (m for help): d
Partition number (1,2, default 2):

Partition 2 has been deleted.

Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-15564799, default 2048): 49152
Last sector, +sectors or +size{K,M,G,T,P} (49152-15564799, default 15564799):

Created a new partition 2 of type 'Linux' and of size 7.4 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Now, we’ll use e2fsck to extend the ext4 partition to fill the entire partition. Before that, the partition should be checked with e2fsck.

Those steps are shown below:

# e2fsck -f /dev/sdc2
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Setting filetype for entry 'uncompress' in /bin (12) to 1.
Setting filetype for entry 'mke2fs' in /sbin (317) to 1.
Setting filetype for entry 'mkfs.ext4dev' in /sbin (317) to 1.
Setting filetype for entry 'fsck.ext3' in /sbin (317) to 1.
Setting filetype for entry 'mkfs.ext4' in /sbin (317) to 1.
Setting filetype for entry 'e2fsck' in /sbin (317) to 1.
Setting filetype for entry 'fsck.ext4' in /sbin (317) to 1.
Setting filetype for entry 'mkfs.ext2' in /sbin (317) to 1.
Setting filetype for entry 'fsck.ext4dev' in /sbin (317) to 1.
Setting filetype for entry 'arm-oe-linux-gnueabi-ld' in /usr/bin (416) to 1.
Setting filetype for entry 'gawk' in /usr/bin (416) to 1.
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc2: 3647/60480 files (0.8% non-contiguous), 157146/241664 blocks

# sudo resize2fs /dev/sdc2
resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on /dev/sdc2 to 7757824 (1k) blocks.
The filesystem on /dev/sdc2 is now 7757824 (1k) blocks long.

Get Involved

Now, You’re ready to use Tizen on your Raspberry PI 2. If you want to learn more or get involved, you can join us in the Tizen IRC chatroom, or subscribe to the Tizen Community mailing list. Lastly, you can also stay tuned to this blog to catch more articles about building things on Tizen and Raspberry Pi. Have fun!

Raspberry Pi is a trademark of the Raspberry Pi Foundation