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-<arch>-linux-gnueabi"
in each of the "/opt/eldk/<arch>/" directories. Sourcing this script in
your shell will provide a number of useful settings, including the CFLAGS
environment variable:

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:

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:

"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:

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

-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:

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:

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

Note: All tools working with software packages have to maintain
a certain "package database". This may be a real database (like
Berkeley DB files as used by the rpm tool), or a plain text file
(like used by the ipkg tool). The important message is: without
such package database, you will not be able to work with packages,
like adding new, or listing, removing or updating already installed
ones.

The following operations will therefore only be possible on file
system images that contain such package information. Note that most
of the "small" root file system images in ELDK (say,
core-image-minimal or core-image-basic) do not contain any package
database.

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:

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 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 the architectures, 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:

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:

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.

Note that (starting with release v5.4), ELDK includes the full
U-Boot and Linux kernel trees that are used in this release.
These are available in the u-boot-dev and kernel-dev (and for
configurations with Xenomai support in the kernel-ipipe-dev)
packages. For the SDK and meta-toolchain images these images get
installed into the "/usr/src" resp.
"/opt/eldk-5.4/5.4/armv5te/sysroots/armv5te-linux-gnueabi/"
directories.

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:

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.

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.5 Known Issues and Workarounds

/etc/inittab id field too long

Question:

When booting with one of the provided root file systems, I get an error message

INIT: /etc/inittab[31]: id field too long (max 4 characters)

and there is no login prompt on the serial console.

Answer:

This is a bug in the setup of the "/etc/inittab" file in the target root file system.
It contains the following entry:

115200;console:12345:respawn:/sbin/getty 115200 console

The initial string "115200;console" is incorrect;
to fix the problem, please change it into "S0",
i. e.

This happens when the ELDK is installed outside the "canonical" location of /opt/eldk.
Usually the ELDK can be installed at arbitrary paths, but this does not work in ELDK 5.5. Either
a symlink or a fresh install at the canonical path will fix the problem.

ELDK 5.4 Known Issues and Workarounds

Installer does not show Xenomai images in help message

Question:

I would expect that the ="install.sh=" script offers to install
the available Xenomai images, i. e. the
"core-image-minimal-xenomai"
and
"core-image-qte-xenomai-sdk"
root file system images, and the
"meta-toolchain-xenomai-qte"
SDK image. However, I cannot see any of these?

Answer:

This is a bug in the installer script that will be fixed in a later
version. However, the images are there, and you can install them fine.
So for example to install the QtE root file system and the matching SDK with
Xenomai support included, please use a command like this:

./install.sh -s xenomai-qte -r qte-xenomai-sdk armv7a

Note however, that this does not apply for the MIPS architecture,
which is currently not supported yet by Xenomai.

Installing the Xenomai SDK root file system throws error messages

Question:

When installing the "core-image-qte-xenomai-sdk" root file system
image, I get a number of error messages like these:

This is a bug in the xenomai-qte SDK image.
It will be fixed in a later version.
As long as you do not get any other error messages, this has no impact on the
actual operation of the SDK and cn safely be ignored.

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 and 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.

WARNING: Be careful not to mix using
"eldk-switch" with and without the "-m" option; see
here for details.

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:

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:

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.