CVS-Tag r0-2-6 compiles but does not work

[macfly]

Hello all.

I'm  trying to do some stuff to the current CVS (marks), but i have difficulties running the compiled vompclient. When i use the actual precompiled 0.2.6-dongle, everything works. If i use the CVS-Tag 0.2.6 (or HEAD), recompiles everything and copy this vompclient to the nfs-environment for my MVP, starting the client looks like:

Code Select Expand

00:03:16.586273 [info]   Core - Starting up...
00:03:16.601776 [info]   Core - Signal handlers set up successfully
00:03:16.614572 [info]   Core - Remote module initialised
00:03:16.615384 [info]   Core - LED module initialised
00:03:16.616923 [debug]  MTD - Failed to find correct /dev/mtdX device
00:03:16.617718 [EMERG]  Core - Mtd module failed to initialise
00:03:16.618493 [notice] Core - ViewMan module shut down
00:03:16.619288 [notice] Core - Command module shut down
00:03:16.620100 [notice] Core - VDR module shut down
00:03:16.620869 [notice] Core - OSD module shut down
00:03:16.621634 [notice] Core - Audio module shut down
00:03:16.622403 [notice] Core - Video module shut down
00:03:16.623183 [notice] Core - Timers module shut down
00:03:16.623949 [notice] Core - MTD module shut down
00:03:16.624712 [notice] Core - LED module shut down
00:03:16.625512 [notice] Core - Remote module shut down
00:03:16.626271 [notice] Core - Log module shutting down... bye!


any idea?

[davep]

Is it the same problem I found in http://www.loggytronic.com/forum/index.php?topic=229.msg1366#msg1366 where the kernel modules were not loading due to a version mismatch? Telnet into the vomp and do an lsmod, the result should be:

Module                  Size  Used by    Tainted: PF
lbox_border              936   1
osdfb                   7588  63
gfx                    63500   1 [osdfb]
ircombo                12100   1
av_core               221516   2
os_core                18536   0 [gfx ircombo av_core]

[Chris]

Have you remade your NFS environment recently? The new vompclient requires /proc/mtd to be correctly filled out, which is only done by the 2.4.31 kernel which is part of all the new build system.

[macfly]

OK, I think i found the Problem. My NFS-kernel-Image was 2.4.17 - i think, this is too old. I'll rebuild the kernel with 2.4.31 and try again.

thank you!

[macfly]

hm, looks like the makedev-4 script is unhappy with my system. I started it in a clean environment, it downloaded some files, compiled everything until binutils, and then:

Code Select Expand

+ cd ..
+ logresult binutils /opt/vdr/vomp_new/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-ld
+ test -x /opt/vdr/vomp_new/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-ld
+ echo crosstool: binutils built ok
crosstool: binutils built ok
+ echo 'Install glibc headers needed to build bootstrap compiler -- but only if gcc-3.x'
Install glibc headers needed to build bootstrap compiler -- but only if gcc-3.x
+ grep -q 'gcc-[34]' /opt/vdr/vomp_new/crosstool/crosstool-0.43/build/powerpc-405-linux-gnu/gcc-3.4.5-glibc-2.2.5/gcc-3.4.5/ChangeLog
+ test '!' -f /opt/vdr/vomp_new/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/powerpc-405-linux-gnu/include/features.h
+ mkdir -p build-glibc-headers
+ cd build-glibc-headers
+ test '!' -f Makefile
+ libc_cv_ppc_machine=yes
+ CC=gcc
+ /opt/vdr/vomp_new/crosstool/crosstool-0.43/build/powerpc-405-linux-gnu/gcc-3.4.5-glibc-2.2.5/glibc-2.2.5/configure --prefix=/usr --build=i686-pc-linux-gnu --host=powerpc-405-linux-gnu --without-cvs --disable-sanity-checks --with-headers=/opt/vdr/vomp_new/crosstool/gcc-3.4.5-glibc-2.2.5/powerpc-405-linux-gnu/powerpc-405-linux-gnu/include --enable-hacker-mode
creating cache ./config.cache
checking host system type... powerpc-405-linux-gnu
checking sysdep dirs... sysdeps/powerpc/elf sysdeps/unix/sysv/linux/powerpc sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/powerpc sysdeps/unix sysdeps/posix sysdeps/powerpc/fpu sysdeps/powerpc sysdeps/wordsize-32 sysdeps/ieee754/flt-32 sysdeps/ieee754/dbl-64 sysdeps/powerpc/soft-fp sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for pwd... /bin/pwd
checking build system type... i686-pc-linux-gnu
checking for powerpc-405-linux-gnu-gcc... gcc
checking version of gcc... 4.1.2, bad
checking for gnumake... no
checking for gmake... no
checking for make... make
checking version of make... 3.81, ok
configure: error:
*** These critical programs are missing or too old:gcc
*** Check the INSTALL file for required versions.


I don't think, that the script does mean *my* gcc (since its 4.1.2). I guess, it does mean the gcc in crosstolls, right?

[torsten]

Hi,

have a look at the following thread:

http://www.loggytronic.com/forum/index.php?topic=229.0

There is a bug in the crosstool environment. Unpatched it will only accept gcc up to version 4.0.xx. There is only a small patch needed to get it to work.

Torsten

[macfly]

thank you for this hint, this worked, but:

when compiling the crosstool, i get an error with gcc-3.4.5-glibc-2.2.5:

cc1: error: unrecognized command line option "-mnew-mnemonics"

Does anyone know this problem?

[macfly]

no one with this error? What gcc are you using?

I found this error here: http://sources.redhat.com/ml/crossgcc/2002-05/msg00100.html, but there is no real solution to this. Why do only i run into this error?

regards,
Friedhelm.

[torsten]

Hi Friedhelm,

I'm sorry, but after the patch the crosstool compiled successfully. Afterwards I compiled the client with Chris' script, only leaving the crosstool out.

By the way I am using gcc 4.1.2 on my system. It's based on a OpenSUSE 10.2.

I hope, that you will solve your problem.

BTW in the man-page of the crosstool-gcc "-mnew-mnemonics" options is mentioned like in the system-gcc.

Just a question: Did you move the old crosstool away, e.g. by renaming the crosstool-directory?

Greetings

Torsten

[macfly]

OK, seems there were some inconsistency in my system. I deinstalled everything about gcc 3.3, 3.4 and 4.0, leaving 4.1 alone.

right now, crosstool is compiling.

thank you for your tipp.

[macfly]

*sight*

I'm hopping from one Problem to the next.

I managed to compile a new kernel with nfs-root support, but the mvp doesn't manage to go up with this kernel.

according to the logfile, the mvp gets an IP, requests the nfs-kernel, rerequests an IP and is quiet until reboot:

Code Select Expand

Mar  4 17:39:13 master dnsmasq[28653]: DHCPDISCOVER(eth1) 00:0d:fe:00:42:65
Mar  4 17:39:13 master dnsmasq[28653]: DHCPOFFER(eth1) 192.168.42.31 00:0d:fe:00:42:65
Mar  4 17:39:13 master in.tftpd[28995]: RRQ from 192.168.42.31 filename mvp-kernelimage-nfsroot
Mar  4 17:39:28 master dnsmasq[28653]: DHCPDISCOVER(eth1) 00:0d:fe:00:42:65
Mar  4 17:39:28 master dnsmasq[28653]: DHCPOFFER(eth1) 192.168.42.31 00:0d:fe:00:42:65
Mar  4 17:39:28 master dnsmasq[28653]: DHCPREQUEST(eth1) 192.168.42.31 00:0d:fe:00:42:65
Mar  4 17:39:28 master dnsmasq[28653]: DHCPACK(eth1) 192.168.42.31 00:0d:fe:00:42:65 mvp.4t.to


What's missing is a logentry, that the MVP is mounting the nfs-share. I configured dnsmasq to give the MVP all Information it needs:

Code Select Expand

dhcp-host=00:0d:fe:00:42:65,net:mvpnet,mvp.4t.to,mvp.4t.to,24h
dhcp-option=mvpnet,17,"/tftpboot/root/vomp"
dhcp-boot=net:mvpnet,mvp-kernelimage-nfsroot,server,192.168.42.4


so the MVp should try to mount "/tftpboot/root/vomp" on nfs-server 192.168.42.4 - but this request doesn't occur. the NFS-server is up as i have other clients (headless VDR) which uses nfs from this machine.

anyone an idea?

[Chris]

I'm not sure if this will be relevant to you, but I hit something similar yesterday. I was surprised to find that a kernel built with the config-dev-5 file and the auto build scripts was failing to NFS mount its root. After about an hour of head scratching I booted the mvpmc dongle for no good reason. Straight after this, the vomp kernel would boot again, and load its NFS root. My conclusion is that a vomp dongle made with the standard scripts is somehow altering something in the static RAM (even on a non-wireless MVP) which makes a NFS root kernel not work.

Now as for a solution......... 

[macfly]

Yes, that really worked.

Now what was going on? My "old" nfs-root was build with kernel 2.4.17. Sadly, i do not have the old build-environment. Do you have the old files? is the kernelconfig for the NFS-Kernel identical to the current kernel?

regards,
Friedhelm.

[Chris]

The old files are still on the web site, just replace the -4 on the end of makedevenv with lower numbers... You most likely won't be able to compile a working vomp with the older build systems now, but for comparing kernel setups, go ahead.

As for the kernel config files, they aren't identical, but they are probably not too different. What is really different is the kernel itself - the 2.4.17 was a Montavista port whereas the 2.4.31 starts from a standard kernel and applies lots of patches. The end result is the mostly the same but I suspect it might be quite a different kernel.