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.
Customizations
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:
- 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.
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
ELDK v5.x and 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.
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.
