We will begin by creating a new layer. The new layer will act as the base of our home automation project. For now, it will only contain our image recipe, but we will add more content to the layer throughout the chapter until we have all the parts needed for our server. Just as described in Chapter 7, Deploying a Custom Layer on the Raspberry Pi, we will use yocto-layer to help us set up the structure of the layer. We need to set a high priority to ensure that content from this layer is prioritized over, for example, content in meta-raspberrypi, like so:

$ /path/to/poky/scripts/yocto-layer create packt-iot
Please enter the layer priority you'd like to use for the layer: [default: 6] 10
Would you like to have an example recipe created? (y/n) [default: n] 
Would you like to have an example bbappend file created? (y/n) [default: n] 
New layer created in meta-packt-iot.
Don't forget to add it to your BBLAYERS (for details see meta-packt-iot/README).

In this subsection, we will improve upon the usage of a customized image recipe, which we learned in Chapter 7 , Deploying a Custom Layer on the Raspberry Pi..

Start by creating your image recipe file:

$ cd meta-packt-iot
$ mkdir -p recipes-core/images/
$ touch recipes-core/images/packt-iot-image.bb

Next, we will set up the basic content of the image; take a look at the following code snippet. This image recipe will be growing during the entire chapter until we finally have a complete image that fits our purpose. The image will be based on rpi-basic-image.

$ cat recipes-core/images/packt-iot-image.bb
# Base this image on rpi-basic-image
include recipes-core/images/rpi-basic-image.bb
SPLASH = "psplash-raspberrypi"
IMAGE_FEATURES += "ssh-server-dropbear splash"
IMAGE_INSTALL_append = " rpi-gpio"

When working with image recipes, two commands called ROOTFS_PREPROCESS_COMMAND and ROOTFS_POSTPROCESS_COMMAND exist. They can be used as the last resort to, for example, add, remove, or modify content in the root filesystem. The two methods can be used either just before the root filesystem is created using the PREPROCESS variant or after the root filesystem has been created using the POSTPROCESS method. They are used by specifying a list of functions to the variable. The functions can use ${IMAGE_ROOTFS} to, in a generic way, find out the path to the filesystem. For this project, we will use this method to add a function to ROOTFS_POSTPROCESS_COMMAND that will create a release file for our image. Add the following content last in packt-iot-image.bb:

ROOTFS_POSTPROCESS_COMMAND += " create_release_file ; " 
create_release_file() { 
IMAGE_REL_FILE="${IMAGE_ROOTFS}${sysconfdir}/packt-iot-release" 
    echo "packt-iot release version 1.0" > ${IMAGE_REL_FILE} 
    echo "Image: ${IMAGE_NAME}" >> ${IMAGE_REL_FILE} 
    echo "Build date: ${DATETIME}" >> ${IMAGE_REL_FILE} 
    chmod 0444 ${IMAGE_REL_FILE} 
} 

Take careful notice of the whitespace in the create_release_file; part of the ROOTFS_POSTPROCESS_COMMAND declaration.

We now have a new external layer containing a basic image recipe. Until now, we haven't done any testing of the layer. It is always a good idea to perform regular tests of your changes during development. We will perform an early test of our layer. In order to do this, we will create a new project, set up some mandatory and good-to-have configurations in local.conf, and add external layers to bblayers.conf. This project will then be used throughout the chapter.

$ source /path/to/poky/oe-init-build-env packt_project_chapter12

Add the meta-raspberrypi and meta-oe external layers, together with our new meta-packt-iot layer, to bblayers.conf:

BBLAYERS ?= " 
/path/to/poky/meta 
/path/to/poky/meta-poky 
  /path/to/poky/meta-yocto-bsp 
/path/to/meta-raspberrypi 
  /path/to/meta-openembedded/meta-oe 
  /path/to/meta-packt-iot 
  "

Decide which machine to use and add it to local.conf. In this example, we will use raspberrypi2:

$ echo "MACHINE = "raspberrypi2"" >> conf/local.conf

We will next enable a local package revision (PR) server in our project. The PR server will automatically bump the PR of a package if a change is detected. This will be done without a need for the end user, to manually update the PR number in the recipe file. This feature is very handy during, for example, the development of new recipes:

$ echo "PRSERV_HOST = "localhost:0"" >> conf/local.conf

A project in BitBake can consume a lot of disk space. There exist a number of methods that can be used to reduce both the amount of disk space used by a project and its overall build time.

The first method is to use rm_work. This feature will make sure that BitBake performs a full cleanup of packages that have been built. By default, all built packages will have source and artifacts saved in package-specific locations, under ./tmp/work in the project. These will be wiped when the following class is inherited for the project:

$ echo "INHERIT += "rm_work"" >> conf/local.conf

However, it might be good to exclude packages that are frequently used during development, especially if it takes a long time unpack them. To achieve this, RM_WORK_EXCLUDE can be used.

The build time for a project is often quite long, especially the first time, since BitBake needs to fetch all source and build packages from scratch. But after the first build is done, you can use a number of methods to speed up subsequent builds. These methods can also be used in other Yocto projects with a similar setup to decrease the build time and amount of disk space needed. The first method is to use a shared state (sstate). By default, the sstate cache is located within the project. But by using the SSTATE_DIR variable in local.conf, the shared state can be located outside of a project and be used by other projects as well. The same goes for the next method, which is specifying the download location for all packages fetched by BitBake during the build. It can also be configured from local.conf using the DL_DIR variable. In this example, we will not use a shared state or a download directory outside of our project. The reason for this is that it isn't recommended when using a local PR server.

At this point, your local.conf file should look something like this:

$ tail conf/local.conf
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
#ASSUME_PROVIDED += "libsdl-native"
# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"
MACHINE = "raspberrypi2"
PRSERV_HOST = "localhost:0"
INHERIT += "rm_work"

When the project has its initial configuration in place, we can build the image created earlier in this chapter:

$ bitbake packt-iot-image                                   
Parsing recipes: 100% |#########################################################################################################| Time: 00:00:31
Parsing of 895 .bb files complete (0 cached, 895 parsed). 1325 targets, 68 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Let's try our new image on the target. In this state, the image should behave similarly to a normal rpi-basic-image image. It's always good to not only build our changes but also test them on the target in order to ensure that nothing gets broken along the road. Use the method described in Chapter 2, Building our First Poky Image for the Raspberry Pi to copy the image to an SD card (remember to change /dev/sdX to the proper device name):

$ sudo dd if=/path/to/packt_project_chapter12/tmp/deploy/images/raspberrypi2/packt-iot-image-raspberrypi2.rpi-sdimg of=/dev/sdX bs=1M

Next, insert the SD card into the Raspberry Pi and power it on. The image doesn't contain any big changes from rpi-basic-image; still, we can easily see that we are running the correct image. As you might remember, we added a post function in the image recipe, which added a release file. Let's check whether it exists and check the content (log in using root and an empty password):

Poky (Yocto Project Reference Distro) 2.0+snapshot-20160229 raspberrypi2 /dev/ttyAMA0
raspberrypi2 login: root
root@raspberrypi2:~# ls /etc/*release*
/etc/packt-iot-release
root@raspberrypi2:~# cat /etc/packt-iot-release 
packt-iot release version 1.0
Image: packt-iot-image-raspberrypi2-20160304085812
Build date: 20160304085812
root@raspberrypi2:~#