Hmmm. Just for the heck of it, I tried to build fontconfig-native myself, using the bb-file from the development branch of OE. And it worked like a charm, no problems at all.

Could it be that the build system is still using an older version? Maybe it will help if you try and delete the stamps (rm tmp/stamps/fontconfig-native*) and the build directory (rm -rf tmp/work/fontconfig-native*).

If that doesn't work, you might also try to upgrade the configure pre-sets in site/mipsel-linux. I've attached the latest from the dev branch of OE. I've had to do this to get vim to compile.

Not sure if it helps, but I do have a suggestion. Try fontconfig-native version 2.3.91 from the development branch of openembedded. The dreambox branch is still at version 2.2.95. Maybe there are some important bug fixes in the more recent version.

Mind you, I haven't tried this myself, so it could well be that it doesn't work.

Please find fontconfig.tar.bz2 attached, in case you don't check out the org.openembedded.dev branch. Save your old fontconfig directory, and unpack the tar file:

cd ../packages
mv fontconfig fontconfig.orig
tar xjf fontconfig.tar.bz2

Then try again, and see if it works.

Ohh, the joys of cross compiling... A library on the build computer is interfering with configuration of the cross environment.

Suggested "fix":

mv /usr/bin/caca-config /usr/bin/caca-config.orig

Then you will have to force OE to re-configure gst-plugins-good. I usually do that by

rm tmp/stamps/gst-plugins-good*

And then start building again.

You can move the /usr/bin/caca-config back when finished.

Strange... I my setup, the caca plugin (whatever it is) isn't built at all. From my config.log file in gst-plugins-good-0.10.2-r0:

configure:19941: checking for ladspa.h
configure:19948: result: no
configure:19982: *** These plugins will not be built: ladspa
configure:20042: checking for caca-config
configure:20073: result: no
configure:20121: *** These plugins will not be built: libcaca

Check your own config.log file, and see where it picks up the caca-stuff from, and try and move it out of the way.

Store the following files in your sources directory. Then unpack the md5 file and try again.

Post your log file (/home/dm/tuxbox-dev/dm7025/build/tmp/work/gst-plugins-good-0.10.2-r0/temp/log.do_stage.9940)

That might give someone a bright idea.

Last one, I think....

I'm not 100% certain why the ppp-2.4.3-r0 package compiled OK before, while it now complains about missing crypt support. Anyway, upgrading to ppp-2.4.3-r1 from the org.openembedded.dev branch fixed the problem.

With the previously posted patches to enigma2 and this upgrade of ppp, dreambox-image now builds on my machine (Suse 10.1, x86_64) without resorting to using i686 as the build architecture.

Me again.

Since guidance has been difficult to get, I have just stumbled on to see where the path leads me. The following patches to enigma2/acinclude.m4 and site/mipsel-linux are probably not 100% correct, but they do actually work on my setup, and I think they represent a step in the right direction.

Having bought myself this new 64bit toy, I've had the opportunity to look a little bit closer into this problem of compiling enigma2 using an x86_64 architecture build machine.

Zitat

Original von tmbinc
das BUILD_ARCH = "i686" ist natürlich nur für 32bit userspace unter 64bit kernel. Da ist das auch dringend notwendig, sonst sollte man nochmal alles neu bauen.

mit 64bit userspace hab ich keine ahnung - das kann auch ein bug sein. Ich wäre dann sehr dankbar für ein .diff

My conclusion so far is that there is indeed a bug in the build files for enigma2. The generated Makefile contains the following line (I've split it up to be readable):

Zitat

CPPFLAGS = -I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include
-I$(top_srcdir) -D_REENTRANT
-I/src/OpenEmbedded/build/tmp/staging/x86_64-linux/include/python2.4
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib/../include
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib/../include/freetype2
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include/fribidi
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib/../include/libpng12
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib/sigc++-1.2/include
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include/sigc++-1.2
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include -pthread
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include/gstreamer-0.10
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include/glib-2.0
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib/glib-2.0/include
-I/src/OpenEmbedded/build/tmp/staging/mipsel-linux/include/libxml2

Alles anzeigen

I've put the offending part in bold. The include files for the build system is used instead of the include files for the host system, and that just can't be right. The LDFLAGS

Zitat

LDFLAGS = -L/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib
-Wl,-rpath-link,/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib -Wl,-O1 -pthread
-L/src/OpenEmbedded/build/tmp/staging/x86_64-linux/lib/python2.4/config -lpython2.4

is also wrong, but the fact that the mipsel directory contains the correct libraries saves us from this becoming a serious problem.

I then looked for the source of the incorrect Makefile, and found the following lines in configure.ac

Zitat

AC_INIT(tuxbox-enigma,0.0.1)
AM_INIT_AUTOMAKE(tuxbox-enigma,0.0.1)

TUXBOX_APPS
TUXBOX_APPS_DIRECTORY

AC_PROG_CC
AC_PROG_CXX
AC_PROG_RANLIB

AC_ARG_WITH(libsdl,
AC_HELP_STRING([--with-libsdl], [use sdl, yes or no]),
[[withsdl=$withval]],
[[withsdl=yes]]
)

AM_PATH_PYTHON(2.3)
AC_PYTHON_DEVEL
.
.

Alles anzeigen

The first of these two lines will run the python compiler and set some variables. The second line will expand upon this (in the AC_PYTHON_DEVEL macro in acinclude.m4) to set the include files and library paths. Running the build python to set the include- and library path for the host python library is, as the English say, "not even wrong".

Unfortunately, I don't have a simple solution. I have a few ideas, though:
[list=1]
[*]Patch python so that a python.pc file can be assembled and installed in the correct directory. Then the python lib can be handled like any other pkgconfig-controlled library.
[*]Change the acinclude.m4 file so that cross-compilation is detected, and a different strategy is used when it makes no sense to run python to find the values for the variables.
[*]Hack the hell out of configure.ac. This would most likely break portability of enigma2 configuration, so it's probably not a good solution
[/list=1]
Before I invest more time in trying out any of these ideas, I thought I should check here to see if anybody has any better ideas. Also, it would be nice to hear what kind of fix would be acceptable to the enigma2 developers.

Does anybody have any comments or suggestions?

You can't make a valid 7020 image from a 7000 image alone. Essential parts in the 7020 image are simply not present in the 7000 image. Like the linux kernel. Like head.ko.

As you've found out, this won't work. The whole MTD/JFFS2/NAND-flash implementation stops you from using the standard Linux utilities to copy data directly to the flash. The problem is that NAND-flashes contain so-called OOB (out-of-band) data in addition to the normal data blocks. When you do a straight write to one of the device files (like /dev/mtdblock/3), only the data blocks are copied, while the OOB-data is computed and written by the MTD driver "invisibly" to the user. The unpacked .nfi file consists of complete jffs2 images, OOB-data included, so if you try to just dump this to the device, you will find that
1) it takes more space than it should on the flash (OOB-data is effectively written twice), and
2) the result is not a correct jffs2 file system, so it's unusable

OK, you might say, let's just strip off the OOB data also from the .nfi, write the data blocks to the device, and let the MTD device driver recompute the OOB data. Well, this won't work either, since jffs2 is actually using some of the OOB data for filesystem meta data. So you still won't have a valid jffs2 file system.

There are some programs in the mtd-utils package that should be able to do the job, but I have not used any of them (except flash-eraseall) myself. After a bad experience I had, when some scripts I made to backup the flash caused bad blocks to appear on a beta-tester's machine, I've stayed away from mucking around too much with NAND-flash. It's just too easy to make mistakes that are next to impossible to recover from.

And, BTW, as a personal opinion, I think you're going about this the wrong way. What you need is a program (running on the dreambox) that can unpack an .nfi file to the CF, and keep away from the flash altogether. The best starting point for such a program, that I know of, is the one that tmbinc wrote. It will need one semi-major change (i.e. unpacking to files instead of doing everything in memory) and some minor changes to become just what you need to unpack a .nfi directly to the flash (CF, that is).

I believe tmbinc's unpacking tools come closest to what you want. See Experimental: NFI2CF

Zitat

Original von Lior
ping?

4 packets transmitted, 1 packet received, 75% packet loss

I'm currently compiling OE for the 7025 using opendreambox version 1.3, and saw a bug that I haven't noticed before. When installing ncurses (the cross version), terminfo files are produced in the misc/run_tic.sh shell script. When cross-compiling, the native "tic" program is used to compile the terminfo files. In OpenEmbedded, the ncurses-native package will compile and install the necessary binaries and libraries in the staging/ directory. The "run_tic.sh" script correctly picks up the correct version of the "tic" binary. So far, so good.

BUT, and here's the problem, the "ncurses.so.5" library is NOT picked up from the staging/ directory, but comes from the system /usr/lib instead. Might be a missing LD_LIBRARY_PATH or something. I was too lazy to find out, I just installed the missing libraries in /usr/lib and re-started the build. If you happen to already have a suitable libncurses.so.5 in /usr/lib, you will of course never even see the problem.

I've now tested with a different CF card, and the problem persists. A little while after starting my test program, the machine hangs up, or to be more precise, as soon as a process needs access to the IDE bus, it hangs forever. It also complains a couple of times on the serial console that it's loosing interrupts from hdc. The two cards I have tested are:
1. SanDisk 256MB (an old one, with no DMA capabilities)
2. TwinMOS 256MB Ultra-X 70X (does have DMA capabilities)

One other thing I've noticed. When running the TwinMOS 70X, hdparm correctly reports that it is able to run UDMA. However, the IDE driver will by default use PIO mode to access it, and if I try to force it to use UDMA, the machine just hangs. Does anybody have a good explanation?

Box type: 7025
GUI (enigma1/enigma2): e2
Firmware version: dreamville 03-24

I've been running my 7025 with the root file system on CF for a while, and since the latest revision of the kernel patches, I've had a problem that the machine just hangs after some time when recording to HDD. This week-end, I moved my root file system to HDD instead (using CF just for the boot partition), and the problem seems to have disappeared. By running the following script, the system hangs after a few minutes. Sometimes I see a kernel message saying "hdc: lost interrupt".

#! /usr/bin/python


import os


if os.fork():
    file = "/dev/ide/host0/bus0/target0/lun0/disc"
else:
    file = "/dev/ide/host1/bus0/target0/lun0/disc"


while 1:
    print "Open %s" % file
    fd = open(file, "r")


    i = 0
    while fd.read(4*1024):
        i += 1
    fd.close()

My problem could also be caused by a faulty HDD or a faulty CF, so could someone with both CF and HDD be so kind and run the test and see what happens? I tend to believe that the sharing of the interrupt between CF and HDD is to blame, but I can't be sure until someone else can repeat it.

Thanks! I'm looking forward to having a closer look at this during the week-end.

About making a FAT image in batch mode (from the README file): Look at the "mkdosboot" script in the mtools package.

Zitat

Original von TheDOC
Ein kleiner Leitfaden zum Image-Selberbauen:
http://dm7020.dreamville.de/howto/imagehowto.html

Could you please also make corresponding drivers for the 7000 available?

If you look in /etc/init.d, you will find a script called "modutils.sh". It's a small script that reads the /etc/modules file, loading any modules that are listed in this file. The modutils.sh script is run during boot, so all you need to do is to add the extra modules that you want to load to the /etc/modules file.

Well, let it not be said that I didn't warn you... These scripts have been written for my own private use, reflecting my Linux environement, with no attempt at making them generic and usable for anybody else. I can almost guarantee that they will need changes to run on any other machine but my own.

Just to make it clear, these scripts are used on my PC, not on the 7025. On the PC, each image for the 7025 is stored in a separate directory.

There are four different scripts:
1) Backup_cf, to copy the existing image from CF to the PC disk.
2) Unpack_image, to unpack an nfi file to PC disk
3) Update_files, to copy config files etc. from one image to another (still on the PC)
4) Copy_image_to_cf, to copy an image to the CF

Those four scripts would typically be run one after the other when I test a new image. The new image on CF would then contain all my up-to-date configuration files, and I would have a backup of my last working image on disk in case the new one fails for whatever reason.

Notably missing is a script to install extra ipkg-packages offline on an image. This script would also make it easier to update single packages (think CVS versions of enigma2) from OE. Maybe this week-end... Currently, I keep a collection of ipkg-files in a directory on the harddisk on the 7025, and install them on any new image from the 7025 itself.