Tuesday, March 29, 2016

Identification & Authentication

Cherry Blossoms








Identification


Identification is the process whereby a human or computer presents its identity to another human or computer. When you claim that you are a certain person, you are presenting your identity. This process is known as identification.  

For example, when you introduce yourself to someone, you present your identity to her.  When you travel on a plane, you have to wait in a line to have your bags checked.  Before placing your bags on the conveyor belt to be scanned, you present your driver's license or government ID card to a law enforcement, security officer.   The process of presenting your ID card to the officer is called identification.   

Authentication


After you present your ID card to the officer, she reads your ID card and compares your physical face to the printed photo of your face.  The process of comparing your physical face to the printed face on the ID card is called authentication.  If your physical face matches the face on the printed ID card, then you are successfully authenticated. The officer may also compare your name on the ID card against the name that is printed on the airline ticket. 

The process of validating your identity is called authentication.  Formally, authentication is the process whereby a human or computer validates that you are who you say you are.

Human-Generated Facial Signatures


When the officer views your photo on the ID card, she looks for distinguishable physical characteristics on your face.  She identifies features on your face. It is this combination of unique characteristics that forms a visual signature of you. She then looks at your physical face and creates a second physical signature, after which she compares the signature of your printed face with the signature of your physical face.  If they match, then you are successfully authenticated and can proceed to the conveyor belt. She may also perform additional checks as already mentioned.  

The process that her brain performs when creating human facial signatures and storing them in her brain's memory is called an algorithm. Formally, an algorithm is a finite sequence of steps or rules that produce a solution to a problem.  

Computer-Generated Facial Signatures


Computers can execute algorithms more efficiently than humans. While the human brain can form a visual signature of someone by identifying unique combinations of visual, facial characteristics, a computer can also create a visual signature of a person's identity.  In contrast to a human, a computer can identify millions of tiny pixels in a photograph and compare them against the pixels in another photograph. Computer algorithms perform shading and blending to identify facial features with extreme precision.  A unique signature is generated that is both computationally complex and reproducible. If you are standing at a 90 degree angle to a camera instead of an 85 degree angle, then the same unique signature of your face can be generated.  If you are standing at an 80 degree angle to the camera and you are wearing make up, then the same signature can be created. If there are 300 million other people also getting their photos taken at these angles, both with and without makeup, the computer can still generate unique signatures for every single human. The computer representation of this information is typically a long string of numbers. Your name and birth date are typically appended to this long string of numbers.  The entire string or a partial length of the string are then stored in computer memory so that the computation of the signature can be easily recalled when needed.  Replacing your name with someone else's name in this string or modifying your unique physical characteristics could mean the creation of an identity that is not you.  

It is for this reason that your signature must be stored in a secure computer system.  Microprocessor-based storage chips often provide an encrypted, non-volatile medium for the storage of identification information.  This cryptographic storage medium is usually accompanied by a small, embedded, and highly optimized microprocessor for performing computationally expensive cryptographic operations or algorithms such as encryption, decryption, and signature generation.

As we grow older and our physical features change, computer algorithms should compensate for these changes and generate the same or similar unique signatures. DNA can also be used to uniquely identify humans.  Computer algorithms should properly compensate for changes in human DNA so that individuals can be uniquely identified.


Resources


Sunday, November 8, 2015

Configuring the Cyclone V FPGA SoC Boot loader on a DE0-Nano-SoC board

Understanding the boot loader on a computer system is probably the most important aspect of security. Most computer systems have multiple boot loaders that run in sequence immediately after a power reset is applied to the processor on the computer system.  This applies to embedded, desktop, and server systems.
The Captain America logo was popular this Halloween. 

So I picked up a couple of Altera FPGA SoC boards a few weeks ago and immediately pulled up all of the documentation that I could find on the Cyclone V SoC.  This SoC has an FPGA and a Hard Processor System (HPS) woven into a single processor package.  The HPS is a dual core ARM Cortex A9.  Building everything from scratch is the best way to figure out how the system works.

The boot sequence on a Cyclone V HPS works like this:

The On-chip ROM (for which source code is not provided) loads the preloader (1st stage bootloader). The preloader then loads U-boot. U-boot then loads the kernel and root file system.

There are two well thought out options for the preloader according to the Cyclone V boot guide.  The two options are licensed differently depending on how you build the source code.  One is licensed under a BSD license and the other under GPL v2 with U-Boot.

Building a pre-loader image for the DE0-Nano-SoC board was straightforward.  Altera provides the bsp-editor utility for customizing the preloader configuration and generating the BSP HPS preloader source code, after which, make is used to build the sources using the Mentor ARM cross toolchain.
The preloader settings directory can be found on the DE0-Nano-SoC CD in the DE0_NANO_SOC_GHRD subdirectory.


The preloader load address can be set via the bsp-editor so that the on chip ROM either loads the preloader from an absolute zero address on the sdcard or from a fat partition with id equal to a2 on the sdcard.  These are the options for booting from the sdcard.

After the sources are generated and the preloader image is built using the Makefile, U-boot must be compiled. An Altera port of U-Boot is available on github for the Cyclone V FPGA SoC. U-Boot is built using the Linaro ARM cross toolchain.

There's quite a bit you can do with the Cyclone V FPGA SoC boot configuration.  FPGA images can be loaded from U-boot.  The jumpers on the board can be configured to boot from the on-board serial flash (QSPI), bare metal applications can be loaded from the preloader, the FPGA can be configured from serial flash, and the list goes on.  The HPS SoC Boot Guide for the Cyclone V SoC  is a valuable reference and contains all of the boot configuration information.



Wednesday, October 28, 2015

Altera Cyclone V FPGA SoC - the Possibilities are endless

Altera FPGA SoC and Camera
Altera FPGA ARM Powered® SoC and Camera - the Possibilities are endless

Altera's new Cyclone V FPGA SoC - An Integrated ARM® Cortex®-A9 MPCoreTM Processor System and Cyclone V FPGA.

The DE0-Nano-SoC development board was released by Terasic in the summer of 2015 and includes the lateset Cyclone V FPGA SoC.  The board comes with a wealth of features including an analog to digital converter (LTC2308) and has an Arduino expansion header. 


There are an adequate number of programmable logic elements on the FPGA - 40K along with 5 fractional PLLs and 2460 Kbits of embedded memory.  The ARM® Cortex®-A9 MPCore Dual Core processor (HPS) runs at 925Mhz and the board has 1GB of DDR3 SDRAM.   The board also includes an on board ethernet PHY, USB OTG and Micro-AB connectors, a micro SD card slot, accelerometer, and built-in USB Blaster II.

Altera Quartus II 15.0 Web Edition and Altera SoC Embedded Design Suite with ARM DS-5 AE run seamlessly on X86 64 Fedora 21.  The board supports OpenCL so you can easily program the FPGA from Linux user space running on the HPS. Finally, writing a newly compiled bitstream to the FPGA from Quartus II running on an attached Linux host was also seamless.



Monday, August 17, 2015

The "Three Fives" Discrete 555 Timer Kit

I picked up a "Three Fives" Discrete Timer Kit this weekend.  As it turns out the kit was well worth the money.  The "Three Fives" Discrete Timer Kit is a transistor-scale replica of the NE555 timer IC.  The printed circuit board (PCB) is high-quality and soldering the transistors and resistors was alot of fun. Thanks to  Eric Schlaepfer and Evil Mad Scientist Labs for this high quality circuit kit.

The size of the board makes it easy to measure what's going on inside the circuit.  Just connect the probes from an oscilloscope to any of the solder or test points on the board.

A photo of the board that I built is below. I also wired a sample test circuit for blinking a pink LED and then connected a scope to the board so that I could look at the square wave.


Here is the sample test circuit that is wired on the breadboard. Substitute resistor and capacitor values where applicable.

http://www.555-timer-circuits.com/flashing-led.html



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