67 replies to this topic

[sundtek]

confirm, I have both dm500hd and vuduo,

the newest sundtek drivers works like a charm with the newest openpli on dm500hd, contrary to vuduo, which sucks since marusys switched to kernel 3.x and stopped working on drivers in february/march
--------------------------------------------------------------------------------------
Ik kan bevestigen dat de nieuwste drivers perfect lopen op de 500HD. Dit in tegenstelling tot de VU+ duo die, sinds dat Marusys naar kernel 3.x overstapte, het met de drivers vanaf februari / maart niet meer goed heeft gedaan.

3.x is not the problem, the problem seems to be related to Openpli somehow. We can reproduce the somewhat bad picture with OpenPLI and 3.x - but it works fine with VTI and 3.x, so the issue is somewhere else in OpenPLI. Also all systems are using the same driver so it's very unlikely that the issue is on our side this time.

VTI 4.2 .. Linux vusolo 3.1.1 #1 Wed Feb 8 05:04:42 CET 2012 mips GNU/Linux ... OK
$ cd /lib/modules/3.1.1/extra
$ md5sum *
ae8a3c9d3d82907a0222ccb83b60131b brcmfb.ko
199ae4f2fdf7298e2fe4bad580e436c2 dvb-bcm7325.ko
159094fd78c0a67f12a88a9b6f8be84b procmk.ko


OpenPLI 3.0 ..Linux vusolo 3.1.1 #1 Fri Jun 8 05:54:18 CEST 2012 mips GNU/Linux ... Problems
$ cd /lib/modules/3.1.1/extra
$ md5sum *
ae8a3c9d3d82907a0222ccb83b60131b brcmfb.ko
3c641500d2fc441925bf654c88abc8ce dvb-bcm7325.ko <---- different than in VTI
159094fd78c0a67f12a88a9b6f8be84b procmk.ko


dvb-bcm7325.ko causes the bad picture.. broadcom modules from marusys/VU+ again, happy bug fixing.

after copying the dvb-bcm7325.ko file from VTI to OpenPLI, OpenPLI also seems to work now.

Edited by sundtek, 18 June 2012 - 23:26.

[littlesat]

Do you now a source were we can get that driver from to we are able to build our images with it?

[sundtek]

Do you now a source were we can get that driver from to we are able to build our images with it?

it seems like a bug in their latest drivers

Good (VTI):
http://archive.vuplu...20120126.tar.gz
Bad (OpenPLI):
http://archive.vuplu...20120228.tar.gz

[littlesat]

So we can suggest we do currently use a later driver (a bit more then one month) that is not good???? What if VU comes with a succeeder driver? Probably it fails again... ????

At least it is confirmed VTI works better because they are using an older driver....

Edited by littlesat, 19 June 2012 - 06:59.

[sundtek]

So we can suggest we do currently use a later driver (a bit more then one month) that is not good???? What if VU comes with a succeeder driver? Probably it fails again... ????

At least it is confirmed VTI works better because they are using an older driver....

later doesn't mean that it's always better, it's a regression in their module, a bug.
It would be nice to have an option to select which driver package should be used with OpenPLi.

We also told VU+ about it it's their turn to fix it, Dream usually fixes such issues on time we haven't heard about any issues for a long time which just confirms that our drivers are okay (with OE1.6 and OE2.0, Linux 2.6.18 and Linux 3.x) that makes it easy to figure out where to look at ... usually the broadcom drivers from the STB company.

Edited by sundtek, 19 June 2012 - 07:10.

[atilaks]

problem solved on my vuduo after going back to old drivers http://archive.vuplu...20120126.tar.gz

[Pr2]

Hi,

Here is my feedback with my Sundtek DVB stick with Openpli 3.0 on Xtrend ET-9x00.

The driver that works with Openpli 3.0 is: sundtek_installer_120521.0526.sh

the only thing that doesn't work, is the DVB_C_Tuner_autostart.sh so I need to launch the DVB_C_Tuner_starten.sh after each reboot of the box.

All the latest sundtek drivers that I test doesn't work. So not sure that it is really an Openpli 3.0 problem since it works with older Sundtek drivers.

I pick up the Sundtek driver from here:

http://sundtek.de/media/

Pr2

[sundtek]

Hi,

Here is my feedback with my Sundtek DVB stick with Openpli 3.0 on Xtrend ET-9x00.

The driver that works with Openpli 3.0 is: sundtek_installer_120521.0526.sh

the only thing that doesn't work, is the DVB_C_Tuner_autostart.sh so I need to launch the DVB_C_Tuner_starten.sh after each reboot of the box.

All the latest sundtek drivers that I test doesn't work. So not sure that it is really an Openpli 3.0 problem since it works with older Sundtek drivers.

I pick up the Sundtek driver from here:

http://sundtek.de/media/

Pr2

There have been some special modifications for Dreamboxes with the latest drivers, maybe that bites your ET9x00, in order to check that please contact us via Skype "sundtek".
Clarketech is the only STB we don't have in our Lab.

[ricki]

Hi,

Here is my feedback with my Sundtek DVB stick with Openpli 3.0 on Xtrend ET-9x00.

The driver that works with Openpli 3.0 is: sundtek_installer_120521.0526.sh

the only thing that doesn't work, is the DVB_C_Tuner_autostart.sh so I need to launch the DVB_C_Tuner_starten.sh after each reboot of the box.

All the latest sundtek drivers that I test doesn't work. So not sure that it is really an Openpli 3.0 problem since it works with older Sundtek drivers.

I pick up the Sundtek driver from here:

http://sundtek.de/media/

Pr2

I have the same problem on my Vu+ duo, after a reboot it doesn t work, i cant even start it with DVB_C_Tuner_starten.sh.

Edited by ricki, 19 June 2012 - 18:04.

[raphor79]

On my ET9000 with OpenPLi 2.1 the sundtek_netinst.sh installer fails to detect the box as a ctet9000.

It fails on the check

[ "`grep -c BCM97xxx /proc/cpuinfo`" = "1" ]

since this string isn't found in /proc/cpuinfo.

After changing the ctet9000=1 setting in the script and rerun the installer, the driver installs successfully and works as expected.

[WanWizard]

That doesn't seem correct, the ET9000 has a BCM7413.

[pieterg]

The BCM97xxx check seems based on old 2.6.18 /proc/cpuinfo information

[sundtek]

The BCM97xxx check seems based on old 2.6.18 /proc/cpuinfo information

Do you know another safe way to detect ET9000? Unfortunately we don't have such a box here.

[littlesat]

[email="root@et9x00:/"]root@et9x00:/[/email]# cat /proc/stb/info/boxtype
et9000

-or- see here how we detect boxtypes... (in oython - but could be adapt e.g. with less detail).
http://openpli.git.s...7ebc6c4;hb=HEAD

def getHardwareTypeString():
		try:
				if os.path.isfile("/proc/stb/info/boxtype"):
						return open("/proc/stb/info/boxtype").read().strip().upper() + " (" + open("/proc/stb/info/board_revision").read().strip() + "-" + open("/proc/stb/info/version").read().strip() + ")"
				if os.path.isfile("/proc/stb/info/vumodel"):
						return "VU+" + open("/proc/stb/info/vumodel").read().strip().upper() + "(" + open("/proc/stb/info/version").read().strip().upper() + ")"
				if os.path.isfile("/proc/stb/info/model"):
						return open("/proc/stb/info/model").read().strip().upper()
		except:
				pass
		return _("unavailable")

Edited by littlesat, 20 June 2012 - 09:39.

[raphor79]

You could detect the ET9000 the same way as you do with the ET5000.

In /proc/stb/info/boxtype you'll find the string et9000.

And /proc/cpuinfo contains the string BCM7413B1 STB platform.

[sundtek]

You could detect the ET9000 the same way as you do with the ET5000.

In /proc/stb/info/boxtype you'll find the string et9000.

And /proc/cpuinfo contains the string BCM7413B1 STB platform.

Thanks, the netinstaller is updated please test.

cd /tmp
wget http://sundtek.de/meda/sundtek_netinst.sh
chmod 777 sundtek_netinst.sh
./sundtek_netinst.sh

Edited by sundtek, 20 June 2012 - 10:00.

[littlesat]

FYI:
http://openpli.git.s...94d5d96a56b326d
http://openpli.git.s...2f8d4704dde6e2b

[raphor79]

The ET9000 now gets detected correctly.

Going through the installer, I think the ET5000 isn't handled correctly now (can't test it since I don't have a ET5000).
For the ET5000 I would expect an additional elif statement after line 404 like

		elif [ "$ctet5000" = "1" ]; then
				SYSTEM="mipsel2"
				echo "ET5000 detected"

and again at line 671, so this would look like

if [ "$vusolo" = "1" ] || [ "$ctet9000" = "1" ] || [ "$ctet5000" = "1" ]; then

[raphor79]

I found the ET6000 wasn't detected as well, so attached a patch to detect them both.

 sundtek_netinst.txt   2.84KB   7 downloads

[sundtek]

The ET9000 now gets detected correctly.

Going through the installer, I think the ET5000 isn't handled correctly now (can't test it since I don't have a ET5000).
For the ET5000 I would expect an additional elif statement after line 404 like

		elif [ "$ctet5000" = "1" ]; then
				SYSTEM="mipsel2"
				echo "ET5000 detected"

and again at line 671, so this would look like

if [ "$vusolo" = "1" ] || [ "$ctet9000" = "1" ] || [ "$ctet5000" = "1" ]; then

we also updated the et5000 check, however it doesn't matter it's just for speeding up the detection and printing that it detected something.
The installer is quite generic and basically installs on every plattform settopboxes, embedded PCs, normal PCs (x86, arm, mips, ppc, sh4) and every linux kernel version.
Settopboxes only start the driver a little bit different.