Messages

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

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

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.
~ #

Hi,

I have done a quick test and if I replace the redwood.c file with the one that the mvpmc project patch their 2.4.31 kernel it works. It seems as if the redwood.c file is backportable to the 2.4.17 kernel...

E.g. replace ./kernel/dongle/mvpdist/kernel/drivers/mtd/maps/redwood.c
with ./dongle/kernel/linux-2.4.31/patches/redwood.c
from the mvpmc git repository

- Magnus

No I'm using a ordianry kernel downloaded from the tftp.
I did a test with the mvpmc 0.3.1 dongle which is a 2.4.17 kernel and it doesn't list any mtd devices either. I'm pretty sure that its the redwood.c patch applied to the 2.4.31 kernel used by mvpmc 0.3.2 that fixes this.

What hardware did you test on where you had success? Mine is a H3 PAL unit.

- Magnus

Well this is fishy...

Tonight I tried the suggestion mentioned previosly in this thread but only gets so far as to open the /proc/mtd and read the header wich was what I suspected since this is the only one get running a 'cat /proc/mtd' on the mediamvp!

# cat mtd
dev:    size   erasesize  name

However - the same comand booting with the latest mvpmc dongle (0.3.2) gives

# cat mtd
dev:    size   erasesize  name
mtd0: 002c0000 00010000 "HCW MediaMVP KERN"
mtd1: 00100000 00010000 "HCW MediaMVP DATA"
mtd2: 00010000 00010000 "HCW MediaMVP VPD"
mtd3: 00010000 00010000 "HCW MediaMVP LOGO"
mtd4: 00020000 00010000 "HCW MediaMVP BOOT"
mtd5: 00200000 00001000 "HCW MediaMVP ROOT"
mtd6: 000ff000 00001000 "HCW MediaMVP OSD"

So there is clearly something missing in the kernel configuration for vomp. I will investigate this further but as always suggestions are welcome...

- Magnus

Hi,

I just tried the lastest development script and it now produces a bootable dongle for H3 mediamvp's. The only problem now is figuring out wether PAL or NTSC should be used.

Unforrunatelly as the code in main.cc is written the vompclient exits if it fails to open the /dev/mtd1 device. If I'm not totally misstaken there are no mtd devices on Hx hardware?

Its really easy to patch the source oneself and skip the opening of the /dev/mtd1 device and default to PAL (or NTSC). But it would be much nicer to have a generic solution.

So what would be the best way to solve this problem. Perhaps not bailing out if there is a prblem opening/reading the /dev/mtd1 device and then default to read the value from the conf file and if the value does not exist defauilt to a either PAL or NTSC.

Suggestions welcome

- Magnus

Carsten,

Out of curiosity and beeing a total newbie using ProjectX - Which setting gives audio on the mediamvp. I have tried a bunch of them and none works for me yet? Perhaps you could post your X.ini file?

- Magnus

Hi,

If you read the all post in the thread "Patches to make an H3 boot" you will find an excellent post by Forty2 describing howto grab the kernel modules from later hauppauge dongles with squashfs and 2.4.31 kernels. I have personally followed his guide and successfully extracted the kernel modules! Note that the simplest way is to retreive the modules from the mvpmc git repository...

What we must ask ourselves is if there really is any advantage of switching kernel to 2.4.31? During my initial attempts to get my H3 to run vompclient I misstakenly assumed that I had to use the 2.4.31 kernel and squashfs as filesystem. What I noticed is that I couldn't really see any performance differencies between running a 2.4.17 kernel and a 2.4.31 kernel with squashfs. (Perhaps one should try it once more and apply the smc91111.patch to see if its still true but since I don't really have any performance problems this is not higly prioritized by me)

If features keep beeing added to vomp and one run scarse on memory there might be reasons to switch to 2.4.31 and squashfs. For now I would really just appriciate if the buildsystem would apply the hcwmp_header.patch so that Hx users would have an easy way to get a booting dongle without having to patch the kernel themselves.

- Magnus

You need to build your own dongle where the kernel has been patched. The patch to apply, hcwmp_header.patch,  has been posted to this forum earlier. It can also be found on the mvpmc git repository.

It is also neccesary to patch main.cc from the vompclient sources. The following is a diff of the changes that works for me on PAL systems.

Index: main.cc
===================================================================
RCS file: /cvsroot/vomp/client/main.cc,v
retrieving revision 1.28
diff -r1.28 main.cc
193c193
<   success = mtd->init("/dev/mtd1");
---
>   success = 1; // mtd->init("/dev/mtd1");
215c215
<   UCHAR videoFormat = (UCHAR)mtd->getPALorNTSC();
---
>   UCHAR videoFormat = Video::PAL; // (UCHAR)mtd->getPALorNTSC();
404c404
<     mtd->shutdown();
---
>     // mtd->shutdown();

I suggest that you build the dongle and the vompserver plugin with a checkout of the sources from 2006-11-11. My wife, kids and myself use it as our only system watching dvb-t tv.

Hopefully there will be a 0.2.5 release of vomp in a near future addressing the H3 hardware issuses...

- Magnus

To clearify,

I have no problems getting the unit to boot if it has been unplugged for more than two minutes. Its when the coord is unplugged from a running state and imediatelly plugged in that the boot process stalls. If the original huappauge sotware send with the box is used there is no need to wait for two minutes...

Schnuurps - From your reply I kinda get the impression that you problem has gone away. A'm I correct in that assumption?

- Magnus

Hi,

I've got an H3 mediamvp successfully running vomp. Its extremely stable if used with the a cvs checkout from 2006-11-11 (cvs update -D 2006-11-11) and the kernel patch mentioned before on this list.

Only thing boothering me now is the boot process. If vompclient is up and running and I unplug the and plug it back imediately the boot process never completes. It dosn't even get to the point of connecting the servers. Only way to get it to boot is to unplug the coord and wait for about two minutes. When power is back the mediamvp boots fine.

The strange thing is that the unit boots as expected if the original hauppauge software is used!!!

I have tried catching the network traffic with wireshark but I'm a beginner analyzing network traffic so if someone has a clue about the problem please let me know. May save me a couple of late nights analyzing network traffic...

The reason I'm investigating this is that I would like to incorporate the functionallity of the mvprelay program into the vompserver plugin. It will ease the  setup for others running H3 boxes.

- Magnus

You can follow the information on http://mvpmc.wikispaces.com/hxhowto to make your H3 mediamvp boot.

I have no problem using the built in tftp of vompserver either as long as I have the mvprelay program running as described in the link above.

Haven't had time to really understand why the mvprelay progam is needed even if the tftp server is running on the same server as the vompserver plugin. I can only confirm that it doesn't boot without the mvprelay program!

Note that the boot process sometimes stalls in the same way as explained in the link above. The solution is to unplug the mediamvp and wait for about two minutes and retry!

- Magnus

Hi,

My problems were related to faults in the vompserver code when running on 64 bit hardware. Please see my other thread for quick fix. Livetv, recordings, epg etc works fine for me now on a 'cvs update -D 2006-09-30' of vompclient and vompserver.

Thanks everybody who gave input...

- Magnus S.

Hi,

I just realized narrowing down the problems I've seen on my H3 mediamvp that the vompserver code isn't 64 bit compatible. Since a fair amount of my daily work is related to writing and porting code to new platforms I should have seen the fault at once.

The use of long as the type ULONG defined in defines.h is not very portable. The size of long differ between 32 bit platforms (ILP32) and 64 bit platforms (LP64). The long is 32 bits on ILP32 and 64 bits on LP64.

The quick fix for the vompserver is to change the ULONG define to be an unsigned int instead of an unsigned long in defines.h. I recompiled my vompserver, that runs on an 64 bit machine, with this change and voila now livetv, recordings, epg etc works like a charm. Even the windows vompclient began to work!!!

Someone need to go over the code with regard to 64 bit machine compability in mind and post a better patch. I will probably do so over the days but encourage others to work on the issue as well.

- Magnus S.