2. Building and installing images

2.1. Building images

2.1.1. Stamp9G20/PortuxG20

After setting up the build environment, you can start to build images. The smallest image you can build is the helloworld-image. It contains just a statically linked helloworld application, which is started on boot and then hangs forever. This is a good test to see, if your environment is setup correctly.

bitbake helloworld-image

Although the image is simple, it will take a while until it is ready, because the toolchain will be built first. This can take some hours if you have a slow system. The following builds will not take so long, as the toolchain will then be built already (unless you wipe the tmp directory).

As a next step you could built the base-image. It contains everything needed to boot the target board.

bitbake base-image

When the command is finished, you can find the image in the directory /develop/oe/tmp/deploy/glibc/images/machine. Replace machine with the machine you set in the local.conf.

If everything worked as expected, you can try to build default image, that came preloaded with your product. It is called taskit-image. Before you try to build it, you have to add some lines to your local.conf:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"
PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_PROVIDER_classpath = "classpath"

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_jamvm = "1.5.0"

PREFERRED_VERSION_classpath = "0.97.2"
PREFERRED_VERSION_classpath-minimal = "0.97.2"
PREFERRED_VERSION_classpath-native = "0.97.2"
PREFERRED_VERSION_classpath-initial = "0.93"

They are needed, because the taskit-image contains jamvm and classpath and without the correct version numbers, the build might fail. These are the settings we used for building the image. If they do not work for you, see http://wiki.openembedded.net/index.php/Java#Version_suggestions for further information.

If you only use devices without a screen, you can replace

PREFERRED_PROVIDER_classpath = "classpath"

with

PREFERRED_PROVIDER_classpath = "classpath-minimal"

This leaves out all graphical components of classpath and thereby improves build times.

2.1.2. Stamp9G45

A small image to try at first, is the core-image-minimal. If it builds without errors, you can be sure everything is set up correctly:

bitbake core-image-minimal

Now you could also try to build the taskit-demo-image but this will take some more time as it includes QtEmbedded:

bitbake taskit-demo-image

The bootloader can also be built using OpenEmbedded Core. In case of the Stamp9G45 which uses a Linux based loader with an initramfs, you have to switch to uclibc mode so that the initramfs is small compared to an eglibc version:

TCLIBC=uclibc bitbake virtual/bootloader

2.2. Installing images

After finishing the build, you will get a standard kernel image and two file system images (jffs2 and tar) in the directory /develop/oe/tmp/deploy/glibc/images/stamp9g20evb. There will also be symlinks to each file with a shorter name, e.g.

  • uImage-stamp9g20evb.bin

  • taskit-image-stamp9g20evb.jffs2

  • taskit-image-stamp9g20evb.tar

For the Stamp9G45, the corresponding images will appear in the tmp-eglibc/deploy/images/stamp9g45/ subdirectory.

2.2.1. Installing on an SD card

Before flashing the rootfs into the integrated flash, we will test the system on an SD card. For this, you need an SD card with at least one partition. We will assume, that your SD card is accessible as device /dev/sdb and you have a directory /media/card. Additionaly you have to have root rights to proceed with the following steps.

[Caution]Caution

Make sure, that you use the correct device file or you will lose data.

The first thing to do is to format the first partition of the SD card with the ext3 file system:

mkfs.ext3 /dev/sdb1

All data on this partition will be lost.

Now it should be mounted to /media/card:

mount /dev/sdb1 /media/card

You can now extract the files to SD card. Enter the directory /develop/oe/tmp/deploy/glibc/images/stamp9g20evb and use the following command:

tar -xvf taskit-image-stamp9g20evb.tar -C /media/card

Finally, unmount the SD card:

umount /media/card

If you remove the SD card now and place it into the SD card slot of the target board, you can boot the system from the U-Boot prompt with the following command:

run sdboot

[Important]Important

Do not simply switch off the board when the SD card is mounted read-write (default). The ext3 file system is not made for power loss situations. Use the halt command and wait until

Power down.

can be read on the serial console.

2.2.2. Installing on internal flash

When you have tested the root file system on the SD card, you can write the jffs2 version to the internal flash. Because the jffs2 is mounted during the time, Linux is booted, you cannot easily replace it from within Linux. There are ways, but there are a bit complicated and unsafe. Therefore it is better to flash it from U-Boot or the newly created SD card.

In this section we will use the SD card to write the rootfs to the flash memory.

To write the jffs2 image to the flash memory, you obviously need the image accessible on the target board. Either copy it to SD card or mount your development directory via NFS.

Before you flash the image, you have to identify the correct MTD-Partition like in Chapter 6, Compiling a new Linux kernel

cat /proc/mtd

You should get something like this:

dev:    size   erasesize  name
mtd0: 00020000 00020000 "bootstrap"
mtd1: 00040000 00020000 "uboot"
mtd2: 00020000 00020000 "env1"
mtd3: 00020000 00020000 "env2"
mtd4: 00200000 00020000 "linux"
mtd5: 1fd60000 00020000 "root"

The image must be written to the partition with the name root, in this case it is /dev/mtd5.

First, erase the partition completely.

flash_eraseall -j /dev/mtd5

The -j is used to indicate, that a jffs2 image will be written to the partition. It will put a so-called CLEANMARKER into each flash block. Jffs2 uses them to test, if the last erase operation was correctly completed. If it is missing, jffs2 will erase the block again on the first mount resulting in a unneeded double erase.

Now enter the directory containing the jffs2 image. Depending on the type of flash, use either

nandwrite /dev/mtd5 taskit-image-stamp9g20evb.jffs2

for NAND flash or

flashcp -v taskit-image-stamp9261evb.jffs2 /dev/mtd5

for NOR flash.

The jffs2 image is now written to the flash and can be used on next boot with the U-Boot command

run flashboot