Poky provides several pre-designed image recipes that we can use to build our own binary image. We can check the list of available images by running the following command from the poky directory:

$ ls meta*/recipes*/images/*.bb

All the recipes provide images that are, in essence, sets of unpacked and configured packages, generating a filesystem that we can use on actual hardware (for further information about different images, you can visit ( http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-images ).

Next, here's a brief representation of available images:

We can add the layers proposed by meta-raspberry to all of these layers:

$ ls meta-raspberrypi/recipes-core/images/*.bb
rpi-basic-image.bb
rpi-hwup-image.bb
rpi-test-image.bb

We will choose one of these three recipes for the rest of this chapter. Note that these files (.bb) describe recipes, like all the others. These are organized logically, and here, we have the ones for creating an image for the Raspberry Pi.

At this point, we need to start BitBake, the build engine, which will parse all the recipes that contain the image you pass as a parameter (for our first example, we can take rpi-basic-image):

$ bitbake rpi-basic-image

Loading cache: 100% 
|########################################################################################################################################################################| ETA:  00:00:00
Loaded 1352 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.25.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-14.04"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "raspberrypi"
DISTRO = "poky"
DISTRO_VERSION = "1.7"
TUNE_FEATURES = "arm armv6 vfp"
TARGET_FPU = "vfp"
meta
meta-yocto 
meta-yocto-bsp = 
"master:08d3f44d784e06f461b7d83ae9262566f1cf09e4"
meta-raspberrypi = 
"master:6c6f44136f7e1c97bc45be118a48bd9b1fef1072"
NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks

Once launched, Bitbake begins by browsing all the files (.bb, .bbclass) that the environment provides access to and storing the information in a cache.

While the parser of Bitbake is parallelized, the first execution will always be longer (only by about a few seconds) because it has to build the cache. However, subsequent executions will be almost instantaneous because Bitbake load the cache. As we can see from the previous command, before executing the task list, Bitbake displays a trace that details the versions used (target, version, OS, and so on). And finally, Bitbake starts the execution of the tasks and displays the progress.

Depending on your setup, you can go drink some coffee or even eat some pizza. Usually, after this, if all goes well, you will be pleased to find that the tmp/ sub directory's directory construction (rpi-build) is generally populated. The build directory (rpi-build) contains about 20 GB after the creation of the image.

After a few hours of baking, we can rejoice with the result and the creation of the system image for our target:

$ ls rpi-build/tmp/deploy/images/raspberrypi/*sdimg
rpi-basic-image-raspberrypi.rpi-sdimg

It is this file that will serve us to create our bootable SD card.

Now that your environment is complete, you can create an SD card with the following command (remember to change /dev/sdX to the proper device name and be careful not to kill your hard disk by selecting the wrong device name):

$ sudo dd if=rpi-basic-image-raspberrypi.rpi-sdimg of=/dev/sdX 
bs=1M

Once the copying is complete, you can check whether the operation was successful using the following command (see mmcblk0):

$ lsblk 
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0   3,7G  0 disk 
├─mmcblk0p1 179:1    0    20M  0 part  
/media/packt/raspberrypi
└─mmcblk0p2 179:2    0   108M  0 part /media/packt/f075d6df-d8b8-4e85-a2e4-36f3d4035c3c

You could also look at the left-hand side of your interface: