Monday, July 20, 2015

Creating a custom Linux Image for the Raspberry Pi











Creating a custom Linux distribution for the Raspberry Pi is very similar to creating a custom Linux distribution for the RIoTboard.  A new meta-layer is created and customized. The Yocto project already has support for the Raspberry Pi.  There is a hardware specific BSP overlay layer in the Yocto project called meta-raspberrypi.  The layer contains machine specific tunings, compile time parameters, kernel configuration options, and boot loader parameters that are specific to the Raspberry Pi hardware.  Other items such as the GPU/CPU memory split, ARM and GPU processor frequencies, and SDRAM frequency are also set in the pre-existing bsp layer.

This guide provides simple directions for creating an operating system image (U-Boot, GNU/Linux kernel, and root file system) for the Raspberry Pi.  The operating system image will contain native ARM cross compilers, a full development environment, and kernel source code.  These directions will work for the Raspberry Pi 2, B+, B, and A+.

The operating system image will be called specialpi.

Note: The Yocto Project will be releasing version 1.9 in October at which time, several changes will be incorporated which fix the current kernel defconfig issue with the meta-raspberrypi layer. In the mean time, the best option for customizing the raspberry pi kernel is building it in the Linux tree, or out of the Yocto tree.  By default, the meta-raspberrypi layer pulls the broadcom defconfig from the applicable kernel branch and uses that for the configuration.

A 64-bit Fedora 21 GNU/Linux host will be used to compile all of the source components.  Here is what uname shows on my development host:
Fedora release 21 for x86_64 GNU/Linux kernel 4.0.7-200.fc21.x86_64 #1 SMP

This guide consists of the following steps.

1. Install required Packages for a 64-bit Fedora 21 Host development system
2. Pull the Raspberry Pi layer from the Yocto project
3. Create the specialpi layer and image.
4. Make the specialpi image useful.
5. Create layer.conf in the specialpi layer.
6. Make the specialpi layer visible.
7. Set the type of MACHINE.
8. Set up the local configuration.
9. Execute the build.
10.Burn the build to a bootable media device.
11. Validate the build.

Hardware and software prerequisites

Host Operating System


Fedora release 21 for x86_64
GNU/Linux kernel 4.0.7-200.fc21.x86_64 #1 SMP

Host Hardware


Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
Physical Memory 12 GB
My /home partition is 414 GB and resides on a solid state hard drive.

The Yocto build requires a large amount of space so I recommend keeping a scratch area on your /home partition of at least 100 GB.  You can get away with less space but if you decide to make changes to the source and binaries within the Yocto tree later on down the line, then it is a good idea to have extra space.


1. Install required Packages for a 64-bit Fedora 21 Host development system


from the Yocto Project Mega Manual Revision 1.8

Execute the following commands on the development host.

 host]$ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
        diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
        ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \
        findutils which
 host]$ sudo yum install SDL-devel xterm perl-Thread-Queue
 host]$ sudo yum install make docbook-style-dsssl docbook-style-xsl \
        docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
 host]$ sudo yum install autoconf automake libtool glib2-devel

2. Pull the Raspberry Pi layer from the Yocto project



Execute the following commands on the development host.

host]$ mkdir $HOME/bin
host]$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
host]$ chmod a+x $HOME/bin/repo
host]$ echo "PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
host]$ source .bashrc
host]$ mkdir -p $HOME/src/rpi
host]$ cd $HOME/src/rpi
host]$ git clone git://git.yoctoproject.org/poky -b fido
host]$ cd poky
host]$ git clone git://git.yoctoproject.org/meta-raspberrypi -b fido
host]$ git clone git://git.openembedded.org/meta-openembedded -b fido
host]$ source oe-init-build-env build
host]$ export RPIHOME=$HOME/src/rpi/poky

3. Create the specialpi layer and image


Execute the following commands on the development host.

host]$ cd $RPIHOME
host]$ mkdir -p specialpi/recipes-specialpi/images
host]$ mkdir specialpi/conf
host]$ cd specialpi/recipes-specialpi/images
host]$ cp ../../../meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb specialpi.bb

4. Make the specialpi image useful


Modify meta-specialpi/recipes-specialpi/images/special.bb so that it looks like the following

include recipes-core/images/core-image-minimal.bb

IMAGE_FEATURES += "tools-sdk tools-debug debug-tweaks ssh-server-openssh"

# Include modules in rootfs
IMAGE_INSTALL += " \
 packagegroup-core-buildessential \
 kernel-modules \
 kernel-devsrc \
 "

inherit core-image

IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 3000000"

5. Create layer.conf in the specialpi layer.


Modify meta-specialpi/conf/layer.conf so that it looks like the following

BBPATH .= ":${LAYERDIR}"

# We have a recipes directory containing .bb and .bbappend files, add to BBFILES
BBFILES += "${LAYERDIR}/recipes*/*/*.bb \
            ${LAYERDIR}/recipes*/*/*.bbappend"

BBFILE_COLLECTIONS += "specialpi"
BBFILE_PATTERN_specialpi := "^${LAYERDIR}/"
BBFILE_PRIORITY_specialpi = "7"


6. Make the specialpi layer visible


Modify build/conf/bblayers.conf so that it looks like the following

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

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

BBLAYERS ?= " \
  /home/ns/src/rpi/poky/meta \
  /home/ns/src/rpi/poky/meta-yocto \
  /home/ns/src/rpi/poky/meta-yocto-bsp \
  /home/ns/src/rpi/poky/meta-raspberrypi \
  /home/ns/src/rpi/poky/meta-specialpi \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  /home/ns/src/rpi/poky/meta \
  /home/ns/src/rpi/poky/meta-yocto \
  "


7. Set the type of MACHINE


For Raspberry Pi Model B,set MACHINE in build/conf/local.conf above the MACHINE ?? = "qemux86" line as follows
MACHINE ?= "raspberrypi"

For Raspberry Pi 2, B+, or A+,
set MACHINE in build/conf/local.conf above the MACHINE ?? = "qemux86" line as follows

MACHINE ?= "raspberrypi2"

8. Set up the local configuration

Add the following lines to the end of build/conf/local.conf file

CONF_VERSION = "1"
INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
SOURCE_MIRROR_URL ?= "file://${TOPDIR}/source-mirror/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"

9. Execute the build


For Raspberry Pi Model B, insert an SD card into the host.

Execute the following commands on the development host.

host]$ cd $RPIHOME/build
host]$ bitbake specialpi
host]$ cd tmp/deploy/images/raspberrypi
host]$ dd if=specialpi-image-raspberrypi.rpi-sdimg off=/dev/sd<X> bs=1M
host]$ sync

For Raspberry Pi 2, B+, or A+, insert a uSD card into the host.

Execute the following commands on the development host.

host]$ cd $RPIHOME/build
host]$ bitbake specialpi
host]$ cd tmp/deploy/images/raspberrypi
host]$ dd if=rpi-specialpi-image-specialpi.rpi-sdimg of=/dev/sdb bs=1M
host]$ sync

10.Burn the build to a bootable media device


For Raspberry Pi Model B, insert an SD card into the host.
Execute the following commands on the development host.

host]$ cd build/tmp/deploy/images/raspberrypi
host]$ dd if=specialpi-raspberrypi.rpi-sdimg off=/dev/sd<X> bs=1M
host]$ sync

For Raspberry Pi 2 or Model B+, insert a uSD card into the host.

Execute the following commands on the development host.

host]$ cd build/tmp/deploy/images/raspberrypi
host]$ dd if=specialpi-raspberrypi.rpi-sdimg of=/dev/sdb bs=1M
host]$ sync


11. Validate the build


Insert the SD card or uSD card in to the Raspberry Pi and validate that the Raspberry Pi properly boots the image on the SD or uSD card.

You should get a login prompt that says
Poky (Yocto Project Reference Distro) 1.8 raspberrypi /dev/ttyAMA0

The username is root. There is no password.
Kernel sources are in /usr/src/kernel
gcc is in /usr/bin

Increase IMAGE_ROOTFS_EXTRA_SPACE_append as needed in special.bb


Monday, July 13, 2015

Creating a custom Linux BSP for the RIoTboard with Yocto 1.8 Fido - Part III


In part III of this guide, we will cover the installation of the final image to the SD card. We will then boot the SD card on the target. Finally, we will test audio recording and playback.
Part III of this guide consists of the following sections.

  1. Write the GNU/Linux BSP image to an SD card.
  2. Set the physical switches on the RioTboard to boot from the uSD or SD card.
  3. Connect the target to the necessary peripherals for boot.
  4. Test audio recording, audio playback, and Internet connectivity.


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

At this point, the build should be complete, without errors.  You should see something like this on the terminal


 real 254m28.335s
 user 737m9.307s
 sys 133m39.529s

Insert an SD card into an SD card reader, connect it to the host, and execute the following commands on the host.


 host]$ cd $HOME/src/fsl-community-bsp/build /tmp/deploy/images/imx6dl-riotboard
 host]$ sudo umount /dev/sd<X>
 host]$ sudo dd if=bsec-image-imx6dl-riotboard.sdcard of=/dev/sd<X> bs=1M
 host]$ sudo sync


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


For booting from the SD card on the bottom of the target, set the physical switches as follows.
SD (J6, bottom) 1 0 1 0 0 1 0 1

For booting from the uSD card on the top of the target, set the physical switches as follows.
uSD (J7, top) 1 0 1 0 0 1 1 0

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

You have two options here. 


Option 1

Connect one end of an ethernet cable to the target. Connect the other end of the ethernet cable to a hub or DHCP server.  

Connect the board to the host computer via the J18 serial UART pins on the target.  This will require a serial to USB breakout cable.  Connect TX, RX, and GND to RX, TX, and GND on the cable. The cable must have an FTDI or similar level shifter chip. Connect the USB end of the cable to the host computer.

Connect your speakers to the light green 3.5 mm audio out jack and your microphone to the pink 3.5 mm MIC In jack.

Connect a 5V / 4 AMP DC power source to the target.

Run minicom on the host computer. You will need to configure minicom at 115200 8N1 with no hardware flow control and no software flow control. If you are using a USB to serial cable with an FTDI chip in it, then the cable should show up in /dev as ttyUSB0 in which case, set the serial device in minicom to /dev/ttyUSB0.

If you choose this option, you can drop into U-boot after power on by pressing Enter on the host keyboard with minicom open and connected.

If you don't press enter after power on, the target will boot and you will get a login prompt.

You will now see a login prompt.

Option 2

Connect one end of an ethernet cable to the target. Connect the other end of the ethernet cable to a hub or DHCP server.  

Connect a USB keyboard, USB mouse, and monitor (via an HDMI cable) to the target.

Connect your speakers to the light green 3.5 mm audio out jack and your microphone to the pink 3.5 mm MIC In jack.

Connect a 5V / 4 AMP DC power source to the target.

You will now see a login prompt.


4. 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 commands on the target

 root@imx6dl-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.

 root@imx6dl-riotboard: cd /usr/share/alsa/sounds
 root@imx6dl-riotboard: aplay *.wav 

You should hear sound played through the speakers.

 root@imx6dl-riotboard: cd /tmp
 root@imx6dl-riotboard: arecord -d 10 micintest.wav

Talk into the microphone for ten seconds.

 root@imx6dl-riotboard: aplay micintest.wav

You should hear your recording played through the speakers.

 root@imx6dl-riotboard: ping riotboard.org

You should get an ICMP reply.

Creating a custom Linux BSP for the RIoTboard with Yocto 1.8 Fido - Part II


In the second part of this guide, we will pull the source code, customize the build configuration, and execute the build.  Part II of this guide consists of the following sections.
  1. Pull the Freescale community BSP platform source code from github. 
  2. Setup the build environment using the predefined imx6dl-riotboard machine.
  3. Create a new layer for the custom Linux distribution.
  4. Customize the image in the meta-bsec layer. 
  5. Create layer.conf file in the meta-bsec layer. 
  6. Create the distribution configuration file in the meta-bsec layer. 
  7. Add the new layer to bblayers.conf.
  8. Customize the local configuration.
  9. Execute the build.

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


Execute the following commands on the host.
 host]$ mkdir $HOME/bin  
 host]$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo 
 host]$ chmod a+x $HOME/bin/repo  
 host]$ echo "PATH=$PATH:$HOME/bin" >> $HOME/.bashrc  
 host]$ source .bashrc  
 host]$ mkdir -p $HOME/src/fsl-community-bsp  
 host]$ cd $HOME/src/fsl-community-bsp  
 host]$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b fido  
 host]$ repo sync  

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


Execute the following commands on the host.

 host]$ MACHINE=imx6dl-riotboard . ./setup-environment build  

3. Create a new layer for the custom Linux distribution


Execute the following commands on the host.

 host]$ cd $HOME/src/fsl-community-bsp/sources  
 host]$ mkdir -p meta-bsec/conf/distro  
 host]$ mkdir -p meta-bsec/recipes-bsec/images  
 host]$ cd poky/meta/recipes-extended/images  
 host]$ cp core-image-full-cmdline.bb \
        ../../../../meta-bsec/recipes-bsec/images/bsec-image.bb

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


Execute the following commands on the host.

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

Customize bsec-image.bb as follows.  Lines with bold text indicate lines to add to the file.

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

 # customize IMAGE_FEATURES as follows
 IMAGE_FEATURES += "dev-pkgs tools-sdk tools-debug tools-profile tools-testapps \
 debug-tweaks splash ssh-server-openssh package-management"

 # packagegroup-core-tools-profile will build and install tracing and profiling tools to the target image.
 # packagegroup-core-buildessential will build and install autotools, gcc, etc. to the target image.
 # kernel-modules for install of the kernel modules.
 # kernel-devsrc for building out of tree modules.
 # IMAGE_ROOTFS_EXTRA_SPACE_append for adding extra space to the target rootfs image.

 # customize IMAGE_INSTALL as follows
 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"

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


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

BBPATH .= ":${LAYERDIR}"  
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \  
     ${LAYERDIR}/recipes-*/*/*.bbappend"  
 BBFILE_COLLECTIONS += "bsec"  
 BBFILE_PATTERN_bsec = "^${LAYERDIR}/"  
 BBFILE_PRIORITY_bsec = "6"  

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


Create sources/meta-bsec/conf/disro/bsecdist.conf with the below 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"

7. Add the new layer to bblayers.conf


Execute the following commands on the host.

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

Customize bblayers.conf by adding the meta-bsec layer to BBLAYERS 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 \
 "

8. Customize the local configuration


Customize local.conf as follows.

 MACHINE ??= 'imx6dl-riotboard'
 # set distro name
 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 = '4'
 PARALLEL_MAKE = '-j 4'
 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"

9. Execute the build


Execute the following commands on the host.

 host]$ cd $HOME/src/fsl-community-bsp/build 
 host]$ time bitbake bsec-image 

While the image is building, please take note of the following.

The input specifications for the GNU/Linux kernel and U-boot segments of the BSP are in the below files. These specifications include such things as GNU/Linux kernel patch files for i.MX 6 processor features, kernel boot args, kernel load address, cortex specific tuning parameters, etc.

 sources/meta-fsl-arm-extra/conf/machine/imx6dl-riotboard.conf  
 sources/poky/meta-yocto/conf/distro/poky.conf  
 sources/meta-fsl-arm/recipes-kernel/linux/linux-imx.inc  
 sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc_4_0.bb  
 sources/poky/meta/conf/machine/include/tune-cortexa9.inc

In part III of this guide, we will boot the image on the target and then test audio recording and playback. Continue to part III of this guide.

Continue to Part III

Creating a custom Linux BSP for the RIoTboard with Yocto 1.8 Fido - Part I

This guide is an update to "Creating a custom Linux distribution for an ARM® Cortex®-A9 based SBC" and provides directions for building a GNU/Linux BSP for the RioTboard with Yocto 1.8 on a 64-bit Fedora 21 GNU/Linux host.  The latest stable version of Yocto (1.8 - Fido) has been incorporated along with build instructions for version 4.0.7 of the GNU/Linux kernel with i.MX 6 patches, U-boot, audio recording and playback support, and a full kernel and application development environment on the target.

This guide is split into three parts as follows.

I. Creating a custom Linux BSP for the RioTboard with Yocto 1.8 Fido - Part I
  1. Hardware and software prerequisites.
  2. Required Packages for a 64-bit Fedora 21 Host development system.
II. Creating a custom Linux BSP for the RioTboard with Yocto 1.8 Fido - Part II
  1. Pull the Freescale community BSP platform source code from github. 
  2. Setup the build environment using the predefined imx6dl-riotboard machine.
  3. Create a new layer for the custom Linux distribution.
  4. Customize the image in the meta-bsec layer. 
  5. Create layer.conf file in the meta-bsec layer. 
  6. Create the distribution configuration file in the meta-bsec layer. 
  7. Add the new layer to bblayers.conf.
  8. Customize the local configuration.
  9. Execute the build.
III. Creating a custom Linux BSP for the RioTboard with Yocto 1.8 Fido - Part III
  1. Write the GNU/Linux BSP image to an SD card.
  2. Set the physical switches on the RioTboard to boot from the uSD or SD card.
  3. Connect the target to the necessary peripherals for boot.
  4. Test audio recording, audio playback, and Internet connectivity.

The BSP will consist of a GNU/Linux 4.0.7 kernel, an EXT3 root filesystem, and the U-Boot bootloader.  All components will be compiled from the latest, public sources.  The GNU/Linux system will include support for audio recording and playback via the RioTboard's MIC In and Audio Out jacks.  We will also build in support for ethernet, ipv4, bluetooth, USB host and USB gadget, and an ssh server.  The final target image will also contain native ARM compilers, a full SDK, strace, GDB, package management tools, and the GNU/Linux 4.0.7 kernel source code with i.MX 6 patches already applied.

In the first guide for Yocto 1.7, a custom distribution and target image was created by extending the core-image-minimal image.  In this guide, a custom distribution and target image will be created by extending the core-image-full-cmdline image.  The resulting target image will be larger in size but will include a much richer set of features for kernel and application level development and debugging on the target.

Finally, Yocto will be configured so that all source packages are archived in their original format with accompanying license files.

To start with, please read Setting up an ARM® Cortex®-A9 based SBC which outlines the necessary components that you will need to get started.  You will also need a microphone and a set of powered speakers, both with 3.5mm connectors.  I have an Audio-Technica ATR4650 microphone and a pair of Logitech S-00134 powered speakers connected to the RioTboard.  We will need these for testing audio recording and playback.

1. Hardware and software prerequisites



Host Operating System

Fedora release 21 for x86_64
GNU/Linux kernel 4.0.7-200.fc21.x86_64 #1 SMP

Host Hardware

Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
Physical Memory 12 GB
My /home partition is 414 GB and resides on a solid state hard drive.


The Yocto build requires a large amount of space so I recommend keeping a scratch area on your /home partition of at least 100 GB.  You can get away with less space but if you decide to make changes to the source and binaries within the Yocto tree later on down the line, then it is a good idea to have extra space.

2. Required Packages for a 64-bit Fedora 21 Host development system


from the Yocto Project Mega Manual Revision 1.8

Execute the following commands on the host.

 host]$ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
        diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
        ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \
        findutils which
 host]$ sudo yum install SDL-devel xterm perl-Thread-Queue
 host]$ sudo yum install make docbook-style-dsssl docbook-style-xsl \
        docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
 host]$ sudo yum install autoconf automake libtool glib2-devel

In Part II, we will continue by pulling the source code for the kernel, boot loader, and root file system packages.  We will then build all of these components from source and prepare the GNU/Linux BSP image for the target.

Continue to Part II

Wednesday, April 29, 2015

What does it mean to be green?

You might think that assigning a unique number to every living human in the world sounds crazy.  You also might think that assigning a unique number to every living human in your country or state sounds crazy.

For many, the notion of such systems brings back memories of dark times in world history.  The last generation of those who survived the holocaust can still be seen today with numbers inscribed on their arms in black ink.  Atrocious crimes were committed during this time period of history.  Consequently, permanent associations were created.  For those of us who have seen elderly individuals with numbers inscribed on their forearms, we think of the crimes that were committed during the second world war.

 It goes without saying, the subject of assigning numbers to human beings is far from popular.  Thoughts of global control and conspiracy cloud the thoughts of many.  The current practicality of every human being inscribed with a number on their arm at birth is nil.  Even at the country level, no one would put up with it.  Alternatively, scientists and doctors have proposed the insertion of identification chips underneath the skin.  The electronic chips would store a unique number.  The only problem is that by the time the electronic chips were delivered to the hospital, the technology would soon be close to end of life.  Even so, cloning the chip would render the system useless.

Why are systems like these being proposed?  The list is certainly huge.  For many, health care and insurance come to mind.  For others, personal credit, law enforcement, and national security come to mind.  For whatever the reason, good or bad, classifying humans with numbers is a debated topic.

On a simple scale, the department of public safety manages a database of driver's licenses and the social security administration manages a database of social security numbers. These systems work well for their intended purpose.  However; they too are approaching end of life in terms of technology.

Copyright Grateful Dead
Alice can trade social security cards with Eve, albeit illegally.  Perhaps they are sisters and look very similar.  Perhaps Bob decides that he wants to make photo copies of Eve's driver's license, change the photo, and then apply for a new Blockbuster movie membership.  The list goes on.

Most people would agree that their identity is important to them. Your identity is tied to your bank account and your credit history is tied to your identity.   Equally so, your identity is who you are.  It is the places that you have been in life. It is the moments that you spent with loved ones and it is the photographs that you took on your favorite vacations.  Your identity is comprised of some many things that make you unique.  It is the aisle that you walk down when you buy groceries and it is the way that you sip your coffee in the morning.  It is the exact time that you call your family members to tell them that you love them and it is those childhood memories that you will never forget.  It is also the exact amount of money in your bank account at this moment in time and it is every payment that you have ever made to every creditor in your credit history file.  Your eye color, your hair color, your skin color, the length of your hair, the shape of your face, and the way you walk when you just finished working out help form your identity.  Your DNA can be uniquely associated to your identity.  And most importantly, your memory (or your memories) in your brain form your identity. Without memories, we would not know what our identity was.  The memories in our brain are more important than our DNA.  DNA can be replicated. The human brain cannot (yet).

If some or all of this information is copied without the knowledge of the
person it is copied from, then the person that it is copied to is "green".

So if someone were to take all of this information from you, who would you be?  Perhaps it sounds completely crazy that someone could actually take all or part of this stuff from you.  In actuality, just a small fraction of this information can reek havoc if stolen.  In today's time, this information can be stolen in microseconds from the other side of the world.  During World War II, this could not happen anywhere near the scale of where it can happen today.

Most of the characteristics described above form a loose connection to the individual.  There is no intrinsic association between a person and a subset of DNA base pairs that describe that person's genetic traits.  Equally so, there is not an intrinsic association between a person and that person's bank account.  Alice can trade social security cards with Eve and the system begins to break down.  In contrast, there is an intrinsic association between a person and his or her brain.  We have not yet figured out how to transplant memories or subsections of the brain between different humans.

For the past several years, several efforts have been underway to build a system that will keep us safe and help protect our financial credit history.

Systems such as these are concerned with identification and authentication.  Validating that someone is who they say they are is critical for three reasons:  individual security, national security, and global security.

Formally, authentication is the act or process of confirming the truth of an entity or single piece of data.  In the context of computers and cryptography, authentication is used to verify and validate a single identity that has been previously described by identification data.

Neither asymmetric or symmetric cryptography solve the authentication problem.

Wednesday, April 15, 2015

Vim for assembly, programming, and system admin

Computer pioneer, Bill Joy, created the Vi text editor.  Vi has made its way onto nearly every UNIX and Linux computer and is used by kernel developers, system administrators, programmers, and users.  The learning curve is steep; however, the ability to run circles around 95% of UNIX programmers, administrators, and the like can easily be achieved.  One hour per day for five to six years digging through kernel source code with ctags will allow you to become proficient with the editor. If you are already a C programmer and can work from the terminal quickly, then picking up Vi should be easy for you.  My notes below describe how to setup VIM, a fork of Vi that includes features such as color syntax highlighting.

Thanks to this guy for creating an awesome Vi cheat sheet for programmers. He has also created a Vi emulator Plugin for Microsoft Word.

 Vim is especially useful for reading assembly and bootloader code.when a VGA connection is not available.
! Spin Lock - Solaris 2.6 C4.2
.seg "text"
.global set_byte ! make the name visible outside the .o file
.global clear_byte !
.global spin_lock !
!
set_byte:
retl
ldstub [%o0],%o0 ! delay slot for retl
!
clear_byte:
set 0x0,%o1
swap [%o0],%o1
retl
nop ! delay slot for retl
!
!
spin_lock:
busy_loop:
ldstub [%o0],%o1
tst %o1
bne busy_loop
nop ! delay slot for branch
!
retl
nop ! delay slot for branch


For the non-programmer, having Vi handy on a terminal means easily modifying any readable file on a UNIX system from the terminal - including log files and tcpdump log file snippets.  Quickly setting up snort config files, copying public and private keys between files on servers, configuring build systems, and modifying /etc/hosts and resolv.conf can easily be done with Vim. 

Running make tags from the top level Linux kernel source tree will build the ctags file over the Linux kernel source. Alternatively; man ctags will show you how to recursively run ctags over your source code.
Nerd Tree and Taglist are two useful plugins that can be downloaded from vim.org.  
Once NERD tree and Taglist are placed in ~/.vim/plugin/, the following lines in your .vimrc will allow you to use 

<ctrl-n> and <ctrl-m> to toggle the file explorer and visual tag list.
nmap <silent> <c-n> :NERDTreeToggle<CR>
nnoremap <silent> <c-m> :TlistToggle<CR>

Also, if you need a status line:
set statusline=\ %{HasPaste()}%F%m%r%h\ %w\ \ CWD:\ %r%{CurDir()}%h\ \ \ Line:\ %l/%L:%c
function! CurDir()
let curdir = substitute(getcwd(), '/Users/myhomedir/', "~/", "g")
return curdir
endfunction

function! HasPaste()
if &paste
return 'PASTE MODE  '
else
return "
endif
endfunction

Vim should be good to go at this point. cd back into your source code directory and begin work.  Finally, man vim will tell you more about how to use the editor.

Enter g?g? in command mode on the current line of text.and Vim will perform a rot13 encryption of the text.

And here's that rot13 encryption algorithm in sparc assembler (courtesy of colorado.edu)
.section ".text"
.align 4
.global main
.type main,#function
.proc 020
main:
save %sp, -112, %sp ! save the stack!
mov 0, %o0 ! stdin
readbyte:
sub %fp, 1, %o1 ! 1 byte below frame pointer
mov 3, %g1
!call read
mov 1, %o2 ! 1 byte
ldub [%fp-1], %l1 ! pull the byte into %l1
cmp %o0, 0
be done ! byte was EOF, jump to done
and %l1, 32, %l2
xor %l2, 0xff, %l3 ! invert %l2, store as a temp
and %l1, %l3, %l1
cmp %l1, 0x41
bl skip ! note lack of trailing nop.
cmp %l1, 0x5A ! the instructions trailing
bg skip ! these branches affect nothing
mov 26, %o1 ! if the branch isn't taken.
sub %l1, 0x41, %l1 ! add 'A'
add %l1, 13, %l1
call .rem ! (modulus) call is unconditional
mov %l1, %o0 ! so final arg can be set afterwards
add %o0, 0x41, %l1
skip: or %l1, %l2, %l1 stb %l1, [%fp-1] ! return the byte to memory
mov 1, %o0 ! setup syscal args
sub %fp, 1, %o1
mov 4, %g4
! call write
mov 1, %o2
ba readbyte ! return to beginning
mov 0, %o0 ! stdin (see beginning)
done: ret ! return
restore ! fix stack before return completes

In conjunction with Vi, od and/or hexdump (if installed) can be used for examining binaries on different flavors of UNIX.

Thursday, January 29, 2015

Customizing a Linux distribution for an ARM® Cortex®-A9 based SBC

We will be pulling Yocto 1.7.1 (Dizzy branch) from Freescale source and building a BSP for the i.MX 6 RIoTboard. The final image will consist of the following components

  • U-Boot version 2014.10 from the Freescale git repositories.
  • Linux kernel version 3.17.4 from the Freescale git repositories.
  • ext3 root filesystem with selected packages

Camas Lilies at Sunrise

The image will be built from the custom distribution (bsecdist) and custom image (bsec-image) defined in the last post. bsec-image is derived from core-image-minimal. The configuration changes below will add support for package tests to the baec-image. In addition, the profiling tools and static development libraries and header files will be added to the image. Finally, several standard userspace packages will be added to baec-image; namely, bison, flex, and and gunning. Last, several configuration directives will be added to the local configuration file so that source code archives, package versions, and accompanying license files are stored and cached in a local directory for future builds and compliance purposes.