Skip to main content.

4. Frequently Asked Questions (and Answers)

Installation

Installation directory cannot be renamed

Question:
After installation I decided to rename the installation directory, resp. moved it to another path. Unfortunately, ELDK stopped working.
Answer:
It is important to keep in mind that the tool chain is not dynamically relocatable, but relocation (adaption of the builtin path names to the installation directory path) is a special part of the installation procedure. If you need to rename a directory or so you have to reinstall into the new path.

Installation in other directory (ELDK v5.2.x and older only)

Question:
I cannot install the ELDK into it's default directory "/opt/eldk-5.0". I installed it in another directory, but it doesn't work. Why?
Answer:
The ELDK 5.0 tools are linked against their own set of shared libraries. This makes them highly independent from the actual host environment. One unfortunate side-effect of this is that they are not relocatable. To run them, they must be seen by the OS under their predefined path.

There are several ways how this can be achieved. You can for example use symbolic links or bind mounts (globally visible for all users) or name spaces (may be used on a per-process base), etc. However, this can be confusing for inexperienced users, so we recommend to install into the standard location and avoid the trouble.

Note: this has been fixed with ELDK v5.3 and later.

Installation of several target configurations

Question:
I would like to install both the GNOME Mobile and the Qt Embedded configurations, but it doesn't work.
Answer:
You can do this, but you have to install the second (and any other) configuration into alternative directories. See also question Installation in other directory.

Tool Chain

GCC does not generate floating point instructions

Question:
When using the tools for the armv7a target I noticed that the compiler generates soft-float code instead of using the FPU.
Answer:
This behavior appears to be common practice for GCC on ARM. If you want to use real floating point instructions, you must use appropriate compiler flags, like "-mfpu=vfp -mfloat-abi=softfp".

Note: There is a script "environment-setup--linux-gnueabi" in each of the "/opt/eldk//" directories. Sourcing this script in your shell will provide a number of useful settings, including the CFLAGS environment variable:
$ . /opt/eldk-5.0/armv7a/environment-setup-armv7a-linux-gnueabi 
$ echo ${CFLAGS}
-march=armv7-a -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize --sysroot=/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi
We are aware that older versions of the ELDK behaved differently, but as mentioned the current behavior is considered standard for GCC on ARM.

How can I use the QtEmbedded target configuration with Qt Creator?

Question:
Im using Qt Creator for development. How can I use this with the ELDK 5.0 QtEmbedded target configuration?
Answer:
The QtEmbedded target configuration provides all required environment settings so you should be able to build Qt programs as easy as just running
$ source /opt/eldk-5.0/<arch>/environment-setup-<arch>-linux-gnueabi
$ qmake
$ make
Qt creator actually creates *.pro file suitable for qmake so one can also use these commands to build generated projects.

Here is an example using the qttest.tar.gz QtEmbedded test code:
$ tar xzvf ~/qttest.tar.gz
qttest/
qttest/main.cpp
qttest/mainwindow.cpp
qttest/qttest.pro
qttest/mainwindow.ui
qttest/mainwindow.h
qttest/qttest.pro.user
$ cd qttest/
$ .  /opt/eldk-5.0/armv7a/environment-setup-armv7a-linux-gnueabi
$ qmake
$ make
/opt/eldk-5.0/armv7a/sysroots/x86_64-oesdk-linux/usr/bin/uic4
mainwindow.ui -o ui_mainwindow.h
arm-linux-gnueabi-g++ -c -pipe   -Wall -W -D_REENTRANT -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi/usr/share/qtopia/mkspecs/linux-g++
-I.
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtCore
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtGui
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia
-I. -I. -o main.o main.cpp
arm-linux-gnueabi-g++ -c -pipe   -Wall -W -D_REENTRANT -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi/usr/share/qtopia/mkspecs/linux-g++
-I.
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtCore
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtGui
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia
-I. -I. -o mainwindow.o mainwindow.cpp
/opt/eldk-5.0/armv7a/sysroots/x86_64-oesdk-linux/usr/bin/moc4
-DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi/usr/share/qtopia/mkspecs/linux-g++
-I.
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtCore
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtGui
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia
-I. -I. mainwindow.h -o moc_mainwindow.cpp
arm-linux-gnueabi-g++ -c -pipe   -Wall -W -D_REENTRANT -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi/usr/share/qtopia/mkspecs/linux-g++
-I.
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtCore
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia/QtGui
-I/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/include/qtopia
-I. -I. -o moc_mainwindow.o moc_mainwindow.cpp
arm-linux-gnueabi-g++
-Wl,-rpath-link,/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/lib
-o qttest main.o mainwindow.o moc_mainwindow.o
-L/opt/eldk-5.0/armv7a/sysroots/arm-linux-gnueabi//usr/lib -lQtGuiE
-lQtNetworkE -lQtCoreE -lpthread
$ file qttest
qttest: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
$
Uh.. Sorry, long lines wrapped.

Cannot compile Linux kernel version 2.6.32 for armv7a

Question:
I want to compile a vendor-provided old Linux kernel tree (kernel version 2.6.32) with ELDK 5.0 for the armv7a configuration. Unfortunately this fails with errors like this one:
 ...
  CC      arch/arm/kernel/sysfs_v7.o
/tmp/ccwkv7On.s: Assembler messages:
/tmp/ccwkv7On.s:249: Error: selected processor does not support ARM mode `smc #0'
/tmp/ccwkv7On.s:289: Error: selected processor does not support ARM mode `smc #0'
make[1]: *** [arch/arm/kernel/sysfs_v7.o] Error 1
Answer:
Your kernel tree is too old for the ELDK 5.0 tool chain. You can work around this problem by applying the following patch to your kernel tree:
--- arch/arm/kernel/sysfs_v7.c.ORIG   2011-01-27 11:47:54.000000000 +0100
+++ arch/arm/kernel/sysfs_v7.c   2011-05-10 08:51:58.953252638 +0200
@@ -76,7 +76,8 @@
    asm ("mrc p15, 0, %0, c1, c0, 1" : "=r"(val));
    SETBITS(val, 0xff8, new);
    val &= ~2;
-   asm ("mov r0,  %0   \n\t"
+   asm (".arch_extension sec\n\t"
+        "mov r0,  %0   \n\t"
         "mov r12, #3   \n\t"
         "smc #0      \n\t"
         :: "r"(val) : "r0", "r12");
@@ -107,7 +108,8 @@
 
    asm ("mrc p15, 1, %0, c9, c0, 2" : "=r"(val));
    SETBITS(val, 0xbc00000, new);
-   asm ("mov r0,  %0   \n\t"
+   asm (".arch_extension sec\n\t"
+        "mov r0,  %0   \n\t"
         "mov r12, #2   \n\t"
         "smc #0      \n\t"
         :: "r"(val) : "r0", "r12");

GCC generates illegal opcodes for ARMv4T systems

Question:
I use the armv5te configuration to build U-Boot for a AT91RM9200 base system, but the resulting code does not run on the target board. Closer inspection reveals that it crashes with illegal instructions.
Answer:
The problem comes from the fact that ELDK was configured for the ARMv5TE architecture, while the AT91RM9200 uses a ARM920 core, i. e. it belongs to the ARM9TDMI family, ARMv4T architecture. The U-Boot Makefiles take mostly care of this by using the correct "-march=armv4" compiler options, but without special provisions GCC will link in his own libgcc support routines - and these have been built for ARMv5TE, so they contain for example "clz" instructions which are only available in ARM architecture versions 5 and above.

To avoid such problems you must make sure that U-Boot also builds it's own version of the libgcc library routines using the needed compiler flags. This can be achieved by setting the environment variable "USE_PRIVATE_LIBGCC=yes" before running the build, for example like this:
$ USE_PRIVATE_LIBGCC=yes make at91rm9200ek_config
$ USE_PRIVATE_LIBGCC=yes make all
Please see the U-Boot documentation for details.

Note: This method works only with software packages that are self-contained (like for example U-Boot or the Linux kernel), i. e. that do not link against any system libraries. It does not work for normal user space application code etc.

The recommended solution is of course to use the ARMv4T configuration of ELDK instead.

The glibc function "backtrace(3)" on ARM does not work

Question:
I want to use the "backtrace" function on ARM with ELDK 5.x but the function yields no stack frames. The same program works with ELDK 4.2.
Answer:
You need to compile the relevant sources with "-funwind-tables" for ARM CPUs to make it work. This seems to be undocumented in glibc.

Difference between ${CROSS_COMPILE}gcc and ${CC} ?

Question:
I assumed there was no differnce between the invocation of the cross compiler as ${CROSS_COMPILE}gcc (as documented in the DULG or with eldk-switch ) versus as ${CC} (after sourcing the "environment-setup-*" script). However, there appear to be subtle differences?
Answer:
With the Yocto 1.3 release, a number of compiler options and similar settings were moved from the CFLAGS environment variable into the definition of the compiler name, CC ; ELDK inherited these changes, like this:

ELDK v5.2.1:
CC=powerpc-linux-gcc
CFLAGS=" -m32 -mhard-float --sysroot=/opt/eldk-5.2.1/powerpc/sysroots/powerpc-linux"
ELDK 5.3:
CC="powerpc-linux-gcc  -m32 -mhard-float --sysroot=/opt/eldk-5.3/powerpc/sysroots/powerpc-linux"
CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types"
This is somewhat unconventional and may cause problems when used incautiously.

In any case, make at least sure to use the correct "--sysroot..."= setting.

Target Environment

Touch screen calibration does not work on Twister board

Question:
When I run the "ts_calibrate" command to calibrate my touch screen, I get a "selected device is not a touchscreen I understand" error message and all bogus results. I'm using a TAM3517 "Twister" board with the vendor provided (out-of-tree) Linux kernel.
Answer:
The vendor-provided Linux kernel is simply too old. The touch driver returns a version ID which is not accepted by the relatively recent version of the tslib code as inlcuded with ELDK 5.0. To work around this, you can apply this simple patch to the touch driver in your kernel tree:
diff --git a/include/linux/input.h  b/include/linux/input.h
--- a/include/linux/input.h   2011-01-27 11:48:07.000000000 +0100
+++ b/include/linux/input.h   2011-05-31 11:46:40.252656416 +0200
@@ -34,7 +34,7 @@
  * Protocol version.
  */
 
-#define EV_VERSION      0x010000
+#define EV_VERSION      0x010001
 
 /*
  * IOCTLs (0x00 - 0x7f)

"getty: ioctl() TIOCSPGRP call failed" console messages

Question:
I'm getting the following messages printed before the login prompt:
getty: ioctl() TIOCSPGRP call failed: Inappropriate ioctl for device
What is wrong?
Answer:
When configuring the ELDK, we cannot know which board it will be used on, so we do not know the correct name for the console device. To provide a generic configuration, the file "/etc/inittab" contains the following entry:
S:2345:respawn:/sbin/getty 115200 console
This means that "/dev/console" gets used for the console login. This works, but not perfectly: the console driver does not support some operation needed here.

To fix, please find out which exact device is used as serial console port on your board, and replace the string "console" in above entry in "/etc/inittab" by the name of your real console device. For example, if you are running on a MPC5200 based system, and your console device is "/dev/ttyPSC0", then change "/etc/inittab" like this:
-S:2345:respawn:/sbin/getty 115200 console
+S:2345:respawn:/sbin/getty 115200 ttyPSC0

"-sh: no job control in this shell" console messages

Question:
When loggin in, the following error messages are printed:
-sh: cannot set terminal process group (-1): Inappropriate ioctl for device
-sh: no job control in this shell
If I type ^C to interrupt a running process, this does not work either. How can I fix this?
Answer:
The cause for this problem is most likely the same as for the "getty: ioctl() TIOCSPGRP call failed" problem above - and the fix is also the same: please change "/etc/inittab" and use your real console device name for login.

"respawning too fast" console messages

Question:
I'm getting the following messages printed on the console:
INIT: Id "1" respawning too fast: disabled for 5 minutes
How can I fix this?
Answer:
The cause of the problem is that you appear to be running a Linux kernel which has no support for virtual terminals in it's configuration (CONFIG_VT configuration option). In the result, attempts to run a login process on virtual terminal tty1 will fail. To prevent the error messages, comment out the related entry in the "/etc/inittab" file in your root file system:
--- etc/inittab.ORIG        2011-12-02 13:33:33.317276339 +0100
+++ etc/inittab     2011-12-02 13:33:53.255592549 +0100
@@ -38,5 +38,5 @@
 #  <id>:<runlevels>:<action>:<process>
 #
 
-1:2345:respawn:/sbin/getty 38400 tty1
+#1:2345:respawn:/sbin/getty 38400 tty1
 

Missing Device Files for Cold Plugged Devices

Question:
When I hot-plug a USB stick in a running system it gets detected and the corresponding device files get created, so I can for example mount partitions on a USB stick. But when the USB device is already attached when the system boots, no device files get created for it, even though the Linux kernel properly detects it as can be seen from the boot messages, like for example:
scsi 0:0:0:0: Direct-Access     JetFlash Transcend 8GB    8.07 PQ: 0
ANSI: 2
sd 0:0:0:0: [sda] 15654912 512-byte logical blocks: (8.01 GB/7.46 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI removable disk
What can I do to make cold plugging work as expected?
Answer:
This behavior is caused by a feature called "udev-cache" which tries to speed up the boot process by caching the "/dev" contents: it creates an archive "/etc/dev.tar" on the first boot and, if this archive exists during the next boot, it gets extracted and most of the coldplug events are filtered. Only if the archive does not exist a full scan is performed.

This seems to be a good solution for a root file system used inside a typical embedded device with a static configuration, as scanning for cold plug events is known to be slow, but it does not work so well in a setup where the configuration can change for each reboot.

As a workaround you just need to remove the "/etc/dev.tar" file from the root file system.

A permanent fix would be to disable this functionality for the ELDK. It is provided by the "udev-cache" package so we could just skip it's installation. With opkg (as used with ELDK starting with release 5.2) we can just add an entry
BAD_RECOMMENDATIONS = "udev-cache"
to the "meta-eldk/conf/distro/eldk.conf" file and rebuild. This should do the trick.

Note that this is not so easy when using RPM packages: "udev-cache" is marked as "recommended" by the main "udev" package, and RPM treats such "recommends" as dependencies.

Working with Packages

List installed packages

Question:
How can I find out which software packages are installed in a root file system image, and what their versions are?
Answer:
ELDK 5.1 and later uses "ipk" packages for software package management. To get an overview over the installed packages use a command like this:
$ sudo $(type -p opkg-cl) -o /opt/eldk-5.1/powerpc/rootfs-sato-sdk list
[sudo] password for ...: 
acl - 2.2.51-r2
acl-dev - 2.2.51-r2
alsa-conf-base - 1.0.24.1-r0
alsa-lib - 1.0.24.1-r0
alsa-lib-dev - 1.0.24.1-r0
alsa-utils-amixer - 1.0.24.2-r2
alsa-utils-aplay - 1.0.24.2-r2
attr - 2.4.46-r2
attr-dev - 2.4.46-r2
autoconf - 2.68-r2
autoconf-dev - 2.68-r2
automake - 1.11.1-r4
automake-dev - 1.11.1-r4
avahi - 0.6.30-r7.0
avahi-daemon - 0.6.30-r7.0
avahi-dev - 0.6.30-r7.0
base-files - 3.0.14-r69
base-files-dev - 3.0.14-r69
base-passwd - 3.5.22-r3
base-passwd-dev - 3.5.22-r3
...
Use "opkg-cl --help" to get an overview over the available commands.

Install additional packages

Question:
How can I install additional software packages into my root file system?
Answer:
On the development host you can use some command like this:
$ sudo $(type -p opkg-cl) -o /opt/eldk-5.1/armv5te/rootfs-qte-sdk install /tmp/*.ipk
The same (without the "-o" option) can be done on the target.

Find package name for given file

Question:
How can I find out which package a specific file belongs to? For example, which package provides "/lib/libc-2.16.so" ?
Answer:
On the development host you can use some command like this:
$ sudo $(type -p opkg-cl) -o /opt/eldk-5.3/armv7a/rootfs-sato-sdk search /opt/eldk-5.3/armv7a/rootfs-sato-sdk/lib/libc-2.16.so
libc6 - 2.16-r15+svnr20393

Customization and Advanced Usage

Extending the Cross Development Environment

Question:
I have been trying to compile the FreeSWITCH package, but this failed with "openssl/crypto.h not found" errors. How can I add the missing header files to the cross development environment?
Answer:
This problem boils down to the question which packages are included in the tool chain (actually in its "sysroot" directory), and if there is an easy way to add to that.

Here is an example - first, we try a native build on the x86 development host:
[dzu@pollux openssl]$ gcc -Wall -lssl -lcrypto -o ssl-demo ssl-demo.c
[dzu@pollux openssl]$ 
So the native compilation works fine. Now try the ELDK cross tool chain (here for armv7a):
[dzu@pollux openssl]$ eldk-switch -r 5.3 armv7a
Setup for armv7a (using ELDK 5.3)
dzu@pollux openssl]$ ${CROSS_COMPILE}gcc -Wall -lssl -lcrypto -o ssl-demo ssl-demo.c
ssl-demo.c:11:26: fatal error: openssl/rand.h: No such file or directory
compilation terminated.
That's the same problem - the SSL header files (and libraries) are missing in the (sato) SDK image.

The files are, however, included in the development software packages, so if you have access to the openssl-dev ipkg file, you can use this and addd it to the tool chain. This can be done as follows:
[dzu@pollux openssl]$ type opkg-cl
opkg-cl is /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/opkg-cl
Now we know the path for native "opkg-cl" tool. We use this information like that:
[dzu@pollux openssl]$ sudo /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/opkg-cl --force-depends -o /opt/eldk-5.2/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/ -f /opt/eldk-5.2/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/etc/opkg.conf install /tmp/openssl-dev_1.0.0j-r15.3_armv7a-vfp-neon.ipk
[sudo] password for dzu: 
Upgrading openssl-dev on root from 1.0.0h-r15.1 to 1.0.0j-r15.3...
openssl-dev: unsatisfied recommendation for libssl-dev
openssl-dev: unsatisfied recommendation for libcrypto-dev
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for openssl-dev:
 * openssl (= 1.0.0j-r15.3) * 
Note that the "-o" option to opkg-cl is needed to tell it the location of the sysroot directory it should install into. One also needs to specify "-f" with the corresponding opkg.conf file (otherwise it will find a config file that does not specify armv7a architecture for packages). Maybe somewhere in the future these options are compiled in as default into the opkg-cl binary, but until then the command line will be long, sorry. For this example we also override the dependency check just to show that the package can be installed.

Now we can rety the software build:
[dzu@pollux openssl]$ ${CROSS_COMPILE}gcc -Wall -lssl -lcrypto -o ssl-demo ssl-demo.c 
[dzu@pollux openssl]$ 
Voila, it works!

Now for the more problematic facts of this procedure - the .ipk files are currently not hosted on our ftp server as this would use up too much disk space for all thearchitectures, so you need to generate this yourself by compiling the eldk from scratch (see EldkBuilding).

It is also neccessary that the packages generated fit the toolchain tarball as the sysroot hierarchy in the toolchain contains an opkg "packages" file with md5sums of the package files. If those things do not match, you will see something like this:
Collected errors:
   * opkg_install_pkg: Package openssl-dev md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.
   * opkg_install_cmd: Cannot install package openssl-dev.

Using ELDK v5.x with Eclipse

Question:
How can I use ELDK v5.x with the Eclipse IDE?
I have read about the Yocto Eclipse IDE Plug-In, but even when following exactly the steps explained in the Instructional Video it doesn't work for me: the settings made for "Toolchain Root Location" and "Sysroot Location" will not be accepted. Is there a way to use ELDK v5.x with Eclipse?
Answer:
Yes, you can use the Yocto Eclipse IDE Plug-In, but you have to apply this patch . Please note that this patch was taken against the "master-indigo" branch of the plugin.

Customized File System Images

Question:
What is the best way to adjust the functionality of the provided root file system images to our requirements? For example, I would just like to add packages FOO and BAR to the core-image-minimal image.
Answer:
If you only want to make such minor modifications, like adding a few additional packages, you can use the HOB image builder, i. e. a graphical user interface for BitBake.

If you have built the ELDK from the sources, it is most efficient to re-use the existing build directory. Otherwise just chose any name for the build directory. The standard hints for ELDK Building apply. For example, to reuse the existing build directory for armv7a targets, set up the build environment like this:
$ source oe-init-build-env /opt/eldk/build/eldk-rel-v5.1-2011-12-11-a999e4a-armv7a
Then run the HOB image builder:
hob
Select the correct machine configuration (here: generic-armv7a) and base image (i. e. what you want to use as starting point to add packages to; here: core-image-minimal). Then scroll through the list of existing packages and/or package collections and check the "Include" button for those you want to add. when done, click on "Bake".
Yes, that's all.
Question:
Well, HOB is fine, but I need finer control, like selecting a specific version of the Linux kernel, specific configuration options, and my own application code which obviously is not listed in HOB. How can I do that?
Answer:
This is probably the point where you should add your own machine configuration to the build system. This gives you a complete system then for all your software productions.

Custom U-Boot and Linux kernel images

Question:
I downloaded and installed ELDK v5.2 for PowerPC e500v2, but I cannot find any U-Boot or Linux kernel images for my board. Where can I find these?
Answer:
There are no such ready-to-use board specific images. We call this target configuration "generic-powerpc-e500v2" - instead of configuring everything (including U-Boot, Linux kernel and device tree) for one specific machine (= board), we try to provide a configuration that is generic enough to be used with all boards deploying a PowerPC e500v2 core.

We can use a common Linux kernel image that works on a number of boards, but both the U-Boot image and the device tree blob have always to be built for a specific hardware or board - we cannot do this in the "generic-powerpc-e500v2" context of the ELDK where we do not even know which board you will be using.
Question:
So how can I build the U-Boot and Linux kernel images for my board?
Answer:
There are two ways to approach this target:
  1. Classic approach as used with ELDK 4.x and before: download the U-Boot source code (i. e., clone the git repository), and use the ELDK tool chain to configure and build the U-Boot image for your target board. Do the same for Linux to build at least the correct device tree blob, and usually it is also better to build you own, matching Linux kernel image.
  2. Use the ELDK 5.x environment as software build environment for your own specific needs. To do that, you would define your own MACHINE settings, so you can not only build customized images for U-Boot, Linux and the device tree, but also the complete root file system as needed on your target board.

    This is actually one of the major improvements of ELDK 5.x over the older ELDK releases: in the past, ELDK provided a tool chain, but to set up your software build environment, you were mostly on your own. Now with ELDK 5.x, ELDK brings you not only the cross tools and the target environment, but also a complete, sophisticated software production environment that can easily be extended and customized for your specific project needs.

    See for example the definition of the "enbw_cmc" Machine in the ELDK source tree (meta-eldk/conf/machine/enbw_cmc.conf) - this is not one of the "generic" configurations that tries to support all boards of a specific CPU family, but a custom configuration for one specific custom board. Building with MACHINE set to "enbw_cmc" will result in U-Boot and Linux kernel images, but also in a root file system image, all ready configured for installation on "enbw_cmc" boards.

ELDK 5.3 Known Issues and Workarounds

Compiling U-Boot or Linux fails with "unrecognized option" linker errors

Question:
When using the ELDK tools to compile the U-Boot or Linux kernel sources, this failes with linker errors like this:
powerpc-linux-ld.bfd: unrecognized option '-Wl,-O1'
powerpc-linux-ld.bfd: use the --help option for usage information
Answer:
The reason for this error is the value of the LDFLAGS variable ("-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed") which is intended for use with "gcc" for linking, but it fails when using "ld" directly as done within U-Boot nd Linux.

To fix, use "unset LDFLAGS" to get rid of the incompatible LDFLAGS setting, or use "eldk-switch -m" to avoid it being set right from the beginning.

ELDK 5.2 Known Issues and Workarounds

Qt Embedded: Qt related files missing

Question:
It appears that Qt related files are missing in the Qt root file system images.
Answer:
Yes, this is a major bug in ELDK v5.2.
This problem was fixed in ELDK v5.2.1

Qt root fs: ext2 tools missing

Question:
some ext2 related tools like e2fsck, mke2fs and tune2fs are missing in the Qt root file systems.
Answer:
This deficiency has been fixed in ELDK v5.2.1

ELDK 5.1 Known Issues and Workarounds

Qt Embedded: even on 32-bit systems qmake2 is a 64-bit binary

Question:
I cannot run qmake2 on my 32 bit linux host
Answer:
The qmake2 in the eldk-eglibc-i686-*-toolchain-qte images is a 64 bit binary:
$ cd /opt/eldk-5.1/armv7a/sysroots
$ file i686-eldk-linux/usr/bin/qmake2
i686-eldk-linux/usr/bin/qmake2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
This is a bug we inherit from upstream Yocto (Bug 1920). It is fixed in ELDK v5.2.

ISO images: permission problems

Question:
After mounting the ISO images, I cannot access the content as a normal user, as the permissions of the top level directory of the ISO file system are set to 0700 = "drwx------" .
Answer:
This is a shortcoming of the tool used to generate the ISO images. Wo can work aroud this problem by several methods:
  • You can run the installer as root.
  • You can (as root) copy the content of the ISO image into a local directory and change the permissions then.
  • You can download the individual files from the FTP server, and use these for installation.

This problem is fixed in ELDK 5.2.

ELDK 5.0 Known Issues and Workarounds

Note: These issues are supposed to be fixed in ELDK 5.1 and later.

Qt Embedded: touch screen is not working as expected

Question:
I'm trying to run the Qt Embedded configuration, but my touch screen is not working correctly. I tried to calibrate it, but this didn't help.
Answer:
Please first make sure that the touch library tslib is working correctly, for example by running the "ts_calibrate" tool. In case of problems, see for example question "Touch screen calibration does not work on Twister board" above.

When you are sure that the tslib is working, please install the tslib plugin for Qt Embedded for your target architecture "ftp://ftp.denx.de/pub/eldk/5.0/updates/<arch>/qt4-embedded-plugin-mousedriver-tslib-4.7.2-r26.1.<arch>.rpm" in your target root file system, for example like this:
# cd /tmp
# wget ftp://ftp.denx.de/pub/eldk/5.0/updates/armv7a/qt4-embedded-plugin-mousedriver-tslib-4.7.2-r26.1.armv7a.rpm
# rpm -Uvh qt4-embedded-plugin-mousedriver-tslib-4.7.2-r26.1.armv7a.rpm 
Then prepare the environment for Qt embedded as follows:
# export QWS_MOUSE_PROTO=tslib
# export LD_PRELOAD=/usr/lib/libts-1.0.so.0.0.0
With this, you should be able to run the Qt demo with touch working correctly:
# qtdemoE -qws

-Os does not work for Power Architecture CPUs

Question
Trying to compile U-Boot or Linux for Power Architecture yields errors like this:
cc1: error: Do not use -Os option if --enable-target-optspace is not set.
Answer:
This option is not supported by a range of upstream GCC compilers for the Power Architecture platform. The issue is fixed in the compiler included in the ELDK 5.1 release. For ELDK 5.0 you need to manually change the -Os options into -O2. Note that it is not possible to compile either U-Boot or the Linux kernel without any optimization, so simply dropping the flag is not a solution.
3. ELDK Building 1. ELDK 5.5 Documentation
Prev Home