Skip navigation
1 2 3 Previous Next

RIoTboard

81 posts

This post documents a recent build of Android 4.3 Jelly Bean for RIoTboard on a fresh installation of openSUSE 13.2 x86_64. The build images were transferred to an SD card using Linux commands rather than using the MFGTool.

 

HARDWARE AND BUILD OS

 

Gateway NE56R12u Laptop running openSUSE 13.2 x86_64 DVD

     2.1 GHz Intel B950 dual-core Pentium processor

     8 GB physical RAM

     135 GB /home partition for build

     60 Mbs Internet connection

 

 

RESOURCES

 

RIoTboard User Manual Version 2.1 (RioTboard-User-Manual-V2.1.pdf)

Freescale Semiconductor Android User's Guide, Document Number : AUG, Rev. jb4.2.2_1.0.0-GA, 05/2013 (android_user_guide.pdf)

https://source.android.com/source/initializing.html

Building Android from Source

RIoTboard - Android KitKat Build on openSUSE 13.2 x86_64

 

 

UPDATE openSUSE 13.2 x86_64

 

As openSUSE 13.2 has reached end-of-life, there will be no future updates via the regular repositories. If you did not update openSUSE 13.2 during installation, then use YaST or the system tray icon to do so now.

 

 

INSTALL NECESSARY PACKAGES

 

sudo zypper install git gpg2 flex bison gperf zip curl zlib-devel gcc-c++ glibc-devel-32bit ncurses-devel-32bit xproto-devel libx11-devel zlib-devel-32bit ccache Mesa-libGL-devel libxml2-2 libxml2-tools libxslt1 libxslt-tools unzip u-boot-tools libuuid-devel lzo-devel perl-Switch

 

Note that perl-Switch must also be installed in addition to the packages necessary to build Android KitKat on openSUSE 13.2.

 

 

INSTALL MAKE

 

Make is problematic in openSUSE 13.2 since the regular repositories only provide Version 4.0, but Android compilation requires Version 3.81 or 3.82. Since openSUSE 13.1 is the most recent release with Version 3.82, I used a copy of its make RPM. Here is the file source I used:

 

ftp://195.220.108.108/linux/opensuse/distribution/13.1/repo/oss/suse/x86_64/make-3.82-160.2.1.x86_64.rpm

Remove make Version 4.0 and install make 3.82:

 

sudo zypper remove make
sudo rpm -ivh make-3.82-160.2.1.x86_64.rpm

 

Once you have installed make Version 3.82, you will likely be prompted by the software updater in the system tray to update, so resist the urge to do so.

 

 

INSTALL JAVA 6 JDK

 

I had a copy of the Oracle Java 6 Update 43 JDK RPM tucked away in my archive, so I used it as the Java JDK. The “Recompiling Android” post above has a link to the more recent Oracle Java 6 Update 45 JDK RPM (remember to use the x64 version):

 

Java Archive Downloads - Java SE 6

 

Execute the .bin file to install the JDK:

 

mkdir ~/jtemp
mv jdk-6u43-linux-x64-rpm.bin ~/jtemp/
cd ~/jtemp
sudo chmod a+x jdk-6u43-linux-x64-rpm.bin
sudo ./jdk-6u43-linux-x64-rpm.bin

 

Log out and log back in.

 

If you have a notion to install OpenJDK instead of Oracle Java JDK, you will be obliged to get packages from an outside repository as openSUSE 13.2 only provides packages for OpenJDK 1.7 and OpenJDK 1.8. An OpenJDK Version 1.6 RPM release for openSUSE 12.1 x86_64 does exist, and it may or may not be adequate (it's quite old):

 

https://www.rpmfind.net/linux/RPM/opensuse/12.1/x86_64/java-1_6_0-openjdk-devel-1.6.0.0_b22.1.10.4-1.2.x86_64.html

 

Android build scripts expect Oracle Java JDK, so using OpenJDK will require script modifications. See the Building Android from Source link above for more information.

 

 

OBTAIN ANDROID SOURCE CODE

 

curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
mkdir ~/android-imx6-jb4.3_1.0.0
cd ~/android-imx6-jb4.3_1.0.0
repo init --repo-url=git://github.com/android/tools_repo.git -u git://github.com/embest-tech/imx-manifest.git -m embest_android_jb4.3_1.0.0
repo sync -j4

 

 

MANUALLY APPLY GITHUB REVERSION

 

The problem: If you were to attempt to build Android 4.3 Jelly Bean right now, your effort would end in failure. Towards the end of the build process, you would see almost two dozen “cannot find symbol” errors relating to the class EthernetDataTracker as noted in the following threads:

 

Unable to do initial 'make' on Jelly Bean (4.3)
Building Android from Source

 

The cause: These errors stem from a GitHub commit to embest-tech/imx-manifest on 22 December 2014 where the embest_android_jb4.3_1.0.0 manifest was altered. As a result of this commit, one package (fsl_imx_demo) was removed, and one package (Ethernet) was added to the manifest. Unfortunately, the Ethernet package is incomplete due to missing class elements in EthernetDataTracker, and this breaks the build process.

 

The solution: Ideally, the solution would be to rescind the 22 December 2014 commit or add an additional commit restoring the embest_android_jb4.3_1.0.0 manifest to its pre-22 December 2014 state. With interest in RIoTboard waning, I wouldn't hold my breath waiting for this, although to be fair, no one has yet posted any Issue on GitHub indicating that the problem exists. Happily, the repository for fsl_imx_demo is still in place, and this leads to...

 

The workaround: It's fairly easy to manually revert the Android 4.3 source code we just obtained to a pre-22 December 2014 state. We just need to do the following:

 

1. Replace the embest_android_jb4.3_1.0.0 manifest

2. Delete the offending Ethernet package from the source tree

3. Download and install the fsl_imx_demo package into the source tree

 

For (1), go to this URL which has the various Embest Android manifests as of 1 December 2014:

 

https://github.com/embest-tech/imx-manifest/tree/72fc2a8c8e1ee0a16d5ca3d06095f16b6d8927cf

 

Click the Clone or Download button, then click the Download ZIP option, and save the file. Unzip the archive, and if you burrow into it, you will find four manifests, one of which is named embest_android_jb4.3_1.0.0. If you are cautious, you can check to make sure that fsl_imx_demo is present and not commented out in the manifest by using a text editor. You now need to copy the manifest into the ~/android-imx6-jb4.3_1.0.0/.repo/manifests directory or whatever corresponds to this if you are using a different base directory compared to what I have used in this procedure so far. You should be replacing an existing file as you do this.

 

For (2), it is necessary to delete the directory ~/android-imx6-jb4.3_1.0.0/packages/apps/Ethernet

 

For (3), you can download the fsl_imx_demo package here:

 

https://github.com/embest-tech/android_packages_apps_fsl_imx_demo

 

Click the Clone or Download button, then click the Download ZIP option, and save the file. Unzip the archive, and you will find a directory named android_packages_apps_fsl_imx_demo-master. Rename this directory to fsl_imx_demo. It should contain a directory FSLOta, a file Android.mk and a file readme. Copy this fsl_imx_demo directory to ~/android-imx6-jb4.3_1.0.0/packages/apps/.

 

You now have prospects for a successful build and functional Ethernet when finished.

 

 

SELECT SD CARD OR EMMC BUILD

 

Open android-imx6-jb4.3_1.0.0/device/fsl/RIoTboard_6solo/BoardConfig.mk in your favorite editor and change

 

BUILD_TARGET_LOCATION ?= emmc

 

to

 

BUILD_TARGET_LOCATION ?= sdmmc

 

since we want to create an SD card image. Save the file.

 

 

BUILD ANDROID

 

cd ~/android-imx6-jb4.3_1.0.0

source build/envsetup.sh

lunch (Select RIoTboard_6solo-user)

make clean

time make -j4

 

The -j4 parameter in the make command is important as this reduced build times on my dual core laptop to 2.5 hours. At the very least you want as many jobs as you have CPU cores (-j2 in my case), but in my tests, increasing beyond that yields only marginal improvement.

 

 

CREATE A BOOTABLE SD CARD

 

The resulting image files to create an SD card for booting RIoTboard are located in ~/android-imx6-jb4.3_1.0.0/out/target/product/RIoTboard_6solo/:

 

boot.img

recovery.img

system.img

u-boot.bin

 

Per the Freescale Semiconductor Android User's Guide, a Linux script to generate the necessary partitions on a blank SD card to boot Android is located in ~/android-imx6-jb4.3_1.0.0/device/fsl/common/tools/fsl-sdcard-partition.sh.

 

Determine the device designation for the SD card in your system. You can use the lsblk command to do this by executing the command first without the SD card inserted, and then again with the SD card inserted.:

 

stmorgan@GATEWAY:~$ lsblk

NAME MAJ:MIN RM SIZE   RO TYPE MOUNTPOINT

sda    8:0   0  465.8G 0  disk 

sda1   8:1   0  100M   0  part 

sda2   8:2   0  288G   0  part 

sda3   8:3   0  1K     0  part 

sda5   8:5   0  169.8G 0  part /

sda6   8:6   0  7.9G   0  part [SWAP]

sr0   11:0   1  1024M  0  rom  


stmorgan@GATEWAY:~$ lsblk

NAME MAJ:MIN RM SIZE   RO TYPE MOUNTPOINT

sda    8:0   0  465.8G 0  disk 

sda1   8:1   0  100M   0  part 

sda2   8:2   0  288G   0  part 

sda3   8:3   0  1K     0  part 

sda5   8:5   0  169.8G 0  part /

sda6   8:6   0  7.9G   0  part [SWAP]

sdd    8:48  1  29.8G  0  disk

sdd1   8:49  1  29.8G  0  part /media/9016-4EF8

sr0   11:0   1  1024M  0  rom  

 

So I would use /dev/sdd for the SD card on my system. Note that this is not an empty SD card, as indicated by the presence of the mounted sdd1 partition.


In the following discussion, /dev/sdX will be used for the SD card, BUT YOU MUST REMEMBER TO CHANGE THE DEVICE DESIGNATION TO MATCH YOUR CARD IN ALL COMMANDS THAT FOLLOW.


Use your favorite method to remove all partitions from your SD card. If the partitioning tool used to remove partitions asks whether to use an MS-DOS or GPT scheme, use MS-DOS.


Execute the following commands after an SD card with no partitions has been inserted into the system:

 

cd ~/android-imx6-jb4.3_1.0.0/device/fsl/common/tools
sudo ./fsl-sdcard-partition.sh /dev/sdX

 

Eject the SD card from the system and reinsert it. This is a necessary step on my Gateway laptop, otherwise the following commands will not generate a usable image, although they give the outward appearance of doing what they are supposed to do.

 

cd ~/android-imx6-jb4.3_1.0.0/out/target/product/RIoTboard_6solo
sudo dd if=u-boot.bin of=/dev/sdX bs=1K skip=1 seek=1; sync
sudo dd if=boot.img of=/dev/sdX1; sync
sudo dd if=system.img of=/dev/sdX5; sync
sudo dd if=recovery.img of=/dev/sdX2; sync

 

The SD card can now be used to boot Android on the RIoTboard.

 

It's worth mentioning that there is a difference between the partition organization yielded by the above procedure versus that used in the Element14 pre-built SD card image. The Element14 image uses a partitioning scheme identical to that described in the Freescale Semiconductor Android User's Manual (presumably a byproduct of using MFGTool in a Windows environment), so the partitions are physically ordered as follows:

 

PARTITION TYPE/INDEX     NAME

N/A                      U-Boot Loader

Primary 1                Boot

Primary 2                Recovery

Logical 5 (Extended 3)   SYSTEM

Logical 6 (Extended 3)   CACHE

Logical 7 (Extended 3)   Device

Logical 8 (Extended 3)   Misc

Primary 4                DATA

 

The procedure used above reverses the Extended 3 and Primary 4 partitions, so the resulting physical order is as follows:

 

PARTITION TYPE/INDEX     NAME

N/A                      U-Boot Loader

Logical 1                Boot

Logical 2                Recovery

Logical 3                (small stub)

Logical 4                DATA

Logical 5                SYSTEM

Logical 6                CACHE

Logical 7                Device

Logical 8                Misc

 

For those too young to remember, the above references to Primary and Extended partitions go all the way back to Microsoft MS-DOS where you could have a maximum of either four Primary partitions on a (usually hard) disk drive or three Primary partitions and one Extended partition which could be populated with one or more Logical partitions. The procedure above just generates a sequence of Type 0x083 GNU/Linux partitions.

 

 

ENABLE 7-INCH LCD DISPLAY

 

The LCD8000-70T 7-inch LCD can be used with the resulting build by using almost all of the U-boot boot arguments specified in the LCD8000-70T Quick Start Guide:

 

Press a key when the “Hit any key to stop autoboot:” message appears, and use the following commands:

 

MX6Solo RIoTboardU-Boot >setenv bootargs console=ttymxc1,115200 init=/init nosmp video=mxcfb0:dev=lcd,7inch_LCD,if=RGB565 video=mxcfb1:off fbmem=10M vmalloc=400M androidboot.console=ttymxc1 androidboot.hardware=freescale
MX6Solo RIoTboardU-Boot >saveenv

 

Note that the setenv command does not have the “calibration” argument suggested by the Quick Start Guide. If the “calibration” argument is present, the calibration screen will appear, but the touchscreen does not respond, and the boot process will hang.

 

Reboot the RIoTboard, and you should see the LCD in action. While the LCD works, the touchscreen does not.

 

CONCLUSION

 

As with Android KitKat, openSUSE 13.2 x86_64 can be used to build Android Jelly Bean 4.3 for RIoTboard.  Hopefully, the GitHub reversion workaround will allow folks to again build Jelly Bean on all hosts.

This post documents a recent build of Android 4.4.2 KitKat on a fresh installation of openSUSE 13.2 x86_64 using the Element14-provided source code for RIoTboard. The build images were transferred to an SD card using Linux commands rather than using the MFGTool.

 

 

HARDWARE AND BUILD OS

 

Gateway NE56R12u Laptop running openSUSE 13.2 x86_64 DVD

     2.1 GHz Intel B950 dual-core Pentium processor

     8 GB physical RAM

     135 GB /home partition for build

     60 Mbs Internet connection

 

 

RESOURCES

 

RIoTboard User Manual Version 2.1 (RioTboard-User-Manual-V2.1.pdf)

Freescale Semiconductor Android User's Guide, Document Number : AUG, Rev. kk4.4.2_1.0.0-ga, 07/2014 (Android-Users-Guide.pdf)

https://source.android.com/source/initializing.html

Building Android from Source

Recompiling Android for use with Parallel RGB TFT LCD and Capacitive Touch Panel

RIoTboard - Android KitKat Build on Ubuntu 12.04.5/14.04.5 LTS

 

 

UPDATE openSUSE 13.2 x86_64

 

As openSUSE 13.2 has reached end-of-life, there will be no future updates via the regular repositories. If you did not update openSUSE 13.2 during installation, then use YaST or the system tray icon to do so now.

 

 

INSTALL NECESSARY PACKAGES

 

sudo zypper install git gpg2 flex bison gperf zip curl zlib-devel gcc-c++ glibc-devel-32bit ncurses-devel-32bit xproto-devel libx11-devel zlib-devel-32bit ccache Mesa-libGL-devel libxml2-2 libxml2-tools libxslt1 libxslt-tools unzip u-boot-tools libuuid-devel lzo-devel

 

 

INSTALL MAKE

 

Make is problematic in openSUSE 13.2 since the regular repositories only provide Version 4.0, but Android compilation requires Version 3.81 or 3.82. Since openSUSE 13.1 is the most recent release with Version 3.82, I used a copy of its make RPM. Here is the file source I used:

 

ftp://195.220.108.108/linux/opensuse/distribution/13.1/repo/oss/suse/x86_64/make-3.82-160.2.1.x86_64.rpm

 

Remove make Version 4.0 and install make 3.82:

 

sudo zypper remove make
sudo rpm -ivh make-3.82-160.2.1.x86_64.rpm

 

Once you have installed make Version 3.82, you will likely be prompted by the software updater in the system tray to update, so resist the urge to do so.

 

 

INSTALL JAVA 6 JDK

 

I had a copy of the Oracle Java 6 Update 43 JDK RPM tucked away in my archive, so I used it as the Java JDK. The “Recompiling Android” post above has a link to the more recent Oracle Java 6 Update 45 JDK RPM (remember to use the x64 version):

 

Java Archive Downloads - Java SE 6

 

Execute the .bin file to install the JDK:

 

mkdir ~/jtemp
mv jdk-6u43-linux-x64-rpm.bin ~/jtemp/
cd ~/jtemp
sudo chmod a+x jdk-6u43-linux-x64-rpm.bin
sudo ./jdk-6u43-linux-x64-rpm.bin

 

Log out and log back in.

 

As noted above, this procedure assumes a clean installation of openSUSE.  If your installation is not "fresh," then you may need some additional configuration.  The following page has information on Java configuration for recent openSUSE releases, including Version 13.2:

 

https://en.opensuse.org/SDB:Installing_Java

 

If you have a notion to install OpenJDK instead of Oracle Java JDK, you will be obliged to get packages from an outside repository as openSUSE 13.2 only provides packages for OpenJDK 1.7 and OpenJDK 1.8. An OpenJDK Version 1.6 RPM release for openSUSE 12.1 x86_64 does exist, and it may or may not be adequate (it's quite old):

 

https://www.rpmfind.net/linux/RPM/opensuse/12.1/x86_64/java-1_6_0-openjdk-devel-1.6.0.0_b22.1.10.4-1.2.x86_64.html

 

Android build scripts expect Oracle Java JDK, so using OpenJDK will require script modifications. See the Building Android from Source link above for more information.

 

 

UNPACK ANDROID SOURCE CODE

 

Copy the android-imx6-kk4.4.2-1.0.0-svn2705-20140818.tar.bz2 source code file to the home directory and decompress it:

 

cd ~
tar -xvf android-imx6-kk4.4.2-1.0.0-svn2705-20140818.tar.bz2

 

 

SELECT SD CARD OR EMMC BUILD

 

Open android-imx6-kk4.4.2-1.0.0/device/fsl/RIoTboard_6solo/BoardConfig.mk in your favorite editor and change

 

BUILD_TARGET_LOCATION ?= emmc

 

to

 

BUILD_TARGET_LOCATION ?= sdmmc

 

since we want to create an SD card image. Save the file.

 

 

BUILD ANDROID

 

cd ~/android-imx6-kk4.4.2-1.0.0
source build/envsetup.sh
lunch (Select RIoTboard_6solo-user)
make clean
time make -j4

 

The -j4 parameter in the make command is important as this reduced build times on my dual core laptop from around 7 hours to 3.75 hours. At the very least, you want as many jobs as you have CPU cores (-j2 in my case), but in my tests, increasing beyond that yields only marginal improvement.

 

 

CREATE A BOOTABLE SD CARD

 

The resulting image files to create an SD card for booting RIoTboard are located in ~/android-imx6-kk4.4.2-1.0.0/out/target/product/RIoTboard_6solo/:

 

boot.img

recovery.img

system.img

u-boot.bin

 

Per the Freescale Semiconductor Android User's Guide, a Linux script to generate the necessary partitions on a blank SD card to boot Android is located in ~/android-imx6-kk4.4.2-1.0.0/device/fsl/common/tools/fsl-sdcard-partition.sh.

 

Determine the device designation for the SD card in your system. You can use the lsblk command to do this by executing the command first without the SD card inserted, and then again with the SD card inserted.:

 

stmorgan@GATEWAY:~$ lsblk

NAME MAJ:MIN RM SIZE   RO TYPE MOUNTPOINT

sda    8:0   0  465.8G 0  disk 

sda1   8:1   0  100M   0  part 

sda2   8:2   0  288G   0  part 

sda3   8:3   0  1K     0  part 

sda5   8:5   0  169.8G 0  part /

sda6   8:6   0  7.9G   0  part [SWAP]

sr0   11:0   1  1024M  0  rom  


stmorgan@GATEWAY:~$ lsblk

NAME MAJ:MIN RM SIZE   RO TYPE MOUNTPOINT

sda    8:0   0  465.8G 0  disk 

sda1   8:1   0  100M   0  part 

sda2   8:2   0  288G   0  part 

sda3   8:3   0  1K     0  part 

sda5   8:5   0  169.8G 0  part /

sda6   8:6   0  7.9G   0  part [SWAP]

sdd    8:48  1  29.8G  0  disk

sdd1   8:49  1  29.8G  0  part /media/9016-4EF8

sr0   11:0   1  1024M  0  rom  

 

So I would use /dev/sdd for the SD card on my system. Note that this is not an empty SD card, as indicated by the presence of the mounted sdd1 partition.

 

In the following discussion, /dev/sdX will be used for the SD card, BUT YOU MUST REMEMBER TO CHANGE THE DEVICE DESIGNATION TO MATCH YOUR CARD IN ALL COMMANDS THAT FOLLOW.

 

Use your favorite method to remove all partitions from your SD card. If the partitioning tool used to remove partitions asks whether to use an MS-DOS or GPT scheme, use MS-DOS.

 

Execute the following commands after an SD card with no partitions has been inserted into the system:

 

cd ~/android-imx6-kk4.4.2-1.0.0/device/fsl/common/tools
sudo ./fsl-sdcard-partition.sh /dev/sdX

 

Eject the SD card from the system and reinsert it. This is a necessary step on my Gateway laptop, otherwise the following commands will not generate a usable image, although they give the outward appearance of doing what they are supposed to do.

 

cd ~/android-imx6-kk4.4.2-1.0.0/out/target/product/RIoTboard_6solo
sudo dd if=u-boot.bin of=/dev/sdX bs=1K skip=1 seek=1; sync
sudo dd if=boot.img of=/dev/sdX1; sync
sudo dd if=system.img of=/dev/sdX5; sync
sudo dd if=recovery.img of=/dev/sdX2; sync

 

The SD card can now be used to boot Android on the RIoTboard.

 

It's worth mentioning that there is a difference between the partition organization yielded by the above procedure versus that used in the Element14 pre-built SD card image. The Element14 image uses a partitioning scheme identical to that described in the Freescale Semiconductor Android User's Manual (presumably a byproduct of using MFGTool in a Windows environment), so the partitions are physically ordered as follows:

 

PARTITION TYPE/INDEX     NAME

N/A                      U-Boot Loader

Primary 1                Boot

Primary 2                Recovery

Logical 5 (Extended 3)   SYSTEM

Logical 6 (Extended 3)   CACHE

Logical 7 (Extended 3)   Device

Logical 8 (Extended 3)   Misc

Primary 4                DATA

 

The procedure used above reverses the Extended 3 and Primary 4 partitions, so the resulting physical order is as follows:

 

PARTITION TYPE/INDEX     NAME

N/A                      U-Boot Loader

Logical 1                Boot

Logical 2                Recovery

Logical 3                (small stub)

Logical 4                DATA

Logical 5                SYSTEM

Logical 6                CACHE

Logical 7                Device

Logical 8                Misc

 

For those too young to remember, the above references to Primary and Extended partitions go all the way back to Microsoft MS-DOS where you could have a maximum of either four Primary partitions on a (usually hard) disk drive or three Primary partitions and one Extended partition which could be populated with one or more Logical partitions. The procedure above just generates a sequence of Type 0x083 GNU/Linux partitions.

 

 

ENABLE 7-INCH LCD DISPLAY

 

The LCD8000-70T 7-inch LCD can be used with the resulting build by using the U-boot boot arguments specified in the LCD8000-70T Quick Start Guide.  NOTE:  You must have a connection to the J18 Serial Debug Port during boot in order to execute the following commands.

 

Reboot the RIoTboard, press a key when the “Hit any key to stop autoboot:” message appears and use the following commands:

 

MX6Solo RIoTboard U-Boot >setenv bootargs console=ttymxc1,115200 init=/init nosmp video=mxcfb0:dev=lcd,7inch_LCD,if=RGB565 video=mxcfb1:off fbmem=10M vmalloc=400M androidboot.console=ttymxc1 androidboot.hardware=freescale calibration
MX6Solo RIoTboard U-Boot >saveenv

 

Reboot the RIoTboard, and you should see the LCD in action. While the LCD works, the touchscreen does not.

 

 

CONCLUSION

 

Although build times are slightly longer than with Ubuntu, openSUSE 13.2 x86_64 can also be used to build Android KitKat on RIoTboard.  Thanks again to others who have made their build procedures available.

This post documents a recent build of Android 4.4.2 KitKat on Ubuntu 12.04.5 LTS x86_64 Desktop using the Element14-provided source code for RIoTboard. The build images were transferred to an SD card using Linux commands rather than using the MFGTool.  Ubuntu 14.04.5 LTS x86_64 Desktop users should see the Addendum at the bottom of the post for additional information.

 

HARDWARE AND BUILD OS

 

Gateway NE56R12u Laptop running Ubuntu 12.04.5 LTS x86_64 Desktop

     2.1 GHz Intel B950 dual-core Pentium processor

     8 GB physical RAM

     135 GB /home partition for build

     60 Mbs Internet connection

 

RESOURCES

 

RIoTboard User Manual Version 2.1 (RioTboard-User-Manual-V2.1.pdf)

Freescale Semiconductor Android User's Guide, Document Number : AUG, Rev. kk4.4.2_1.0.0-ga, 07/2014 (Android-Users-Guide.pdf)

https://source.android.com/source/initializing.html

Building Android from Source

Recompiling Android for use with Parallel RGB TFT LCD and Capacitive Touch Panel

Android, setting up a Linux build environment, libgl1-mesa-glx:i386 package have unmet dependencies - Stack Overflow

 

UPDATE UBUNTU

 

sudo apt-get update
sudo apt-get upgrade

(reboot)

sudo apt-get dist-upgrade

(reboot)

 

INSTALL NECESSARY PACKAGES

 

Note that non-development Mesa packages (namely, libgl1-mesa-glx:i386 and libglapi-mesa:i386) are NOT used in the following command. This is due to the fact that attempting to install these packages triggered the removal of more than three dozen 64-bit Mesa packages, and this in turn caused the boot sequence to hang due to graphics issues. Pay attention to what packages are proposed for removal when you install necessary packages, and if you see large numbers of 64-bit graphics libraries being sacrificed for the sake of dependencies, then you are probably doing something wrong.

 

 sudo apt-get install ia32-libs-multiarch git gnupg flex bison gperf build-essential zip curl libc6-dev x11proto-core-dev lib32ncurses5-dev libx11-dev:i386 lib32readline6-dev libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386 ia32-libs u-boot-tools minicom libncurses5-dev lib32z1-dev uuid-dev liblzo2-dev

 

UNPACK ANDROID SOURCE CODE

 

Copy the android-imx6-kk4.4.2-1.0.0-svn2705-20140818.tar.bz2 source code file to the home directory and decompress it:

 

cd ~
tar -xvf android-imx6-kk4.4.2-1.0.0-svn2705-20140818.tar.bz2

 

INSTALL JAVA 6 JDK

 

I had a copy of the Oracle Java 6 Update 43 JDK tucked away in my archive, so I used it as the Java JDK. OpenJDK can also be used, but changes to build scripts will be necessary as noted in the “Building Android from Source” post above. The “Recompiling Android” post above has a link to the more recent Oracle Java 6 Update 45 JDK if you prefer.

 

sudo mkdir /usr/lib/jvm
sudo chmod a+x jdk-6u43-linux-x64.bin
sudo ./jdk-6u43-linux-x64.bin
sudo mv jdk1.6.0_43 /usr/lib/jvm

 

sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.6.0_43/bin/java 1
sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.6.0_43/bin/javac 1
sudo update-alternatives --install /usr/bin/javaws javaws /usr/lib/jvm/jdk1.6.0_43/bin/javaws 1

 

sudo update-alternatives --config java
sudo update-alternatives --config javac
sudo update-alternatives --config javaws
export PATH=$PATH:/usr/lib/jvm/jdk1.6.0_43/bin

 

SELECT SD CARD OR EMMC BUILD

 

Open android-imx6-kk4.4.2-1.0.0/device/fsl/RIoTboard_6solo/BoardConfig.mk in your favorite editor and change

 

BUILD_TARGET_LOCATION ?= emmc

 

to

 

BUILD_TARGET_LOCATION ?= sdmmc

 

since we want to create an SD card image. Save the file.

 

BUILD ANDROID

 

cd ~/android-imx6-kk4.4.2-1.0.0
source build/envsetup.sh
lunch (Select RIoTboard_6solo-user)
make clean
time make -j4

 

The -j4 parameter in the make command is important as this reduced build times on my dual core laptop from around 7 hours to a little over 3 ½ hours. At the very least, you want as many jobs as you have CPU cores (-j2 in my case), but in my tests, increasing beyond that yields only marginal improvement.

 

CREATE A BOOTABLE SD CARD

 

The resulting image files to create an SD card for booting RIoTboard are located in ~/android-imx6-kk4.4.2-1.0.0/out/target/product/RIoTboard_6solo/:

 

boot.img

recovery.img

system.img

u-boot.bin

 

Per the Freescale Semiconductor Android User's Guide, a Linux script to generate the necessary partitions on a blank SD card to boot Android is located in ~/android-imx6-kk4.4.2-1.0.0/device/fsl/common/tools/fsl-sdcard-partition.sh.

 

Determine the device designation for the SD card in your system. You can use the lsblk command to do this by executing the command first without the SD card inserted, and then again with the SD card inserted.:

 

stmorgan@GATEWAY:~$ lsblk

NAME MAJ:MIN RM SIZE   RO TYPE MOUNTPOINT

sda    8:0   0  465.8G 0  disk 

sda1   8:1   0  100M   0  part 

sda2   8:2   0  288G   0  part 

sda3   8:3   0  1K     0  part 

sda5   8:5   0  169.8G 0  part /

sda6   8:6   0  7.9G   0  part [SWAP]

sr0   11:0   1  1024M  0  rom  


stmorgan@GATEWAY:~$ lsblk

NAME MAJ:MIN RM SIZE   RO TYPE MOUNTPOINT

sda    8:0   0  465.8G 0  disk 

sda1   8:1   0  100M   0  part 

sda2   8:2   0  288G   0  part 

sda3   8:3   0  1K     0  part 

sda5   8:5   0  169.8G 0  part /

sda6   8:6   0  7.9G   0  part [SWAP]

sdd    8:48  1  29.8G  0  disk

sdd1   8:49  1  29.8G  0  part /media/9016-4EF8

sr0   11:0   1  1024M  0  rom  

 

So I would use /dev/sdd for the SD card on my system. Note that this is not an empty SD card, as indicated by the presence of the mounted sdd1 partition.

 

In the following discussion, /dev/sdX will be used for the SD card, BUT YOU MUST REMEMBER TO CHANGE THE DEVICE DESIGNATION TO MATCH YOUR CARD IN ALL COMMANDS THAT FOLLOW.

 

Use your favorite method to remove all partitions from your SD card. If the partitioning tool used to remove partitions asks whether to use an MS-DOS or GPT scheme, use MS-DOS.

 

Execute the following commands after an SD card with no partitions has been inserted into the system:

 

cd ~/android-imx6-kk4.4.2-1.0.0/device/fsl/common/tools
sudo ./fsl-sdcard-partition.sh /dev/sdX

 

Eject the SD card from the system and reinsert it. This is a necessary step on my Gateway laptop, otherwise the following commands will not generate a usable image, although they give the outward appearance of doing what they are supposed to do.

 

cd ~/android-imx6-kk4.4.2-1.0.0/out/target/product/RIoTboard_6solo
sudo dd if=u-boot.bin of=/dev/sdX bs=1K skip=1 seek=1; sync
sudo dd if=boot.img of=/dev/sdX1; sync
sudo dd if=system.img of=/dev/sdX5; sync
sudo dd if=recovery.img of=/dev/sdX2; sync

 

The SD card can now be used to boot Android on the RIoTboard.

 

It's worth mentioning that there is a difference between the partition organization yielded by the above procedure versus that used in the Element14 pre-built SD card image. The Element14 image uses a partitioning scheme identical to that described in the Freescale Semiconductor Android User's Manual (presumably a byproduct of using MFGTool in a Windows environment), so the partitions are physically ordered as follows:

 

PARTITION TYPE/INDEX     NAME

N/A                      U-Boot Loader

Primary 1                Boot

Primary 2                Recovery

Logical 5 (Extended 3)   SYSTEM

Logical 6 (Extended 3)   CACHE

Logical 7 (Extended 3)   Device

Logical 8 (Extended 3)   Misc

Primary 4                DATA

 

The procedure used above reverses the Extended 3 and Primary 4 partitions, so the resulting physical order is as follows:

 

PARTITION TYPE/INDEX     NAME

N/A                      U-Boot Loader

Logical 1                Boot

Logical 2                Recovery

Logical 3                (small stub)

Logical 4                DATA

Logical 5                SYSTEM

Logical 6                CACHE

Logical 7                Device

Logical 8                Misc

 

For those too young to remember, the above references to Primary and Extended partitions go all the way back to Microsoft MS-DOS where you could have a maximum of either four Primary partitions on a (usually hard) disk drive or three Primary partitions and one Extended partition which could be populated with one or more Logical partitions. The procedure above just generates a sequence of Type 0x083 GNU/Linux partitions.

 

ENABLE 7-INCH LCD DISPLAY

 

The LCD8000-70T 7-inch LCD can be used with the resulting build by using the U-boot boot arguments specified in the LCD8000-70T Quick Start Guide.  NOTE:  You must have a connection to the J18 Serial Debug Port during boot in order to execute the following commands.

 

Reboot the RIoTboard, press a key when the “Hit any key to stop autoboot:” message appears and use the following commands:

 

MX6Solo RIoTboard U-Boot >setenv bootargs console=ttymxc1,115200 init=/init nosmp video=mxcfb0:dev=lcd,7inch_LCD,if=RGB565 video=mxcfb1:off fbmem=10M vmalloc=400M androidboot.console=ttymxc1 androidboot.hardware=freescale calibration
MX6Solo RIoTboard U-Boot >saveenv

 

Reboot the RIoTboard, and you should see the LCD in action. While the LCD works, the touchscreen does not.

 

CONCLUSION

 

Hopefully, this procedure will be of use to someone who is unable to use the MFGTool due to a lack of access to a Windows machine.  Thanks to those who have taken the time to post their procedures and approaches to issues when trying to build Android for RIoTboard.

 

ADDENDUM

 

The procedure for Ubuntu 14.04.5 LTS x86_64 Desktop is identical except for the Install Necessary Packages section.  Replace this section with the following:

 

INSTALL NECESSARY PACKAGES

 

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip u-boot-tools uuid-dev liblzo2-dev python-markdown

In this small guide I will demonstrate how to integrate Riotboard with Ultrasonic sensor HC-SR04 .

 

HCSR04.jpg

 

Step1:

 

export ARCH & CROSS_COMPILE to environment path.

 

in my case its like below, yours might be different.

$ export ARCH=arm

$ export CROSS_COMPILE=<PATH_TO_TOOLCHAIN>/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi-

 

Step2:

create a directory

$ mkdir driver

 

create a file named "Makefile"  and replace with your KDIR value, below is mine.

 

obj-m := sr04.o

KDIR := /home/tushar/riot_github/kernel_out/lib/modules/3.0.35-02887-g731b440/build

PWD := $(shell pwd)

 

all:

  $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:

  $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean

 

next we will create the driver for sr04 module, create file "sr04.c" with below contents in it.

 

#include <linux/init.h>
#include <linux/module.h>
#include <linux/gpio.h>
#include <linux/delay.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/hrtimer.h>
#include <linux/ktime.h>
#include <linux/device.h>
#include <linux/kdev_t.h>
#include <linux/interrupt.h> 


MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("HC-SR04 ultrasonic sensor");


#define HCSR04_ECHO 113 
#define HCSR04_TRIGGER 112

static int gpio_irq=-1;
static int valid_value = 0;


static ktime_t echo_start;
static ktime_t echo_end;

// write to "/sys/class/hcsr04/value"
static ssize_t hcsr04_value_write(struct class *class, struct class_attribute *attr, const char *buf, size_t len) 
{
  printk(KERN_INFO "Buffer len %d bytes\n", len);
  return len;
}


// read from "/sys/class/hcsr04/value"
static ssize_t hcsr04_value_read(struct class *class, struct class_attribute *attr, char *buf) 
{
  int counter;
  gpio_set_value(HCSR04_TRIGGER,1);
  udelay(10);
  gpio_set_value(HCSR04_TRIGGER,0);
  valid_value=0;
  counter=0;
  while (valid_value==0) {
  if (++counter>23200) {
  return sprintf(buf, "%d\n", -1);;
  }
  udelay(1);
  }
  return sprintf(buf, "%lld\n", ktime_to_us(ktime_sub(echo_end,echo_start)));;
}


// Sysfs definitions for hcsr04 class
static struct class_attribute hcsr04_class_attrs[] = {
  __ATTR(value, S_IRUGO | S_IWUSR, hcsr04_value_read, hcsr04_value_write),
  __ATTR_NULL,
};


// Name of directory created in /sys/class
static struct class hcsr04_class = {
  .name = "hcsr04",
  .owner = THIS_MODULE,
  .class_attrs = hcsr04_class_attrs,
};


// Interrupt handler on ECHO signal
static irqreturn_t gpio_isr(int irq, void *data)
{
  ktime_t ktime_dummy;
  if (valid_value==0) {
  ktime_dummy=ktime_get();
  if (gpio_get_value(HCSR04_ECHO)==1) {
  echo_start=ktime_dummy;
  } else {
  echo_end=ktime_dummy;
  valid_value=1;
  }
  }
  return IRQ_HANDLED;
}


static int hcsr04_init(void)
{
  int rtc;

  printk(KERN_INFO "HC-SR04 driver init...\n");


  if (class_register(&hcsr04_class)<0) goto fail;


  rtc=gpio_request(HCSR04_TRIGGER,"TRIGGER");
  if (rtc!=0) {
  printk(KERN_INFO "Error %d\n",__LINE__);
  goto fail;
  }


  rtc=gpio_request(HCSR04_ECHO,"ECHO");
  if (rtc!=0) {
  printk(KERN_INFO "Error %d\n",__LINE__);
  goto fail;
  }


  rtc=gpio_direction_output(HCSR04_TRIGGER,0);
  if (rtc!=0) {
  printk(KERN_INFO "Error %d\n",__LINE__);
  goto fail;
  }


  rtc=gpio_direction_input(HCSR04_ECHO);
  if (rtc!=0) {
  printk(KERN_INFO "Error %d\n",__LINE__);
  goto fail;
  }


  rtc=gpio_to_irq(HCSR04_ECHO);
  if (rtc<0) {
  printk(KERN_INFO "Error %d\n",__LINE__);
  goto fail;
  } else {
  gpio_irq=rtc;
  }


  rtc = request_irq(gpio_irq, gpio_isr, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_DISABLED , "hc-sr04.trigger", NULL);


  if(rtc) {
  printk(KERN_ERR "Unable to request IRQ: %d\n", rtc);
  goto fail;
  }




  return 0;


fail:
  return -1;


}

static void hcsr04_exit(void)
{
  if (gpio_irq!=-1) {
  free_irq(gpio_irq, NULL);
  }
  gpio_free(HCSR04_TRIGGER);
  gpio_free(HCSR04_ECHO);
  class_unregister(&hcsr04_class);
  printk(KERN_INFO "HC-SR04 disabled.\n");
}

module_init(hcsr04_init);
module_exit(hcsr04_exit);

 

 

Now hit "make" command to compile the above driver.

 

Step3:

 

connect the Vcc    pin in hc-sr04 to Pin2 in J13.

connect the Trig   pin in hc-sr04 to Pin5 in J13.

connect the Echo  pin in hc-sr04 to Pin6 in J13.

connect the Gnd   pin in hc-sr04 to Pin4 in J13.

 

Now copy the compiled sr04.ko to  /opt/ in riotboard.

 

Next insert the compiled module using insmod:

insmod sr04.ko

 

Now configure the Trigger & Echo for gpio in Riotboard terminal:

devmem 0x20E009C w 0x5

devmem 0x20E00A0 w 0x5

 

Prepare sr04 for capturing values:

 

Export the gpio pins

echo 112 > /sys/class/gpio/export

echo 113 > /sys/class/gpio/export

 

Set the Direction

echo out > /sys/class/gpio/gpio112/direction

echo 1 > /sys/class/gpio/gpio112/value

 

 

To view the sonar values , hit below command

cat /sys/class/hcsr04/value

 

Step4:

To continuously view values & object distance in cm i wrote a small python script.

create a file "sr04_distance.py"  in riotboard terminal with below contents:

 

#!/usr/bin/python
f = open("/sys/class/hcsr04/value",'r')
d=f.read()
f.close()
if (long(d)==-1):
  print "N.A."
else:
  print "%.1f cm" % (float(d)/58)

 

 

With all connections ready, run the sr04_distance.py script:

$ python sr04_distance.py

 

The sonar will display values as objects encountered in its way .

 

 

Note: during module testing if found  this hc-sr04 module range is max 3 metres.

 

 

That's all.

 

Thanks

Tushar

Hi, I know that the RiotBoard provides 3,3V on the pin header and also should provide 3,3V over the LVDS connector. What is the maximal current availible ? I would like to connect older LCD fomr a laptop and would like to know if I need extra power supply for feeding the electronics. The 3,3V current will be limited by the power regulator but I do not know which one is used by the riotboard.

In this guide we will be controlling a tower pro sg90 servo motor using software pwm module.

 

2vj8z8z.jpg

 

Step1:

export ARCH & CROSS_COMPILE to environment path.

 

in my case its like below, yours might be different.

$ export ARCH=arm

$ export CROSS_COMPILE=<PATH_TO_TOOLCHAIN>/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi-

 

Step2:

create a directory

mkdir driver

 

create a file named "Makefile"  and replace with your KDIR value, below is mine.

obj-m := soft_pwm.o

KDIR := /home/tushar/riot_github/kernel_out/lib/modules/3.0.35-02887-g731b440/build

PWD := $(shell pwd)

 

all:

  $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:

  $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean

 

create a file named "soft_pwm.c"  with below contents in it.

 

// Generic software-pwm  driver

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/hrtimer.h>
#include <linux/ktime.h>
#include <linux/device.h>
#include <linux/kdev_t.h>
#include <linux/gpio.h>


MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Driver for kernel-generated PWM signals");


static struct hrtimer hr_timer;


/* pwm_desc
 *
 * This structure maintains the information regarding a
 * single PWM signal: its wave period and pulse length
 * are user-definable via sysfs. The counter is also
 * shown in sysfs as a debug helper.
*/
struct pwm_desc {
  unsigned int pulse;    // pulse width, in microseconds
  unsigned int period;   // wave period, in microseconds 
  unsigned int pulses;   // number of pwm pulses before stopping; -1 never stops, 0 stops immediately
  unsigned long counter; // "interrupt" counter - counts each value toggle
  int value;             // current GPIO pin value (0 or 1 only)
  ktime_t next_tick;     // timer tick at which next toggling should happen
  unsigned long flags;   // only FLAG_SOFTPWM is used, for synchronizing inside module
#define FLAG_SOFTPWM 0
};


/* pwm_table
 *
 * The table will hold a description for any GPIO pin available
 * on the system. It's wasteful to preallocate the entire table,
 * but avoiding race conditions is so much easier this way ;-)
*/
static struct pwm_desc pwm_table[ARCH_NR_GPIOS];


/* lock protects against pwm_unexport() being called while
 * sysfs files are active.
 */
static DEFINE_MUTEX(sysfs_lock);


int pwm_export(unsigned gpio);   // forward definition
int pwm_unexport(unsigned gpio); // forward definition


/* Show attribute values for PWMs */
static ssize_t pwm_show(struct device *dev, struct device_attribute *attr, char *buf){
  const struct pwm_desc *desc = dev_get_drvdata(dev);
  ssize_t status;
  mutex_lock(&sysfs_lock);
  if(!test_bit(FLAG_SOFTPWM, &desc->flags)){
    status = -EIO;
  }else{
    if(strcmp(attr->attr.name, "pulse")==0){
      status = sprintf(buf, "%d usec\n", desc->pulse);
    }else if(strcmp(attr->attr.name, "period")==0){
      status = sprintf(buf, "%d usec\n", desc->period);
    }else if(strcmp(attr->attr.name, "pulses")==0){
      status = sprintf(buf, "%d usec\n", desc->pulses);
    }else if(strcmp(attr->attr.name, "counter")==0){
      status = sprintf(buf, "%lu\n", desc->counter);
    }else{
      status = -EIO;
    }
  }
  mutex_unlock(&sysfs_lock);
  return status;
}


/* Store attribute values for PWMs */
static ssize_t pwm_store(
  struct device *dev, struct device_attribute *attr, const char *buf, size_t size
){
  struct pwm_desc *desc = dev_get_drvdata(dev);
  ssize_t status;
  mutex_lock(&sysfs_lock);
  if(!test_bit(FLAG_SOFTPWM, &desc->flags)){
    status = -EIO;
  }else{
    unsigned long value;
    status = strict_strtoul(buf, 0, &value);
    if(status==0){
      if(strcmp(attr->attr.name, "pulse")==0){
        if(value<=desc->period){ desc->pulse = (unsigned int)value; }
      }else if(strcmp(attr->attr.name, "period")==0){
        desc->period = (unsigned int)value;
      }else if(strcmp(attr->attr.name, "pulses")==0){
       if (value>0)
         desc->pulses = (unsigned int)value*2;
       else 
        desc->pulses = (unsigned int)value;
      }
      desc->next_tick = ktime_get();
      //printk(KERN_INFO "Starting timer (%s).\n", attr->attr.name);
      hrtimer_start(&hr_timer, ktime_set(0,1), HRTIMER_MODE_REL);
    }
  }
  mutex_unlock(&sysfs_lock);
  return status ? : size;
}


/* Sysfs attributes definition for PWMs */
static DEVICE_ATTR(pulse,   0644, pwm_show, pwm_store);
static DEVICE_ATTR(period,  0644, pwm_show, pwm_store);
static DEVICE_ATTR(pulses,  0644, pwm_show, pwm_store);
static DEVICE_ATTR(counter, 0444, pwm_show, NULL);
static const struct attribute *soft_pwm_dev_attrs[] = {
  &dev_attr_pulse.attr,
  &dev_attr_period.attr,
  &dev_attr_pulses.attr,
  &dev_attr_counter.attr,
  NULL,
};
static const struct attribute_group soft_pwm_dev_attr_group = {
  .attrs = (struct attribute **) soft_pwm_dev_attrs,
};


/* Export a GPIO pin to sysfs, and claim it for PWM usage.
 * See the equivalent function in drivers/gpio/gpiolib.c
 */
static ssize_t export_store(struct class *class, struct class_attribute *attr, const char *buf, size_t len){
  long gpio;
  int  status;


  status = strict_strtol(buf, 0, &gpio);
  if(status<0){ goto done; }


  status = gpio_request(gpio, "soft_pwm");
  if(status<0){ goto done; }


  status = gpio_direction_output(gpio,0);
  if(status<0){ goto done; }
  
  status = pwm_export(gpio);
  if(status<0){ goto done; }


  set_bit(FLAG_SOFTPWM, &pwm_table[gpio].flags);


done:
  if(status){
    gpio_free(gpio);
    pr_debug("%s: status %d\n", __func__, status);
  }
  return status ? : len;
}


/* Unexport a PWM GPIO pin from sysfs, and unreclaim it.
 * See the equivalent function in drivers/gpio/gpiolib.c
 */
static ssize_t unexport_store(struct class *class, struct class_attribute *attr, const char *buf, size_t len){
  long gpio;
  int  status;


  status = strict_strtol(buf, 0, &gpio);
  if(status<0){ goto done; }


  status = -EINVAL;
  if(!gpio_is_valid(gpio)){ goto done; }


  if(test_and_clear_bit(FLAG_SOFTPWM, &pwm_table[gpio].flags)){
    status = pwm_unexport(gpio);
    if(status==0){ gpio_free(gpio); }
  }
done:
  if(status){ pr_debug("%s: status %d\n", __func__, status); }
  return status ? : len;
}


/* Sysfs definitions for soft_pwm class */
static struct class_attribute soft_pwm_class_attrs[] = {
   __ATTR(export,   0200, NULL, export_store),
   __ATTR(unexport, 0200, NULL, unexport_store),
   __ATTR_NULL,
};
static struct class soft_pwm_class = {
  .name =        "soft_pwm",
  .owner =       THIS_MODULE,
  .class_attrs = soft_pwm_class_attrs,
};


/* Setup the sysfs directory for a claimed PWM device */
int pwm_export(unsigned gpio){
  struct pwm_desc *desc;
  struct device   *dev;
  int             status;


  mutex_lock(&sysfs_lock);


  desc = &pwm_table[gpio];
  desc->value  = 0;
  desc->pulses = -1;
  dev = device_create(&soft_pwm_class, NULL, MKDEV(0, 0), desc, "pwm%d", gpio);
  if(dev){
    status = sysfs_create_group(&dev->kobj, &soft_pwm_dev_attr_group);
    if(status==0){
      printk(KERN_INFO "Registered device pwm%d\n", gpio);
    }else{
      device_unregister(dev);
    }
  }else{
    status = -ENODEV;
  }


  mutex_unlock(&sysfs_lock);


  if(status){ pr_debug("%s: pwm%d status %d\n", __func__, gpio, status); }
  return status;
}


/* Used by pwm_unexport below to find the device which should be freed */
static int match_export(struct device *dev, void *data){
  return dev_get_drvdata(dev) == data;
}


/* Free a claimed PWM device and unregister the sysfs directory */
int pwm_unexport(unsigned gpio){
  struct pwm_desc *desc;
  struct device   *dev;
  int             status;
      
  mutex_lock(&sysfs_lock);


  desc = &pwm_table[gpio];
  dev  = class_find_device(&soft_pwm_class, NULL, desc, match_export);
  if(dev){
    put_device(dev);
    device_unregister(dev);
    printk(KERN_INFO "Unregistered device pwm%d\n", gpio);
    status = 0;
  }else{
    status = -ENODEV;
  }


  mutex_unlock(&sysfs_lock);


  if(status){ pr_debug("%s: pwm%d status %d\n", __func__, gpio, status); }
  return status;
}


/* The timer callback is called only when needed (which is to
 * say, at the earliest PWM signal toggling time) in order to
 * maintain the pressure on system latency as low as possible
 */
enum hrtimer_restart soft_pwm_hrtimer_callback(struct hrtimer *timer){
  unsigned gpio;
  struct pwm_desc *desc;
  ktime_t now = ktime_get();
  ktime_t next_tick = ktime_set(0,0);


  now = ktime_get();
  for(gpio=0;gpio<ARCH_NR_GPIOS;gpio++){
    desc = &pwm_table[gpio];
    if(
      test_bit(FLAG_SOFTPWM,&desc->flags) &&
      (desc->period>0) &&
      (desc->pulse<=desc->period) &&
      (desc->pulses!=0)
    ){
      if(desc->next_tick.tv64<=now.tv64){
        desc->value = 1-desc->value;
        __gpio_set_value(gpio,desc->value);
        desc->counter++;
        if(desc->pulses>0){ desc->pulses--; }
        if((desc->pulse==0)||(desc->pulse==desc->period)||(desc->pulses==0)){
          desc->next_tick.tv64 = KTIME_MAX;
        }else{
          desc->next_tick=ktime_add_ns(
            desc->next_tick,
            (desc->value? desc->pulse : desc->period-desc->pulse)*1000
          );
        }
      }
      if((next_tick.tv64==0)||(desc->next_tick.tv64<next_tick.tv64)){
        next_tick.tv64 = desc->next_tick.tv64;
      }
    }
  }
  if(next_tick.tv64>0){
    hrtimer_start(&hr_timer, next_tick, HRTIMER_MODE_ABS);
  }else{
    //printk(KERN_INFO "Stopping timer.\n");
  }
  return HRTIMER_NORESTART;
}


/* module initialization: init the hr-timer and register a driver class */
static int __init soft_pwm_init(void){
  struct timespec tp;


  int status;
  printk(KERN_INFO "SoftPWM v0.2-acme initializing.\n");


  hrtimer_get_res(CLOCK_MONOTONIC, &tp);
  printk(KERN_INFO "Clock resolution is %ldns\n", tp.tv_nsec);


  hrtimer_init(&hr_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
  hr_timer.function = &soft_pwm_hrtimer_callback;


  status = class_register(&soft_pwm_class);
  if(status<0){ goto fail_no_class; }


  printk(KERN_INFO "SoftPWM initialized.\n");
  return 0;


fail_no_class:
  return status;
}


/* module finalization: cancel the hr-timer, switch off any PWM
 * signal and give back to GPIO the pin, then deregister our class
 */
static void __exit soft_pwm_exit(void){
  unsigned gpio;
  int status;


  hrtimer_cancel(&hr_timer);
  for(gpio=0;gpio<ARCH_NR_GPIOS;gpio++){
    struct pwm_desc *desc;
    desc = &pwm_table[gpio];
    if(test_bit(FLAG_SOFTPWM,&desc->flags)){
      __gpio_set_value(gpio,0);
      status = pwm_unexport(gpio);
      if(status==0){ gpio_free(gpio); }
    }
  }
  class_unregister(&soft_pwm_class);
  printk(KERN_INFO "SoftPWM disabled.\n");
}


module_init(soft_pwm_init);
module_exit(soft_pwm_exit);

 

Now hit "make" command to compile the above driver.

 

 

Step3:

connect the PWM pin (yellow) to  Pin7 in J13.

connect the PWR pin (red) to Pin2 in J13.

connect the GND pin (brown) to Pin2 in J13.

 

2egfz2e.jpg

 

156v1tw.jpg

 

Step4:

Now create and compile a file "servo_ctrl.c"  in riotboard terminal:

$ cc servo_ctrl.c -o servo_ctrl

 

servo_ctrl.c contents

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>


/*void sig_handler(int signo)*/
/*{*/
/*  if (signo == SIGINT)*/
/*    { */
/*   system("echo 0 > /sys/class/soft_pwm/pwm113/pulse");*/
/* system("cat /sys/class/soft_pwm/pwm113/pulse");*/
/* }*/
/*}*/




void main(int argc,char argv[])
{
/* if (signal(SIGINT, sig_handler) == SIG_ERR)*/
/* printf("\ncan't catch SIGINT : CTRL-C \n");*/


  system("devmem 0x20E00A0 w 0x5");
  printf("\ndevmem SET");
  sleep(1);


  system("cd /opt/soft_pwm/");
  printf("\nEntering /opt/soft_pwm/");
  sleep(1);


  system("rmmod soft_pwm.ko");
  printf("\nrmmod soft_pwm");
  sleep(1);


  system("insmod soft_pwm.ko");
  printf("\ninsmod soft_pwm");
  sleep(1);


  system("echo 113 > /sys/class/soft_pwm/export");
  printf("\nexporting gpio 113");
  sleep(1);


  system("echo 20000 > /sys/class/soft_pwm/pwm113/period");
  printf("\nsetting period: 20000");
  sleep(1);


  while(1)
  {
  system("echo 10 > /sys/class/soft_pwm/pwm113/pulse");
  printf("\nMiddle");
  sleep(1);
  system("echo 0 > /sys/class/soft_pwm/pwm113/pulse");
  sleep(0.5);


  system("echo 1200 > /sys/class/soft_pwm/pwm113/pulse");
  printf("\nRight_30degree");
  usleep(100000);


  system("echo 1600 > /sys/class/soft_pwm/pwm113/pulse");
  printf("\nLeft_30degree");
  usleep(100000);


  system("echo 1400 > /sys/class/soft_pwm/pwm113/pulse");
  printf("\nLeft");
  sleep(1);
  system("echo 0 > /sys/class/soft_pwm/pwm113/pulse");
  sleep(0.5);


  system("echo 2500 > /sys/class/soft_pwm/pwm113/pulse");
  printf("\nRight");
  sleep(1);
  system("echo 0 > /sys/class/soft_pwm/pwm113/pulse");
  sleep(0.5);


  }
}

 

Now copy the compiled soft_pwm.ko  to  /opt/soft_pwm in riotboard.

 

With all connections ready, run the servo_ctrl program compile earlier:

$ ./servo_ctrl

 

The servo will move according to the pulse entry  in servo_ctrl.c file.

 

Note:  as the code is a software pwm , you will be noticing jitter.

 

Have fun.

This post describes a procedure to generate a Linux SD card image for RIoTboard using Yocto on an openSUSE 13.2 x86_64 host.  This procedure is just a clone of the excellent procedure documented by Bryan Hinton (referred to below as B.H. for brevity) with a handful of alterations to accommodate a different host OS, more modest host hardware, minor changes in the resulting Yocto build and one or two issues peculiar to my combination of hardware and software.  Bryan's document enumerates the features of this particular Yocto build and should be consulted prior to reading the procedure below:

 

https://community.freescale.com/docs/DOC-103530

 

The procedure described below was motivated in part by a desire to see if a RIoTboard build environment for Linux could be created in openSUSE 13.2 as this is the distribution on all of my modern computers.  The procedure was also motivated by a desire to come up with an alternative to the Yocto-generated Linux 3.10.17 image provided at riotboard.org since that image causes my RIoTboard to hang when using an HDMI-to-DVI cable for video output (the available Android and Linux 3.0.35 images produce proper video output).

 

Conventions

 

In an effort to make it clear where my procedure differs from that of B.H, I will use the same numbering scheme for corresponding sections in B.H.'s document.  I will also make differing command lines or code bold in order to highlight changes.

 

1. Hardware and software prerequisites.

 

I used a Gateway NE56R12u laptop running openSUSE 13.2 x86_64 as the host machine.  This laptop has a 2.1 GHz Intel B950 dual-core Pentium processor and 8 GB of physical memory.  The OS partition has 40 GB, and the /home partition has 135 GB almost all of which was available prior to creating the build environment.  Internet connection was 1.5 Mbps down/256 kbps up.

 

uname output for the host openSUSE 13.2 x86_64 OS is as follows:

stmorgan@linux-wdyv:~> uname -ia

Linux linux-wdyv.site 3.16.7-32-desktop #1 SMP PREEMPT Wed Jan 20 14:05:33 UTC 2016 (d4df98a) x86_64 x86_64 x86_64 GNU/Linux

 

2. Required Packages for a 64-bit openSUSE 13.2 Host development system.

 

I used the following commands to install the package list for openSUSE from the Yocto Project Mega Manual without changes:

 

sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml

sudo zypper install diffstat makeinfo python-curses patch socat libSDL-devel xterm

 

3. Pull the Freescale community BSP platform source code from github.

 

curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo

chmod a+x $HOME/bin/repo

echo "PATH=$PATH:$HOME/bin" >> $HOME/.bashrc

source .bashrc

mkdir -p $HOME/src/fsl-community-bsp

cd $HOME/src/fsl-community-bsp

repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b fido

repo sync

 

4. Setup the build environment using the predefined imx6dl-riotboard machine.

 

MACHINE=imx6dl-riotboard . ./setup-environment build

 

5. Create a new layer for the custom Linux distribution.

cd $HOME/src/fsl-community-bsp/sources

mkdir -p meta-bsec/conf/distro

mkdir -p meta-bsec/recipes-bsec/images

cd poky/meta/recipes-extended/images

cp core-image-full-cmdline.bb ../../../../meta-bsec/recipes-bsec/images/bsec-image.bb

 

6. Customize the image in the meta-bsec layer.

 

cd $HOME/src/fsl-community-bsp/sources/meta-bsec/recipes-bsec/images

 

Edit bsec-image.bb as follows.

 

DESCRIPTION = "A console-only image with more full-featured Linux system \

functionality installed."

 

IMAGE_FEATURES += "dev-pkgs tools-sdk tools-debug tools-profile tools-testapps \

debug-tweaks splash ssh-server-openssh package-management"

 

IMAGE_INSTALL = "\

  packagegroup-core-boot \

  packagegroup-core-full-cmdline \

  packagegroup-core-tools-profile \

  packagegroup-core-buildessential \

  kernel-modules \

  ${CORE_IMAGE_EXTRA_INSTALL} \

  kernel-devsrc \

  "

 

inherit core-image

 

# Add extra space to the rootfs image

IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 3000000"

 

7. Create layer.conf file in the meta-bsec layer.

 

Create sources/meta-bsec/conf/layer.conf with the following contents:

 

BBPATH .= ":${LAYERDIR}"

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \

  ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "bsec"

BBFILE_PATTERN_bsec = "^${LAYERDIR}/"

BBFILE_PRIORITY_bsec = "6"

 

8. Create the distribution configuration file in the meta-bsec layer.

 

Create sources/meta-bsec/conf/distro/bsecdist.conf with the following contents:

 

require conf/distro/poky.conf

# distro name

DISTRO = "bsecdist"

DISTRO_NAME = "bsecdist distribution"

DISTRO_VERSION = "1.0"

DISTRO_CODENAME = "bsc"

DISTRO_FEATURES_append = " alsa usbhost usbgadget keyboard bluetooth"

SDK_VENDOR = "-bsecdistsdk"

SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"

MAINTAINER = "bsecdist "

INHERIT += "buildhistory"

BUILDHISTORY_COMMIT = "1"

 

9. Add the new layer to bblayers.conf.

 

cd $HOME/src/fsl-community-bsp/build/conf

 

Edit bblayers.conf as follows.

 

LCONF_VERSION = "6"


BBPATH = "${TOPDIR}"

BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"


BBFILES ?= ""

BBLAYERS = " \

  ${BSPDIR}/sources/poky/meta \

  ${BSPDIR}/sources/poky/meta-yocto \

  \

${BSPDIR}/sources/meta-openembedded/meta-oe \

${BSPDIR}/sources/meta-openembedded/meta-multimedia \

  \

  ${BSPDIR}/sources/meta-fsl-arm \

  ${BSPDIR}/sources/meta-fsl-arm-extra \

  ${BSPDIR}/sources/meta-fsl-demos \

  ${BSPDIR}/sources/meta-bsec \

"

 

10. Customize the local configuration.

 

Edit local.conf as follows:

 

MACHINE ??= 'imx6dl-riotboard'

DISTRO ?= 'bsecdist'

PACKAGE_CLASSES ?= "package_rpm package_deb"

EXTRA_IMAGE_FEATURES = " "

USER_CLASSES ?= "buildstats image-mklibs image-prelink"

PATCHRESOLVE = "noop"

BB_DISKMON_DIRS = "\

  STOPTASKS,${TMPDIR},1G,100K \

  STOPTASKS,${DL_DIR},1G,100K \

  STOPTASKS,${SSTATE_DIR},1G,100K \

  ABORT,${TMPDIR},100M,1K \

  ABORT,${DL_DIR},100M,1K \

  ABORT,${SSTATE_DIR},100M,1K"

PACKAGECONFIG_append_pn-qemu-native = " sdl"

PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"

ASSUME_PROVIDED += "libsdl-native"

CONF_VERSION = "1"

BB_NUMBER_THREADS = '2'

PARALLEL_MAKE = '-j 2'

DL_DIR ?= "${BSPDIR}/downloads/"

ACCEPT_FSL_EULA = "1"

# archive source code for all of the packages that will be built into the image

INHERIT += "archiver"

ARCHIVER_MODE[src] = "original"

# ensure that license files accompany each binary in final image

COPY_LIC_MANIFEST = "1"

COPY_LIC_DIRS = "1"

# setup source mirror

# make sure that bitbake checks for all of the source tarballs in a local directory

# before going to the Internet to fetch them.

SOURCE_MIRROR_URL ?= "file://${BSPDIR}/source-mirror/"

INHERIT += "own-mirrors"

# create a shareable cache of source code management backends

BB_GENERATE_MIRROR_TARBALLS = "1"

 

As B.H. had a quad-core processor and a fast Internet connection, it made sense for him to increase the number of processes, but I just kept the defaults given my modest setup.

 

11. Execute the build.

 

cd $HOME/src/fsl-community-bsp/build

time bitbake bsec-image

 

Here is the build console output for the curious:

 

stmorgan@linux-wdyv:~/src/fsl-community-bsp/build> time bitbake bsec-image

WARNING: Host distribution "openSUSE-project-13.2" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. 

Parsing recipes: 100% |#########################################| Time: 00:03:16

Parsing of 1603 .bb files complete (0 cached, 1603 parsed). 2088 targets, 140 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)

NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg

NOTE: multiple providers are available for jpeg-native (jpeg-native, libjpeg-turbo-native)

NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg-native


Build Configuration:

BB_VERSION = "1.26.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING = "openSUSE-project-13.2"

TARGET_SYS = "arm-poky-linux-gnueabi"

MACHINE = "imx6dl-riotboard"

DISTRO = "bsecdist"

DISTRO_VERSION = "1.0"

TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"

TARGET_FPU = "vfp-neon"

meta

meta-yocto = "(nobranch):528bdf528d8bfca7746543f61609b9aceb54d53b"

meta-oe

meta-multimedia = "(nobranch):a7c1a2b0e6947740758136216e45ca6ca66321fc"

meta-fsl-arm = "(nobranch):c9f259a4bf8472dfa3ff75f1c3fcbe5e0ded7aaf"

meta-fsl-arm-extra = "(nobranch):ad90ca98459f5de9483bb3ba5a81be0a67b078c3"

meta-fsl-demos = "(nobranch):17f9da65efb5c65c1d44b5cc18584034b29a742b"

meta-bsec = "<unknown>:<unknown>"


NOTE: Preparing RunQueue

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

WARNING: Failed to fetch URL http://downloads.sourceforge.net/project/libpng/libpng16/1.6.16/libpng-1.6.16.tar.xz, attempting MIRRORS if available

WARNING: Failed to fetch URL ftp://ftp.freedesktop.org/pub/mesa/10.4.4/MesaLib-10.4.4.tar.bz2, attempting MIRRORS if available

WARNING: Failed to fetch URL http://www.apache.org/dist/apr/apr-1.5.1.tar.bz2, attempting MIRRORS if available

WARNING: Failed to fetch URL http://www.apache.org/dist/subversion/subversion-1.8.11.tar.bz2, attempting MIRRORS if available

WARNING: Failed to fetch URL http://www.cpan.org/authors/id/D/DM/DMEGG/SGMLSpm-1.03ii.tar.gz, attempting MIRRORS if available

WARNING: Failed to fetch URL http://downloads.sourceforge.net/levent/libevent-2.0.21-stable.tar.gz, attempting MIRRORS if available

WARNING: lttng-modules: no modules were created; this may be due to CONFIG_TRACEPOINTS not being enabled in your kernel.

WARNING: QA Issue: perf rdepends on liblzma, but it isn't a build dependency? [build-deps]

WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: libstdc++-dev-4.9.2-r0@cortexa9hf_vfp_neon is already installed


WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: gettext-dev-0.19.4-r0@cortexa9hf_vfp_neon is already installed


WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: libgomp-dev-4.9.2-r0@cortexa9hf_vfp_neon is already installed


WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: libc6-dev-2.21-r0@cortexa9hf_vfp_neon is already installed


WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: libgcc-s-dev-4.9.2-r0@cortexa9hf_vfp_neon is already installed


WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: libubsan-dev-4.9.2-r0@cortexa9hf_vfp_neon is already installed


WARNING: log_check: There is a warn message in the logfile

WARNING: log_check: Matched keyword: [warn]

WARNING: log_check: warning: libasan-dev-4.9.2-r0@cortexa9hf_vfp_neon is already installed


NOTE: Tasks Summary: Attempted 6410 tasks of which 18 didn't need to be rerun and all succeeded.

NOTE: Writing buildhistory


Summary: There were 30 WARNING messages shown.


real 600m58.864s

user 596m9.764s

sys 93m20.155s

 

B.H.'s build took 4 hours, while mine took 10 hours.  A subsequent re-build without changes took less than 90 minutes and only about 200 tasks needed execution as opposed to the 6410 required initially.

 

B.H. also enumerates a list of five files that define input specifications in this step.  I made no changes to any of these files.

 

12.  Write the GNU/Linux BSP image to an SD card.

 

This step was the only real hurdle in the entire process.  The bottom line is that I was unable to get a dd command to create a usable SD card unless I deleted all partitions on the card prior to executing dd.  The Partitioner tool in the YaST Control Center can be used to delete partitions on the SD card as needed in openSUSE.

 

lsblk --fs

cd $HOME/src/fsl-community-bsp/build/tmp/deploy/images/imx6dl-riotboard

sudo dd if=bsec-image-imx6dl-riotboard.sdcard of=/dev/sdb bs=1M

sudo sync

 

The lsblk command is used to insure that the SD card has no partitions (partitions would show up as sdb1, sdb2, etc.).

 

13. Set the physical switches on the RioTboard to boot from the uSD or SD card.

 

I was using an SD card, so I set the switches accordingly (1 0 1 0 0 1 0 1).

 

14. Connect the target to the necessary peripherals for boot.

 

Since the Yocto-generated Linux 3.10.17 image did not produce usable video or boot on my board, I made a point of creating a serial connection to the RIoTboard J18 port in addition to connecting the HDMI-to-DVI cable, and that setup is documented here:

 

https://www.element14.com/community/community/designcenter/single-board-computers/riotboard/blog/2016/02/14/jbtek-serial-tty-to-usb-cable-setup-on-riotboard

 

I was pleasantly surprised to find that the openSUSE BSP image not only booted, it generated the proper video output on the HDMI-to-DVI cable as well.  In addition to a USB keyboard and mouse, I connected a microphone/headphone set with 3.5mm connectors to test the RIoTboard audio input/output.

 

15. Test audio recording, audio playback, and Internet connectivity.

 

Type root to log in to the target. The root password is not set.

 

Execute the following command on the RIoTboard:

 

alsamixer

 

Press F6.

Press arrow down so that 0 imx6-riotboard-sgtl5000 is highlighted.

Press Enter.

Increase Headphone level to 79<>79.

Increase PCM level to 75<>75.

Press Tab.

Increase Mic level to 59.

Increase Capture to 80<>80.

Press Esc.

 

At this point B.H. used sample sounds available in the build to test the audio output, but these samples are not present in the latest build. I therefore skipped this step and proceeded to the microphone test since it actually tests both recording and playback of .WAV files.

 

cd /usr/share/alsa

mkdir tmp

cd tmp

arecord -d 10 micintest.wav

 

Talk into the microphone for ten seconds.

 

aplay micintest.wav

 

You should hear your recording played through the headphones.

 

ping riotboard.org

 

You should get an ICMP reply.

 

root@imx6dl-riotboard:~# uname -ia

Linux imx6dl-riotboard 4.1.2-fslc+g95d9e15 #1 SMP Sat Feb 13 02:40:39 EST 2016 armv7l GNU/Linux

 

Conclusion

 

openSUSE 13.2 can be used to create a Linux BSP for the RIoTboard using Yocto and Bryan Hinton's procedure as a basis.  If you have been disappointed by the lack of a pre-built Yocto Linux image, I would encourage you to set up a build environment in your Linux distribution (whatever it may be) and create your own BSP, assuming you have the necessary memory and disk space.

Erich Styger provided an excellent description of how to connect the FTDI-based Embest  UART8000-UUART8000-U USB-to-TTL cable to the J18 interface on the RIoTboard in order to create a system console on a Windows host in the following post

 

http://mcuoneclipse.com/2014/07/21/terminal-connection-to-the-riot-board/

 

This post will describe how to connect a Prolific-based JBtek/Adafruit USB-to-TTL cable to the RIoTboard J18 interface in order to create a system console on a Windows host in conjunction with Tera Term (a Windows communication program). Important differences between Styger's setup and the JBtek setup as well as some additional points to bear in mind will be also be discussed.

 

(***IMPORTANT DISCLOSURE***: While I have used and tested two of the JBtek cables with the RIoTboard, I do not own nor have I tested the Adafruit 954 cable discussed below. Hopefully, someone in the community who has both the Adafruit 954 (second revision) and a RIoTboard can confirm that same procedure described below works for that particular cable as well.)

 

 

The Jbtek/Adafruit 954 USB-to-TTL Serial Cable

 

The cable I used to create a system terminal is a “JBtek® WINDOWS 8 Supported Debug Cable for Raspberry Pi USB Programming USB to TTL Serial Cable“ available from Amazon.com:

 

http://www.amazon.com/JBtek%C2%AE-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88

 

This cable uses a Prolific PL2303TA device according to Prolific's CheckChip utility on one of my Windows 7 machines. Unfortunately, it ships with zero documentation or drivers.

 

While I have been unable to find an unequivocal statement from either JBtek or Adafruit Industries that the JBtek cable I purchased is identical to the Adafruit 954 product, there is a great deal of evidence to suggest that they are almost, if not completely, identical:

 

https://www.adafruit.com/product/954

http://www.amazon.com/ADAFRUIT-INDUSTRIES-954-USB-TO-TTL-RASPBERRY/dp/B00DJUHGHI

 

The Adafruit page for the 954 cable indicates the following:

Revision History

Prior to July 1 2014 this cable would come with a PL2303HX chipset and a black USB body. After July 1, 2014 we changed to a violet body and the PL2303TA chipset. The new 'TA cables are Win8 compatible, and are more reliable especially when dealing with random USB-disconnects.

Newark/element14 sell the Adafruit 954 (in some locales), but the picture on the Newark/element14 site seems to show the earlier revision, so it isn't obvious whether they are in fact selling the most recent revision of the Adafruit 954:

 

http://www.newark.com/adafruit-industries/954/usb-to-ttl-serial-cable-raspberry/dp/44W3509

 

 

Windows Drivers for the JBtek Cable

 

I used the Version 1.12.0 PL2303 driver (PL2303_Prolific_DriverInstaller_v1_12_0.zip) available here to install the needed Prolific driver on both Windows 7 and Windows 8.1 machines prior to connecting the JBtek cable:

 

http://prolificusa.com/pl-2303hx-drivers/

 

This driver package also contains the CheckChip utility mentioned above if you are uncertain or concerned about which exact Prolific chip your cable is using. In order to use the CheckChip utility, you have to know which COM port the cable is using, and that means the device has to be successfully installed prior to using the utility.

 

 

Connecting the Cable to the RIoTboard

 

In order to physically connect the JBtek (or Adafruit) serial cable to the RIoTboard J18 interface, use the following connections (with no power applied to the RIoTboard):

 

JBtek White wire (RXD) to J18 Pin 1 (UART2_TXD) (farthest pin from corner of board)

JBtek Green wire (TXD) to J18 Pin 2 (UART2_RXD) (middle pin)

JBtek Black wire (GND) to J18 Pin 3 (GND) (pin closest to corner of board)

JBtek Red wire (5V) is unconnected

 

Here is a photo of the J18 interface after the JBtek cable has been connected (references to Pin numbers in the photo correspond to the J18.pin-out, not the JBtek cable):

 

JBTek USB-to-Serial TTY Connection to  RIoTboard J18

 

If you compare the photo above with that provided by Erich Styger for the Embest  UART8000-UUART8000-U cable connection in his post(mentioned and linked above one very important point stands out there is no common color coding scheme for these serial cables In other words if you try to connect the JBtek(or Adafruit cable to the RIoTboard by matching the wire colors in Styger's photo you will mis-connect the cable Guaranteed Also remember this fact if you are trying to connect some other cable not discussed in this post because it may well have a different pin-out/color scheme compared to any discussed here For example some serial cables have CTS/RTS lines as well

 

Another point that is probably worth mentioning has to do with the unconnected JBtek red wire (+5 Volts). If you look carefully at the photo above, you can see that the internal metal structure of the box-shaped connector on the end of the red wire is not entirely shielded by the insulating plastic (look at the edge of the Pin 3 bubble where it overlaps the connector). For the connectors attached directly to the RIoTboard J18 interface, this is not likely to cause problems, but the exposed metal on the loose JBtek red wire connector might come into contact with the grounded shells on the RIoTboard Ethernet or USB connectors for example. Therefore, it is a good idea to completely cover the connector on the JBtek red wire with some sort of insulation to prevent inadvertent contact with anything on the RIoTboard when the USB end of the cable has been mated to a USB port.

 

Configuring Tera Term

 

In order to display output from the J18 Serial Debug port using Tera Term (Version 4.89) on a Windows computer, do the following (assuming a fresh install):

 

1. Start Tera Term

2. Click the Serial radio button and select the COM port labeled “Prolific USB-to-Serial Comm Port”

3. Click the OK button

4. Click the Setup tab in the Tera Term VT window and select Serial Port

5. Change the Baud Rate to 115200 and click the OK button (Other parameters should be as follows by default:  Data:  8 bit; Parity:  none; Stop:  1 bit; Flow control:  none)

6. Click the Setup tab in the Tera Term VT window and select General...

7. In the Tera Term General Setup dialog box, change the Language from UTF-8 to English (if you fail to do this, you will see terminal output, but it will be garbled)

8. Apply power to the RIoTboard and output should now appear in the Tera Term VT window

In this mini blog series we will build an IoT based intruder detection and alert system.

 

Blogs:

Part1 : Connecting Pir Sensor

Part2 : Capturing intruder image

Part3Email alert  <--- this blog

 

In previous blog we integrated a camera to Riotboard for capturing images on IR detection.

 

In this mini blog we will send email (with captured image) of the intruder.

 

now add below line to previous code (below ln30)

system("python /opt/send_snapshot.py");


#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main()
{
int ret =0;
int fd=0;
char buf[1];

system("devmem 0x20E00A0 w 0x5  ");
system("echo 113 > /sys/class/gpio/unexport");
system("echo 113 > /sys/class/gpio/export");
usleep(100000);
system("echo in > /sys/class/gpio/gpio113/direction");
usleep(100000);

fd = open("/sys/class/gpio/gpio113/value",O_RDONLY);
while(1)
{
ret = read(fd,buf,sizeof(1));
if(lseek(fd,0,SEEK_SET) < 0) return 1;

if(ret>0 && (atoi(buf)==1))
    {
        printf("\n\033[031;43m HUMAN DETECTED \033[0m ");
        fflush(stdout);
        system("fswebcam -d /dev/video2 capture.jpg");
        usleep(500000);
        system("python /opt/intrusion_detection/send_snapshot.py");
    }
else
    printf("\nNo Detection");

fflush(stdin);
fflush(stdout);
usleep(500000);

}
close(fd);
}




 

 

Now create a file "send_snapshot.py" in /opt/ directory

cd /opt/

touch send_snapshot.py

 

copy the below contents to "send_snapshot.py"

#!/usr/bin/python

import smtplib
from email.MIMEMultipart import MIMEMultipart
from email.MIMEBase import MIMEBase
from email.MIMEText import MIMEText
from email import Encoders
import os

send_user = "YOUR_GMAIL_ID@gmail.com"        #sender_email
send_pwd = "YOUR_GMAIL_PASSWORD"             #sender_password
recv_user = "YOUR_GMAIL_ID@gmail.com"        #receiver_email
subject = "intrusion detected !!!!"

def mail(to, subject, text, attach):
   msg = MIMEMultipart()

   msg['From'] = send_user
   msg['To'] = recv_user
   msg['Subject'] = subject

   msg.attach(MIMEText(text))

   part = MIMEBase('application', 'octet-stream')
   part.set_payload(open(attach, 'rb').read())
   Encoders.encode_base64(part)
   part.add_header('Content-Disposition',
           'attachment; filename="%s"' % os.path.basename(attach))
   msg.attach(part)

   mailServer = smtplib.SMTP("smtp.gmail.com", 587)
   mailServer.ehlo()
   mailServer.starttls()
   mailServer.ehlo()
   mailServer.login(send_user, send_pwd)
   mailServer.sendmail(send_user, to, msg.as_string())
   mailServer.close()

mail(recv_user,    subject,"below is the snapshot of intruder !!!","capture.jpg")






 

this script sends snapshot to gmail,  in line 10,11 & 12 replace the defaults with your sender gmail id, sender gmail password and receiver email.

 

Now perform some hand movement infront of IR sensor, it will show human detected, captures image as "capture.jpg" and sends an email.

 

ruqy6d.jpg

 

Received email:

 

555snd.jpg

 

 

So we conclude this mini blog series on Intrusion detection and notification.

In this mini blog series we will build an IoT based intruder detection and alert system.

 

Blogs:

Part1 : Connecting Pir Sensor

Part2 : Capturing intruder image  <--- this blog

Part3 : Email Alerts

 

In previous blog we integrated a PIR sensor to Riotboard for human movement detection.

 

In this very short guide we will try to capture image once an IR detection is made.

 

I am using a  Logitech C310Logitech C310 USB camera for this purpose.


logitech c310 camera

 

Connect pir sensor HC-Sr501 and Camera to Riotboard.

image snapshot

 

to capture image we will use fswebcam tool.

 

in terminal type:

    apt-get install fswebcam

fswebcam

 

Now we determine the usb device

 

type "ls /dev/video*" without pluggin camera.

Now pluggin camera to Riotboard, and type "ls /dev/video*"

check for video device in /dev.

the camera hardware is accessible at the device /dev/video2

riotboard camera device

 

now add below line to previous code  below ln28.

system("fswebcam -d /dev/video2 capture.jpg");

 

Next we will compile the below code and test.

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main()
{
int ret =0;
int fd=0;
char buf[1];

system("devmem 0x20E00A0 w 0x5  ");
system("echo 113 > /sys/class/gpio/unexport");
system("echo 113 > /sys/class/gpio/export");
usleep(100000);
system("echo in > /sys/class/gpio/gpio113/direction");
usleep(100000);

fd = open("/sys/class/gpio/gpio113/value",O_RDONLY);
while(1)
{
ret = read(fd,buf,sizeof(1));
if(lseek(fd,0,SEEK_SET) < 0) return 1;

if(ret>0 && (atoi(buf)==1))
    {
        printf("\n\033[031;43m HUMAN DETECTED \033[0m ");
        fflush(stdout);
        system("fswebcam -d /dev/video2 capture.jpg");
        usleep(500000);
    }
else
    printf("\nNo Detection");

fflush(stdin);
fflush(stdout);
usleep(500000);

}
close(fd);
}















 

Now perform some hand movement infront of Pir sensor, it will show human detected and captures image as "capture.jpg".

pir camera capture

 

before capture:

hukhh3.jpg

 

after capture:

neyn3s.jpg

 

Now with every pir interrupt we can capture the image of the intruder.

 

Next time we will add an image based email alert for the above.

In this mini blog series we will build an IoT based intruder detection and alert system.

 

Blogs:

Part1 : Connecting Pir Sensor  <--- this blog

Part2 : Capturing intruder image

Part3 : Email Alerts

 

 

In this post we shall connect a simple cheap Pir motion sensor to Riotboard.

We will be using Pir sensor HC-Sr501.

 

pir_sensor_image

 

pir_sensor_image_open

 

Pir Sensor HC-Sr501 has pins : VCC, GND, OUT.


VCC will be connected to pin2 (5VIN) in J13 expansion port.

GND will be connected to pin4 (GND) in J13 expansion port.

OUT will be connected to pin7 (GPIO4_17) in J13 expansion port.

 

246292s.jpgpir_sensor_pins

 

(plz check usermanual  for more info on J13 expansion port)

 

 

Pir setup..

2yx3tdg.jpg

 

this post uses the Linux BSP available here.

 

Next we will compile the below code and test.

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main()
{
int ret =0;
int fd=0;
char buf[1];

system("devmem 0x20E00A0 w 0x5  ");
system("echo 113 > /sys/class/gpio/unexport");
system("echo 113 > /sys/class/gpio/export");
usleep(100000);
system("echo in > /sys/class/gpio/gpio113/direction");
usleep(100000);

fd = open("/sys/class/gpio/gpio113/value",O_RDONLY);
while(1)
{
ret = read(fd,buf,sizeof(1));
if(lseek(fd,0,SEEK_SET) < 0) return 1;

if(ret>0 && (atoi(buf)==1))
    {
        printf("\n\033[031;43m HUMAN DETECTED \033[0m ");
        fflush(stdout);
        usleep(500000);
    }
else
    printf("\nNo Detection");

fflush(stdin);
fflush(stdout);
usleep(500000);

}
close(fd);
}

          

 

code explanation:

ln12 : using devmem to convert pin7 to gpio.

ln14:  exporting pin7 as gpio in /sys/class  for user.

ln16 : configure pin7 as gpio input , in pir we are reading(input) the OUT pin value .

ln19 : opening gpio as READ_ONLY

ln23: while reading a file the pointer moves by certain position,

           in this case the file  frequently updated.

           so using lseek  system call to read file from beginning,

ln25 : if HIGH value (1)  present it means movement detected.

 

Q. why so many fflush & usleep used ??

A. to ensure the GPIO read and the terminal write happens in sync with program flow.

 

Now perform some hand movement infront of Pir sensor, it will show HUMAN DETECTED

 

No movement

30j4l4w.jpg

 

Hand movement

msk6t5.jpg

 

 

Video demo:

 

 

 

in the next blog we will capture intruder image & send snapshot based on pir interrupt.

 

 

Intro

I was inspired by Otto's blog series of getting Debian Linux on the RIoTboard: Linux on the RIoTBoard Part 1: U-Boot. However I need Ubuntu instead.

 

Following are the steps to get a current Linux kernel (4.1) with Ubuntu 14.04 (should work with a more current version one too).

 

Requirements

I used Ubuntu 14.04 x86_64 to implement these instructions (actually it was a Virtual machine on VirtualBox).

 

Install Build dependencies:

sudo apt-get install git build-essential fakeroot kernel-package u-boot-tools lzop zlib1g-dev libncurses5-dev gcc-4.7-arm-linux-gnueabihf
sudo ln -s arm-linux-gnueabihf-gcc-4.7 /usr/bin/arm-linux-gnueabihf-gcc





Please note the specific install of gcc 4.7.  This is because the current version (as of 09/2015) in 14.04 of gcc 4.8 has a bug when building the Linux Kernel.  Feel free to try 4.9 or a fixed 4.8.

The following is needed to chroot to arm based rootfs.

sudo apt-get install qemu-user-static





This is needed to help in the steps to create an sdcard image.

sudo apt-get install qemu-utils kpartx





 

Environment Variables

Here are environment variables used in the scripts that follow.

export ARCH=arm
export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-
export RIOT_PATH=~/riotboard
export RIOT_OUTPUT=$RIOT_PATH/output
mkdir -p $RIOT_OUTPUT





 

U-Boot

Here are the steps to build version 2015.07 of U-boot:

cd $RIOT_PATH
wget ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2
tar xjf u-boot-2015.07.tar.bz2
cd u-boot-2015.07
make riotboard_defconfig
make
cp u-boot.imx $RIOT_OUTPUT/.
cd $RIOT_PATH





If you prefer to use the latest U-Boot or a different version see: SourceCode < U-Boot < DENX

 

Bootscript

The boot.scr is used by U-Boot to give it the boot arguments to pass to the kernel as well as were to find the kernel and DTB.

Please note this script is very basic and needs to know where you will be booting from.  Change the DEVICE= line if you will be booting from eMMC or MicroSD instead.  My eMMC is busted so I have to boot from uSD or SD.

mkdir -p $RIOT_PATH/bootscript
cd $RIOT_PATH/bootscript
# Device 0=SD, 1=MicroSD, 2=eMMC
DEVICE=0
cat <<EOF > bootscript
setenv bootargs console=ttymxc1,115200 nosmp video=mxcfb0:dev=hdmi,1280x720M@60,bpp=32 video=mxcfb1:off fbmem=10M vmalloc=400M rootwait root=/dev/mmcblk0p1
mmc dev $DEVICE
ext4load mmc $DEVICE:1 10800000 /boot/zImage
ext4load mmc $DEVICE:1 16800000 /boot/imx6dl-riotboard.dtb
bootz 10800000 - 16800000
EOF
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "boot script" -d bootscript boot.scr
cp boot.scr $RIOT_OUTPUT/.
cd $RIOT_PATH





 

Kernel

I decided to use a specific released version (i.e. v4.1) of the kernel rather than the tip.  Feel free to change the tag to switch to a different version or remove the -b option if you want to build the tip.  I have not fully tested 4.1 but so far seems to work ok on the RIoTboard.

For detail on each step below see Otto's blog.

cd $RIOT_PATH
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git -b v4.1
cd linux
make imx_v6_v7_defconfig
# Do this next step if you need to change kernel config.
make menuconfig
# this next step will take a long time.  You can try -j option to parallelize.
make bzImage
mkdir -p $RIOT_OUTPUT/boot
sudo cp arch/arm/boot/zImage $RIOT_OUTPUT/boot/zImage
make dtbs
sudo cp arch/arm/boot/dts/imx6dl-riotboard.dtb $RIOT_OUTPUT/boot/imx6dl-riotboard.dtb
make modules
make modules_install INSTALL_MOD_PATH=$RIOT_OUTPUT
make headers_install INSTALL_HDR_PATH=$RIOT_OUTPUT/usr
cd $RIOT_OUTPUT
tar -czf linux-kernel.tgz boot lib usr
rm -rf boot lib usr





 

Root Filesystem

For the rootfs I decided to start from the official ubuntu release and customize it as opposed to building it completely like Otto showed in his blog for Debian.  You can browse here: Index of /ubuntu-core/releases if you would like to pick a different ubuntu release.  If you do, make sure to use an armhf one and update the customizations below in case they are different for your distro.

Unlike other steps above I am going to break this one down:

Get a starting rootfs

cd $RIOT_PATH
mkdir -p $RIOT_OUTPUT/rootfs
wget http://cdimage.ubuntu.com/ubuntu-core/releases/trusty/release/ubuntu-core-14.04-core-armhf.tar.gz
sudo tar --numeric-owner -xzpf ubuntu-core-14.04-core-armhf.tar.gz -C $RIOT_OUTPUT/rootfs





Customize the rootfs

We will chroot to the arm rootfs to make some of the customizations.

# to enable arm emulation
sudo cp /usr/bin/qemu-arm-static $RIOT_OUTPUT/rootfs/usr/bin/
# to enable dns lookups to work
sudo cp /etc/resolv.conf $RIOT_OUTPUT/rootfs/etc
sudo chroot $RIOT_OUTPUT/rootfs





Do your customizations.  Feel free to adjust the stuff below to your needs.  Please note not all of what I am doing below needs to be done from chroot (e.g the file editing and creations).

# setup a locale
locale-gen en_US en_US.UTF-8
# Install any packages you want that are not in the core rootfs from Ubuntu.com
apt-get -y install openssh-server ntpdate
# Create users. The following adds usr/pw: ubuntu/ubuntu
PASSWD=`openssl passwd -crypt ubuntu`
/usr/sbin/useradd ubuntu -m -s /bin/bash -p $PASSWD
# The stuff below can be done outside of chroot. Just make sure to adjust destination files if you do.
# Enable the user to sudo without the need for pw.
echo -e 'ubuntu\tALL=(ALL)\tNOPASSWD: ALL' >> /etc/sudoers
# Configure your network
cat <<EOF >> /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
EOF
# Set the hostname
echo riotboard > /etc/hostname
# Enable login from the serial console
cat <<EOF > /etc/init/serial-console.conf
# serial-console - getty
#
# This service maintains a getty on console from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]

stop on runlevel [!2345]

respawn
exec /sbin/getty -L 115200 ttymxc1 vt100
EOF
#setup fstab to mount the rootfs
echo '/dev/mmcblk0p1  /  auto  errors=remount-ro  0  1' >> /etc/fstab





Clean up apt, exit chroot and remove the chroot setup files

# Clean up apt
apt-get clean
exit
# Clean up files we added to enable chroot and dns
sudo rm $RIOT_OUTPUT/rootfs/usr/bin/qemu-arm-static
sudo rm $RIOT_OUTPUT/rootfs/etc/resolv.conf





 

Bundle up the rootfs:

cd $RIOT_OUTPUT/rootfs
sudo tar -czpf ubuntu-trusty.tgz *
sudo mv ubuntu-trusty.tgz $RIOT_OUTPUT/.





 

Create SD Card Image

Now we create the SD Card image that we will write to an SD card.  You could even write this to the eMMC device (don't forget to change the boot script to load from device 2 if you do this).  If you prefer you can use /dev/sdX instead of sdcard.img below if you want to write direct to the SD card instead of an image first.

cd $RIOT_OUTPUT
# Create a file to hold the disk image
qemu-img create sdcard.img 3600M
# Partition the disk image leaving some room (10mb) for u-boot in front of the first partition.
sfdisk --force -uM sdcard.img << EOF
10,,83
EOF
# create devices from the disk image
sudo kpartx -av sdcard.img
# format the partition. Make sure to use the correct device from the previous command.
mkfs.ext4 -j /dev/mapper/loop0p1
# create a mount point
sudo mkdir -p /mnt/sdcard
# Mount the partition we formatted.
sudo mount -t ext4 /dev/mapper/loop0p1 /mnt/sdcard
# Unpack the root fs and kernel
sudo tar --numeric-owner -C /mnt/sdcard -zxpf ubuntu-trusty.tgz
sudo tar --numeric-owner -C /mnt/sdcard -zxpf linux-kernel.tgz
# Copy the boot script to the top level
sudo cp boot.scr /mnt/sdcard/boot.scr
# Unmount and clean up devices
sudo umount /mnt/sdcard
sudo kpartx -dv sdcard.img
# put u-boot 2 blocks into the disk image.  Don't leave out the notrunc option.
dd if=u-boot.imx of=sdcard.img bs=512 seek=2 conv=notrunc






Now you can use dd or whatever tool you want to write the disk image to an SD card. Eg: sudo dd if=sdcard.img of=/dev/sdd bs=1m

 

Boot your SD Card

Plug the SD Card into the SD card slot.  Set the switches 2,4,5,7 to OFF and the rest to ON to boot from SD.

If you are using a MicroSD, make sure to change the boot script to use device 1 instead of 0 and set the dip switches to 2,4,5,8 OFF and the rest ON.

 

Notes

See Otto's blog post mentioned above for how to use the MfgTool to write the above files to the eMMC flash from Windows as well as more detailed explanations to some of the stuff above..

RiotBoard-Internet-of-Things-IoT.jpg

This blog post describes how I set up my RioTBoard RioTBoard to be a media center. I was inspired by brixtonian1970's Marine Aquarium Interface DreamBoard, and I decided to basically copy it with a RIoTBoard running Android and a compatible WiFi moduleWiFi module. My goal was to build a media center in the garage so that I could listen to music or keep an eye on the latest football game while doing some work out there.

 

Installing Android

There is already a good tutorial out there on how to install Android on the RIoTBoard:

 

Flashing a new Android Image to the RIoTBoard | MCU on Eclipse

 

So, I won't repeat any of that information here.  The above article also has information about how to get the latest Android image.

 

Of course, another option would be to build it from source:

 

Building Android from Source

 

Connect to Wifi

 

RPI-WIPI-2-800x533.jpg

 

With the latest version of Android installed, it should be super easy to get Wifi up and running.  Meaning all you need to do is turn on Wifi, and then click on the network that you would like to connect to.  As a side note, some Wifi dongles work better than others.  The Wi-PiWi-Pi works well right out of the box with the latest Andriod image.

 

Installing Kodi

 

Once Wifi is up and working, either navigate your browser to:

 

http://kodi.tv/download

 

Or click on the Google search bar and search for “Kodi”. The official website should be the first result and then navigate to the downloads section.

 

Once within the downloads section, click on the Android – ARM option.

Kodi Download.png

There are two ways to get to the downloaded file. The first is to swipe down from the top-left of the screen. There will be a little down arrow there. This will bring up a list of files that have been down loaded. The other is through the apps menu. In there will be a “Downloads” entry.

 

When you click on this file, you might get a message saying that the install was blocked. This message will have two options: one to cancel and one to go to the settings page. Click on the settings page. Within the settings page, there should be an option called “Unknown sources”. This will allow programs to be installed that do not come through the Google Play store. Click that check mark. It will then prompt you to make sure that you are certain (which you are).

 

Changing the settings kicked me out of the installation process, so you might have to find the .apk file again and click on it again.

 

Smart Phone as a Remote Control

 

You can use your smartphone as a remote control for Kodi. To do this, install Kore on your phone. (Instructions not provided, since it will vary depending on what type of phone you have.)

 

Once that is installed, we need to configure it. First, go to System – Settings. Then navigate to the Webserver option. Within that menu there should be an option to “Allow control of Kodi via HTTP”, enable that option. Then make sure to set the username and password.

 

Within Kore, the Add Media Center wizard should come up. This will automatically search for any instances of Kodi on your local network. Once it finds it, you can put in your user name and password.

 

Now your smartphone is connected to your media center and can be used as a remote control!

 

Plugins

 

Kodi has a rich plugin community. These plugins really extend the functionality and take Kodi from a great application to a spectacular one! Here's a list of the 20 best Kodi plugins:

 

http://www.htpcbeginner.com/best-kodi-addons-2015-for-cordcutters/

 

Conclusion

 

Setting up Kodi on the RioTBoard was fairly easy, since everything that we need is built in. It is just a matter of finding the right packages and installing them. Everything seems to run really well, and I'm looking forward to being able to keep an eye on the Browns as I do a little work on the car!

MAb

New riotboard.org website is Live!

Posted by MAb Jun 16, 2015

It's Live!

 

31190-IND-RIoT-logotypemarktag-HR.png

The brand new www.riotboard.org website has been released.

 

In this new comprehensive website, you'll find much more information on your precious development board:

 

- Home: general overview

- Hardware: everything about technical features

- Software: more about available software (Android, Linux) and downloads

- Wiki: plenty of user guides for all kinds of users

- Accessories: more about available devices to extend your riotboard

- Review: different roadtests

- Applications: good ideas or new ideas on how to use riotboard explained by users

- Forum: Q&A

 

it's here !

I met Gregory from Freescale at Maker Faire Paris beginning of May after some emails going back and forth regarding another Freescale board. After having exchanged some ideas and feedback, he was kind enough to send me a RIoTboard and some accessories for evaluation purposes and has also given me access to a preview version of the new RIoTboard website due to be launched this summer.

 

This is my first post about the RIoTboard, more specifically on getting everything set up and ready for some projects.

 

 

What is it ?

 

The RIoTboard is an open source community platform, supported by element14 and powered by a Freescale i.MX6 ARM Cortex-A9 processor. The board is meant to help evaluate the various peripherals and includes:

 

1.jpg0.jpg

  • 10/100/Gb ethernet port
  • HDMI port
  • LVDS
  • analog audio in/out
  • microSD and SD card interfaces
  • JTAG
  • two camera ports
  • four USB ports
  • two mini USB ports
  • serial debug port
  • expansion port with PWM, SPI, I2C, UART, ...
  • reset button


The Freescale i.MX6 ARM Cortex-A9 processor runs at 1GHz, there is 1GB of DDR memory and 4GB eMMC. Powering the board is done through a 5V DC barrel jack connector.


The name appears to be a clever wordplay as the tag line is "Revolutionising the Internet of Things":  revolution, IoT, riot, RIoTboard. The logo of a raised fist holding the board fits nicely in the theme.


The board is currently listed at 73EUR (before tax) on the Farnell website, which compared to a Raspberry Pi or Beaglebone Black may seem on the high side, especially since the launch of the quad core Raspberry Pi model 2 at 38EUR.

 

What's in the box ?

2.jpg


In the box, you'll find the following items:

  • RIoTboard
  • mini-USB cable
  • quick start guide

 

Additionally, you will need following items:

  • HDMI monitor
  • USB keyboard and mouse for input, even if only for initial configuration
  • 5V/4A power supply

 

And you may need:

  • wifi dongle for wireless connectivity instead of using the ethernet port
  • (micro)SD card (4GB minimum) to use/test an alternative operating system
  • USB UART cable for troubleshooting

 


3.jpg4.jpg

 

First boot


By default, the RIoTboard boots from the onboard flash which has Android 4.3 pre-installed.

 

Different OS


There are two ways to use a different operating system with the RIoTboard:

  • overwrite the pre-installed OS on the onboard flash
  • boot from a (micro)SD card containing a different OS


I personally prefer the second option (SD card), especially when starting out, for the following reason:

  • more simple procedure that can be executed on any operating system
  • preserves the onboard flash in its current state
  • is not limited to 4GB


Because of these reasons, I will only be covering the SD card approach to use a different operating system.

 

Operating systems


There are currently four flavours of available operating systems:

  • Android 4.3 (Jelly Bean)
  • Android 4.4 (Kit Kat)
  • Linux 3.10.17 (Yocto)
  • Linux  3.0.35 (Ubuntu)


All four come in two variants: eMMC or SD Card. Depending on where you wish to flash the OS on, you will need to download the correct image.Which flavour you pick depends on your preference, what you are familiar with and what you intend to do with the RIoTboard. For this getting started guide, I'll be proceeding with the Yocto Linux image.


If you want to know more about Android, check out this link to training material for developers: https://developer.android.com/training/index.html

 

Flashing the SD card


Flashing an image to the SD card is done in the same way as with the Raspberry Pi. So if you are familiar with that, there should be no problems.First, extract the downloaded zip file containing the image, then using "dd" (Linux/OS X) or "Win32DiskImager" (Windows), flash the image on the SD card. The time to flash the SD card may vary depending on its speed, but I've experienced times around 10 minutes using the latest image. It is recommended to use an SD card of at least 4GB, preferably 8GB.


5.png

 

DIP switch settings


Once the SD card is ready, power off the RIoTboard and insert the SD card. Before powering on the board, it is required to tell it to boot from the card rather than the onboard flash. This is done using the DIP switch in the middle of the board.


These are the settings:

  • boot from onboard flash: 10110111
  • boot from SD card: 10100101

 

Booting


With the SD card inserted and the DIP switch settings adapted, all that remains is to power on the RIoTboard.

 

Wireless connectivity


As far as I'm aware, there are currently two officially supported wifi dongles:

  • Wi-Pi wifi dongle
  • element14 wifi dongle (purple)

 

Both can be obtained from element14 and are compatible with other boards such as the Raspberry Pi or Beaglebone Black.

 

6.jpg

 

Android

 

Wireless connectivity works out-of-the-box using the Android 4.4 image (not with 4.3!).

 

Linux

 

Using the Yocto image, I was having trouble getting the wifi to work. The wifi dongle was listed using the "lsusb" command, but no "wlan0" interface was available.

 

7.png

 

After seeking help on the element14 forums in the RIoTboard area, I was given a newer Yocto image (riotboard_yocto_gui_SVN3000) with which wifi worked immediately, just like with the Android 4.4 image. I've been told this newer image will be officially released soon and the issue was related to kernel gadget support not being configured in the previous build.

 

The new image I received is also more lightweight (1.4GB vs 3.9GB) and boots straight to a graphical environment.

 

8.png9.png

10.png11.png

 

Connecting remotely

 

SSH

 

SSH is enabled by default. One thing to pay attention to though, is that no password is configured for the "root" user, making the system open for anyone.

A password is easily configured using the "passwd" command.

 

Fredericks-Mac-mini:~ frederickvandenbosch$ ssh root@192.168.0.136
root@riotboard:~# passwd
Changing password for root
Enter the new password (minimum of 5, maximum of 8 characters)
Please use a combination of upper and lower case letters and numbers.
New password:
Re-enter new password:
passwd: password changed.




 

Next time you try to log in via SSH, you will be prompted for the password.

 

Fredericks-Mac-mini:~ frederickvandenbosch$ ssh root@192.168.0.136
root@192.168.0.136's password:
root@riotboard:~#




 

VNC

 

Using VNC, it is possible to access the desktop remotely.

First the VNC server needs to be started. This can be done via SSH with the following command:

 

root@riotboard:~# x11vnc -bg -rfbport 5900 -skip_lockkeys -o /tmp/x11vnc.log




 

Once this is executed, connect to the desktop using a VNC client and IP address of the RIoTboard and port 5900.

 

12.png13.png

 

Just like with SSH, there is no password configured by default. This can easily be changed.

 

root@riotboard:~# x11vnc -storepasswd
Enter VNC password:
Verify password:
Write password to /home/root/.vnc/passwd? [y]/n
Password written to: /home/root/.vnc/passwd




 

Running VNC with an additional "-usepw" flag will ensure the defined password is required when connecting.

 

root@riotboard:~# x11vnc -usepw -bg -rfbport 5900 -skip_lockkeys -o /tmp/x11vnc.log




 

14.png

 

Additional resources

 

This is a list of useful links to tutorials or additional information on the RIoTboard.

 

Conclusion

 

Aside from the issues with the wifi using the Linux image, setting up the RIoTboard is fairly easy. If you already have experience with other SBCs such as the Raspberry Pi or Beaglebone Black, there is not much new to know to get started.

 

In a next post, I'll be working on a first project using the RIoTboard, continuing with the Yocto Linux OS.