vomp on kernel 2.4.31 problems

[sirwio]

Hi,

I have now sorted out all problems I see on my H3 mediamvp except one!

If I unplug the power from the unit and imediatelly plug it back the unit will not boot correctly. Of the five grey progress boxes only the first four get filled and the unit hangs forever. If one however leave the unit unplugged for more than 2 minutes the unit boots correctly.

The strange thing is that this behaviour is not present using the mvpmc 0.3.2 dongle wich is based on the 2.4.31 linux kernel. Older mvpmc dongles based on 2.4.17 kernel shows the faulty behavour. Hence my attempt to build a 2.4.31 kernel for use with vomp!

I have tweaked the kernel config file to suit vomp, applied relevant patches and compiled the kernel using the same crosstool as normally used by vomp. The ibm kernel module files are the one present in mvpmc git repository. In previous post I was  told howto retreve this myself and has successfull done so and the two does not differ so I simply using the pre-extracted ones.

The unit successfully boots and vompclient starts but when any button on the remote is pressed the unit crashes. The ir led is initially on but after any keypress its turned off. Starting vompclient with tracing doesn't give any feedback.

Any hints or perhaps even better a solution to my boot problems using the 2.4.17 kernel?

- Magnus

Output of dmesg follows:


~ # dmesg
Linux version 2.4.31-v1.1-hcwmvp (myth@sam) (gcc version 2.95.3 20010315 (release)) #4 Mon Jan 8 08:09:42 CET 2007
IBM Redwood6 (STBx25XX) Platform
Port by MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 ip=:::::eth0:dhcp root=/dev/ram0
Console: colour dummy device 80x25
Calibrating delay loop... 251.49 BogoMIPS
Memory: 13656k available (1112k kernel code, 356k data, 76k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-proc.o version 2.6.1 (20010830)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xe0040000 (irq = 20) is a 16550A
ttyS01 at 0xe0000000 (irq = 21) is a 16550A
ttyS02 at 0xe0010000 (irq = 22) is a 16550A
PPC 405 watchdog driver v0.5
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
smsc91111 org brcr1 = 0x207cc7b2
smsc91111 (brcr1 = 0x207cc7b2) => TWT cycle = 7
smc91111.c:v1.0saa 08/22/01 by Daris A Nevil (dnevil@snmc.com)
eth0: SMC91C11xFD(r:1) at 0xc2000300 IRQ:27
INTF:<NULL> MEM:8192b NOWAIT:1  ADDR 00:0d:fe:0b:b3:f0
HCW MediaMVP: flash mapping: 100000 at fff00000 to c2002000
Search for id:(20 22ca) interleave(1) type(2)
Search for id:(20 22ca) interleave(1) type(2)
Search for id:(ec46 e6a6) interleave(1) type(2)
Search for id:(20 ca) interleave(2) type(1)
Search for id:(20 ca) interleave(2) type(1)
Search for id:(46 a6) interleave(2) type(1)
Search for id:(ec46 b3c2) interleave(2) type(2)
Search for id:(ec46 b3c2) interleave(2) type(2)
Search for id:(ec46 b3c2) interleave(2) type(2)
JEDEC: Found no HCW MediaMVP device at location zero
HCW MediaMVP: jedec_probe: no known JEDEC part found
HCW MediaMVP: flash mapping: 400000 at ffc00000 to c2002000
Amd/Fujitsu Extended Query Table v1.0 at 0x0040
HCW MediaMVP: JEDEC Device ID is 0xCA. Assuming broken CFI table.
HCW MediaMVP: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
cfi_probe: found redwood_mtd size = 00400000
HCW MediaMVP: cfi_probe: adding [5]parts
Creating 5 MTD partitions on "HCW MediaMVP":
0x00000000-0x002c0000 : "HCW MediaMVP KERN"
0x002c0000-0x003c0000 : "HCW MediaMVP DATA"
0x003c0000-0x003d0000 : "HCW MediaMVP VPD"
0x003d0000-0x003e0000 : "HCW MediaMVP LOGO"
0x003e0000-0x00400000 : "HCW MediaMVP BOOT"
<sdram-mtd>: SDRAM MTD(A0D00000) mapped to c2403000
Creating 2 MTD partitions on "SDRAM MTD Device":
0x00000000-0x00200000 : "HCW MediaMVP ROOT"
0x00200000-0x002ff000 : "HCW MediaMVP OSD"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0:PHY remote fault detected
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.40
IP-Config: Complete:
      device=eth0, addr=192.168.0.40, mask=255.255.255.0, gw=192.168.0.1,
     host=192.168.0.40, domain=sirvio.home, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 963k freed
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init

STBx25xx OS-Core 1.1-Jun/28/2002@June/10/2002 Built Nov 21 2005/20:38:12 for 2.4.31-v1.1-hcwmvp

STBx25xx AV 1.1-July/1/2002@June/10/2002 Built Nov 21 2005/20:38:57 for 2.4.31-v1.1-hcwmvp

IR-Combo for IBM Redwood5 1.0-Apr/17/2002@June/10/2002 Built Nov 21 2005/20:38:57 for 2.4.31-v1.1-hcwmvp
Acer IR mouse installed.

STBx25xx/03xxx GFX 0.1-Jun/26/2002@June/10/2002 Built Nov 21 2005/20:38:25 for 2.4.31-v1.1-hcwmvp

STBx25xx/03xxx Framebuffer 1.01-July/04/2002@June/10/2002 Built Nov 21 2005/20:38:26 for 2.4.31-v1.1-hcwmvp
STB OSD: framebuffer  mapped to 0xc270e000
Console: switching to colour frame buffer device 90x36
fb0: STB OSD frame buffer device
Shared surface handle is set to 0.
~ #

[Chris]

Hmm, my immediate no-research-done guess about the button crashing is that it is some incompatibility between modules built at Hauppauge probably with gcc 3.4 and the kernel you built with our ancient crosstool setup which uses gcc 2.9something. I would put log lines in vomp around the parts where it receives button presses just to see if it  is an easy segfault somewhere in there though.

After you sent me the patch for H3 stuff by email I did investigate, but I ran into trouble trying to run the modified kernel on an old wired MVP. The old MVP reboots as soon as it loads the 2.4.17 kernel with the new redwood.c file in it. So I also decided to try the 2.4.31 kernel but so far I have only got as far as setting up the new cross compiler that uses gcc 3.4 provided by Hauppauge. My next step is to make a kernel with that and see if it will run on both boxes.

[sirwio]

Browsing the mailing list of the mvpmc project I found posts describing the same problem as I see - Crash when pressing any button on the remote. The solution they found was the same as the one you suggest. Switch compiler.
They switched from gcc-2.95.3 -> gcc.3.4.5

- Magnus

[sirwio]

I downloaded the crosstool-0.43 and compiled it cleanly without any patches for gcc-3.4.5-glibc-2.2.5
Rebuilt the 2.4.31 kernel, busybox and the jpeg library. I had to tweak the client sources a bit to get it trough mostly because gcc-3.4.5 is stricter.

The new dongle works fine but it still won't reboot cleanly without leaving the power cord unplugged for a while. Next thing to try is to us uclib instead of glibc or perhaps add the vompclient executable to an existing mvpmc dongle...

The changes required to use a new crosstool and a new kernel is fairly trivial and only minor modifications are required to the build scripts. Is there any interest in these patches?

- Magnus

[MarkC]

Hi,

This topic is actually the 'big thing' at the moment, as Chris now has access to an H3 he wants to get working cleanly, and I'm interested in moving away from the ancient gcc/glibc & Montavista kernel, and getting VOMP working with a better dongle build method.

Right now I'm trying to build a dongle using the Hauppauge toolchain that Chris mentioned (gcc-3.4.4/uClibc), along with the 2.4.31 kernel, patches and build procedure. I'll keep the thread posted...

[sirwio]

Hi,

You guys talk about the Hauppage toolchain. It wouldn't by any chance be buildroot - http://buildroot.uclibc.org/ that will be used?

Since crosstool-0.43 gcc-3.4.5-glibc-2.2.5 didn't solve my particular issue I'm willing to give something else a shot.

- Magnus

[MarkC]

I'm talking about this tarball, which Chris brought to my attention last week:

http://www.mvpmc.org/dl/mediamvp-20060728-dist.tar.bz2

(You may have known that already; just making sure!)

To me it looks like something Hauppauge have put together themselves, with the stuff in the toolchain directory being a crosstool-style "download it all and build it" affair. It's probably influenced heavily by crosstool and/or buildroot, but I haven't examined it closely.

From what I can gather, the rest of the tarball is all about running make in the src/ directory, which puts a root filesystem together, compresses it into a squashfs, copies it into the kernel tree and then runs 'make zImage.initrd' on the kernel. The patches have modified the kernel tree such that a dongle.bin magically pops out. At least that's what it looks like; I'm getting close to testing it.

Of course the existing src/ directory doesn't do much as it stands, because all the Hauppauge client stuff is missing. But I'm hoping I can make a vomp/ directory with a similar structure that does what we want. At the moment I'm just going through each step manually to make sure I understand the process.

[Chris]

I am away on work duty for a week now, so there won't be any progress from me. But... Last time I looked at it I examined the hauppauge file and decided I didn't really like some of the way they were doing things, and it is too different from all the structure I have already built (and quite like). So, since Hauppauge are now starting with a clean 2.4.31 kernel and applying patches, I had a go, but didn't get a working cross compiler. What is the trick for building a gcc 3.4 cross compiler from a clean latest crosstool? (Mark?)

Unfortunately I only had time for one go at it - the program I built with the compiler I built kind of started up on the MVP but very quickly crashed out with strange memory problems.

[sirwio]

Hi,

My patches attempted to minimize the changes to the existing vomp development structure. I belive this is a good path since the vomp development guide is actually quite trivial to follow...

Download crosstool-0.43
Unpack it into vomp/crosstool directory.
Create a file mvp-ppc405.sh into the croostool-0.43 directory. File is attached to this message post
Build the crosstool toolchain. ./mvp-ppc405.sh

Note that this will build a toolchain with gcc-3.4.5-glibc-2.2.5. Easy to change the mvp-ppc405.sh script to use a newer glibc! How one adapt the crosstool build to use uclib is beyond my knowledge!

My dongle build with the above toolchain works beautifully except for the reboot thingy wich really of minor importance. Are you sure you rebuiild all components using the correct toolchain?

I'm attaching the modified mvpmc kernel script I used to build the 2.4.31 kernel as well as the .config file for the kernel. The scripts shows wich patches I applied.

- Magnus

[MarkC]

Right, having looked at the Hauppauge tarball, mvpmc's scripts and your latest post, I think you're spot on. Basically we just need to update our build scripts to incorporate stuff from the Hauppauge tarball, like mvpmc have done. And like you have done: thanks! 

I don't have access to an H3, but I'm going to build a dongle using your method and check that it boots on my old MVP. Then, there's just the H3 reboot issue that needs sorting. You say it doesn't happen with the latest mvpmc dongle, so what's different between us and mvpmc? I can only see two things immediately: they're using a uClibc toolchain from buildroot, and they're also using squashfs.

I don't see logically how using a different libc could make a difference, but I don't understand it well enough to be sure. Could there be something in the squashfs patch that helps? Possibly. There definitely is something in there that checks against the MVP dongle version numbers in head.S (from dongle_version.h and mvp-version.patch) and might have something to do with checking whether an H3 MVP is booting from flash or a network dongle. Actually, the code I'm talking about is in sdram-bank1.patch, but it's only triggered if squashfs is enabled instead of the usual CONFIG_BLK_DEV_INITRD.

So I'll also try building dongles with the Hauppauge uClibc toolchain, and then with both that and squashfs. If they all boot on my old MVP, then perhaps we could try on an H3. However, like Chris, I wouldn't like to have to move to squashfs, so I hope that doesn't fix the problem!

[Chris]

Hehe, I'm an idiot. I didn't recompile jpeg lib, I don't think the program got that far, but it probably didn't help. I will have another go when I get back.

glibc is fine, I currently have no interest in switching everything to ulibc.

I read in the Hauppauge file documentation about their version number system, and how to indicate to the MVP loader which version the software is and what stability level it is at. Maybe making sure the stability level is set to alpha will help with the 2 minute reboot problem.

[MarkC]

Hmm, actually, I was a bit wrong last post: the sdram-bank1 code only checks for the HCW_MVP magic string, not the version numbers.

You could be right about the version numbering and the reboot issue, but I think Magnus is using the same dongle_version.h as mvpmc (with alpha flag) and still has the problem. I do feel that it must be something in that area though!