OpenEmbedded: Building
Building an image
Change your working directory to the Bluetechnix overlay:
robert@bltLinux:~/oe$ cd btmxc robert@bltLinux:~/oe/btmxc$ ls conf oeenv
There you see an oeenv file, source it – it will set up everything needed for working with this overlay (mind the space between "." and oeenv):
robert@bltLinux:~/oe/btmxc$ . oeenv robert@bltLinux:~/oe/btmxc$
If you got your own copy of BitBake and you installed it in oe/bitbake/, you may also source the bitbakeenv file. It will add BitBake's path to your $PATH. (Note that you have to do this step after sourcing oeenv, because oeenv sets the OEBASE variable.)
robert@bltLinux:~/oe/btmxc$ . bitbakeenv robert@bltLinux:~/oe/btmxc$
Everytime you execute bitbake you should be in this directory.
Now lets build our first image. Note that we use blt-image generically here. You have to use the correct image name for your board according to the list below.
robert@bltLinux:~/oe/btmxc$ bitbake blt-image NOTE: Handling BitBake files: \ (6638/6638) [100 %] NOTE: Parsing finished. 6345 cached, 0 parsed, 293 skipped, 0 masked. NOTE: Cache is clean, not saving. NOTE: build 200904142114: started OE Build Configuration: BB_VERSION = "1.8.12" METADATA_BRANCH = "stable/2009" METADATA_REVISION = "13e3e087e4d45555ee29caf09576961db9e5f30e" TARGET_ARCH = "arm" TARGET_OS = "linux-gnueabi" MACHINE = "btmxc31" DISTRO = "angstrom" DISTRO_VERSION = "2009.X-test-20090414" TARGET_FPU = "hard" NOTE: Resolving any missing task queue dependencies ...
The first compilation of an image will take a while since it will build everything starting from the cross tool chain and ending with the root file system.
Afterwards you can find the image ready at /oe/btmxc/tmp/deploy/glibc/images/sbc-imx51/blt-image (Last part may verify, depending on the machine for which you are compiling and the image name.)
Images for Bluetechnix hardware
We provide recipes for one or more demo images in our OpenEmbedded repo for each module. Images are contained in oe/openembedded/recipes/images/.
- SBC-i.MX51
- sbc-imx51-console-image.bb
- sbc-imx51-qtembedded-image.bb
- sbc-imx51-gnome-image.bb
- CM-i.MX27 with DEV-i.MX27/35
- btmxc27-image.bb
- CM-i.MX35 with DEV-i.MX27/35
- btmxc35-image.bb
(To compile, don't enter the ".bb" suffix, e.g. bitbake sbc-imx51-gnome-image.)
A little script for setting up NFS file system
After building, the complete image (compressed archive) is saved in oe/btmxc/tmp/deploy/glibc/images/[machine]/[image name].[archive type], e.g.
harald@WS-HP4600-35:~/imx/oe/btmxc/tmp/deploy/glibc/images/i.fly$ ls -l ifly* lrwxrwxrwx 1 harald harald 62 2009-12-21 10:15 ifly-image-i.fly.jffs2 -> Angstrom-ifly-image-glibc-ipk-2009.X-stable-i.fly.rootfs.jffs2 lrwxrwxrwx 1 harald harald 64 2009-12-21 10:17 ifly-image-i.fly.tar.bz2 -> Angstrom-ifly-image-glibc-ipk-2009.X-stable-i.fly.rootfs.tar.bz2 lrwxrwxrwx 1 harald harald 63 2009-12-21 10:17 ifly-image-i.fly.tar.gz -> Angstrom-ifly-image-glibc-ipk-2009.X-stable-i.fly.rootfs.tar.gz
To be able to access kernel and file system easily from your target, here is a little script (for btmxc27) that
- copies the kernel image to /tftpboot
- extracts the file system image to a directory
#!/bin/sh
sudo rm -rf ${OEBASE}/btmxc/tmp/deploy/glibc/images/i.fly/rootfs #delete old directory
cd ${OEBASE}/btmxc/tmp/deploy/glibc/images/i.fly
mkdir rootfs
cd rootfs
sudo tar -xvjf ../ifly-image-i.fly.tar.bz2 #unpack (you need root permissions!)
cd ..
cp zImage.bin /tftpboot/zImage #copy kernel image
cd ${OEBASE}/btmxc/
In your /tftpboot, you should have a symbolic link to the newly created rootfs directory. We explain that [here].
Target network setup
Network setup is configured in the file /etc/network/interfaces in your rootfs. The default network setup for Ethernet (eth0) is set to DHCP:
auto eth0 iface eth0 inet dhcp
To set a fixed IP address, you may modify the lines above as follows:
auto eth0 iface eth0 inet static address 192.168.0.53 netmask 255.255.255.0 gateway 192.168.0.1 broadcast 192.168.0.255
IMPORTANT! If you are mounting the rootfs via NFS, you MUST NOT configure eth0 at all in the configuration file, so comment the lines
#auto eth0 #iface eth0 inet dhcp
The reason is that the Linux kernel - in case of NFS - must configure the network before this file can even be read. This is done via kernel arguments (see Loading Linux: in the Redboot short reference). If the network would be configured later again, the connection to the NFS server is interrupted!
Troubleshooting
- Invalid MD5 sum
- If the build fails because of an invalid md5 sum, run the fetch task on the recipe causing this error, then build again. The re-fetch might solve the problem.
- Package fails to build
- In case a package fails to build, run the clean task on it, then build again. E.g.
bitbake -c clean packetname bitbake failed-image
- If the problem persists, you may try disabling concurrent building by editing btmxc/conf/local.conf. PARALLEL_MAKE defines a flag to the compiler GCC and gives the number of parallel make threads. BB_NUMBER_THREADS decides how many threads bitbake will start.
#PARALLEL_MAKE = "-j 4" PARALLEL_MAKE = "-j 1" #BB_NUMBER_THREADS = "2" BB_NUMBER_THREADS = "1"