Are DiSEqC 1.0 commands supported? about dm500-satip HOT 10 OPEN

hi! it's been a long time since I last touched this project, but a quick look shows the STV0299 (the frontend IC used in DM500S boards) does support DiSEqC:

https://github.com/mildsunrise/stbx25xx-linux/blob/6613d01090e412f2f47ee192dedc98d3f6e98d6d/drivers/media/dvb/frontends/stv0299.c#L273

But maybe there's something else needed for it to work, like GPIO pins or similar.
Are you sure DiSEqC works with stock firmware?

from dm500-satip.

Good idea to check with stock, should indeed have done that in first place on this particular device. I have backed up the original firmware, but I'm not sure which commands I have to use on your firmware to restore it. It seems your firmware not only uses mtd0 but also mtd4 or mtd5.

Could you hint any flash commands, I will try and report back soon.

from dm500-satip.

in principle you should go ahead and flash partition 0. the other partitions are for user data, it's just that I cheat and use them for firmware as if it was one big combined partition (IIRC).

from dm500-satip.

I could cp, cat or dd the backup files directly to /dev/mtd0-6 but I couldn't find a matching tool for eraseall on your firmware. I do did find reference to some flash related binaries flash_erase flash_lock flash_unlock flashcp you included in the later dm500-satip release(s).

Don't know if it is necessary at all to use eraseall or its just some dd if=/dev/zero of=/dev/mtdX equivalent with maybe some flash integrity checking?

I guess the worst case scenario is recovering via RS232 serial port using the bootloader directly or use the DreamUp tool on a Windows machine.

from dm500-satip.

Restoring to dreambox firmware succeeded and 4 position DiSEqC AA AB BA BB is scanning right now as we speek. Only AA(astra 19.2), AB(hotbird 13.0), BB(astra 28.2) scanned since BA (Astra 23.5) doesn't have any valid transponders with this old dreambox firmware so won't find anyhting(could try blind scan though).

Steps for restoring dreambox firmware from dm500-satip:

scp backup-mtd0.img [email protected]:/tmp/
ssh [email protected]
cd /tmp
#direct copy to /dev/mtd0 doesn't write to flash but to filesystem and may soft-brick use mtdblock0!!!
cat backup-mtd0.img > /dev/mtdblock0 #takes a while and finishes without error but ssh get killed
#retry ssh login asks for password but will not login,
#pull powercord after ~1 minute and power on again
telnet 192.168.1.150 #Dreambox firmware is working again ;-) 

from dm500-satip.

okay, so the hardware does have diseqc support...
in that case, something must be missing in the DVB drivers or misconfigured in minisatip, I suppose.
GPIO pin is an option. unfortunately I don't have a board + setup to test, so... you're on your own.

all I can tell you is that the code is there:

• in minisatip
• in the kernel DVB frontend ioctl handler
• in the kernel driver for the DVB frontend

if you want to investigate, you should start minisatip in debug mode and verify that the diseqc commands are indeed processed (and ioctls are issued against the kernel). if this works but the ioctls fail, the stv0299 module can be loaded in debug mode. if these two things appear to be working properly, the way would be to do some reverse engineering on the closed source drivers to see how they do it.

but again, I don't think I'll have time for this anytime soon, sorry :(

from dm500-satip.

No need to say sorry, you already did a great job 👍 and we all know this device is nearing end of lifetime. I'm already happy you replied on topic and showed me direction to think a little further but shouldn't put to much effort in it...

The device is capable of doing DiSEqC in original firmware and is verified on my labelfree clonebox. The box uses a STV0299 as a Frontend, which happen to have a very recent 😄 2022 DiSEqC related kernelpatch under linux yours (jiffies - start > timeout) vs (time_after(jiffies, start + timeout)) vs (time_is_before_jiffies(start + timeout)) current linux media tree. Also in Windows it required special care in form of alternate .dll with driver tool to force a DVB-T adapter mode to make DVB-S DiSEqC work...

From what I have read I understand that DiSEqC commands can be sent by different parts of the DVB-S receiver pathway, as in hack the frontend to do the job or use a other IC's /Tuner/Demod/dontknowname in the signal path todo it. This seem to be the case with a sort of legacy path that is refered in the driver that in some cases STV0299 doesn't do the Job well a other IC might do it if available and capable?

Debugging X86:
I do happen to have 2 similar PCI dvb-s1 cards that also happen to have this "STV0299B" frontend and a Philips SAA7146AH, TDA8060TS, TSA5?59T opened the metal plates on the tuner to verifiy.
One of those tuners is the Hauppauge WinTV Nova which I checked 5 years ago in Ubuntu 16.04 with Tvheadend and DiSEqC seem to work than.
The other TechnoTrend 1500s Philips SAA7146AH,???????,TSA?059T which I recently got still has to be verified to work with diseqc.

My approach would be test these pci-dvb-s devices with Ubuntu 16.04 or 20.04 directly with Tvheadend 4.2 to see if they have DiSEqC functioning at all. Than remove tvheadend, install minisatip(master) and use Tvheadend on a different host with satip tuner config. If that works than downgrade minisatip to version 0.4 that matches DM500s if that still works. Than make a limited selection of matching DVB-S transponders frequencies High/Low/Vert/Horz for 4 satelites and run STV0299,budget(kernel module), minisatip, tvheadend all in debug mode and log everything.

Debugging DM500:
For debugging on the DM500s I guess I have to change the boot parameters to force "STV0299" in debug or hope that /etc/modprobe/modulename will have an effect. In worst case have to recompile kernel with STV0299 as a module instead of builtin so I can modprobe stv0299 debug=1 mode.

Does it make any sense at all doing the X86 debugging route with these 2 pci-cards or are we comparing apples & oranges and should just try to recompile DM500S with seperate module debug mode and maybe even recent 2022 diseqc kernel patch?

from dm500-satip.

I see! Answering point by point:

which happen to have a very recent smile 2022 DiSEqC related kernelpatch

I've reviewed this patch and it doesn't appear to fix a bug, or at least not the kind of bug that would make DiSEqC not work at all. Even if there are more recent patchsets, unless you see one that does seem to fix a bug, I wouldn't spend too much time trying to backport the changes into this firmware.

For debugging on the DM500s I guess I have to change the boot parameters to force "STV0299" in debug or hope that /etc/modprobe/modulename will have an effect. In worst case have to recompile kernel with STV0299 as a module instead of builtin so I can modprobe stv0299 debug=1 mode

Yes, unfortunately I compiled the stv0299 module with Y rather than M.
So if you don't want to rebuild the firmware with M, the only way to specify debug mode is via a kernel boot parameter, which would be: stv0299.debug=1

Does it make any sense at all doing the X86 debugging route with these 2 pci-cards or are we comparing apples & oranges and should just try to recompile DM500S

It's just my intuition, but I'd advise focusing your efforts on playing with the DM500S board rather than comparing behaviour to your pci cards, even if they have the same frontend.

To build your own kernel / firmware, your best shot is probably to follow the instructions in BUILDING.md with an ubuntu:14.10 Docker image...

from dm500-satip.

Bricked... but recovered via DreamUp using the 'backup-mtd0.img' made earlier. I can confirm that your build instructions are still valid on ubuntu 14.04.6 amd64 in april 2022(apt needs universe/multiverse/src/git, host-isl retries and finds different mirror). Reflashed with own dirty build image having stv0299 as a module and commented S70satip script on boot so everything is started manually.

Also did the x86/64 debug route on ubuntu 20.04.1 and verified both stv0299 equiped pci dvb-s cards (Hauppauge&Technotrend) worked with DiSEqC aa:ba:ba:bb in Tvheadend 4.2 stable. Then I started Tvheadend without dvb support with argument -a -1 and run minisatip on the same machine so tvheadend would not claim adapters from minisatip. I build, tried and verified most branches of minisatip working with DiSEqC from 'master, 0.7, 0.5, 0.4' all worked. Although the 0.4 branch had a older date than your 0.4 branch I was able to verify that the DiSEqC code was already working there.

# uname -a
Linux dreambox 2.6.28-tm0-s4-ge460f79-dirty #4 Mon Apr 4 14:46:37 UTC 2022 ppc GNU/Linux

# lsmod
Module                  Size  Used by    Not tainted

# ls /lib/modules/2.6.28-tm0-s4-ge460f79-dirty/kernel/drivers/media/dvb/stbx25xx
dvb_stbx25xx.ko

# ls /lib/modules/2.6.28-tm0-s4-ge460f79-dirty/kernel/drivers/media/dvb/frontends
stv0299.ko

# cat /etc/init.d/S70satip 
#!/bin/sh
# Called at startup to start serving SAT>IP.

# Load DVB module
#/bin/sleep 1
#modprobe stv0299 debug=1
#/bin/sleep 4
#modprobe dvb_stbx25xx

# Start SAT>IP server
#minisatip -R /usr/share/minisatip/html -x 80 -f > /dev/null &

exit 0

Some dmesg snippet without debug, although loading the stv0299 first it won't show in dmesg except after loading dvb_stbx25xx...

# modprobe stv0299
# lsmod
Module                  Size  Used by    Not tainted
stv0299                13224  0

# modprobe dvb_stbx25xx
# lsmod
Module                  Size  Used by    Not tainted
dvb_stbx25xx           35076  0 
stv0299                13224  1 dvb_stbx25xx

#dmesg snip
--- STBx25xx Digital Video Broadcasting drivers ---
GPIO-253 autorequested
Using interrupts: 17 18 19 23 
--- STBx25xx MPEG-2 Transport Demultiplexer driver ---
dvb-stbx25xx: resetting demux... done (took 1 ms)
dvb-stbx25xx: Mapped 2097152 bytes of demux memory at 0xc3900000
DVB: registering new adapter (STBx25xx Digital TV device)
GPIO-238 autorequested
DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)...
GPIO-227 autorequested
GPIO-231 autorequested
dvb-stbx25xx: Initialization of hardware complete
dvb-stbx25xx: IBM STBx25xx digital TV hardware driver loaded successfully

Some snippet of dmesg using debug and scanning on diseqc bb astr282 still reports aa astra192 channels:

###modprobing first stv0299 but reports STBx25xx first?
#modprobe stv0299 debug=1
#modprobe dvb_stbx25xx debug=1

--- STBx25xx Digital Video Broadcasting drivers ---
GPIO-253 autorequested
Using interrupts: 17 18 19 23 
--- STBx25xx MPEG-2 Transport Demultiplexer driver ---
dvb-stbx25xx: resetting demux... done (took 1 ms)
dvb-stbx25xx: Mapped 2097152 bytes of demux memory at 0xc3900000
DVB: registering new adapter (STBx25xx Digital TV device)
GPIO-238 autorequested
DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)...
GPIO-227 autorequested
GPIO-231 autorequested
dvb-stbx25xx: Initialization of hardware complete
dvb-stbx25xx: IBM STBx25xx digital TV hardware driver loaded successfully
stv0299: stv0299: init chip
dtv_property_dump: tvp.cmd = 0x0000002c undefined
dvb-stbx25xx: SEC_VOLTAGE_OFF
dm500_tuner_sleep: not implemented
stv0299: stv0299: init chip
dtv_property_dump: tvp.cmd = 0x0000002c undefined
stv0299: stv0299_wait_diseqc_idle
dvb-stbx25xx: SEC_VOLTAGE_18
stv0299: stv0299_send_diseqc_msg
stv0299: stv0299_wait_diseqc_idle
stv0299: stv0299_wait_diseqc_fifo
stv0299: stv0299_wait_diseqc_fifo
stv0299: stv0299_wait_diseqc_fifo
stv0299: stv0299_wait_diseqc_fifo
stv0299: stv0299_wait_diseqc_idle
stv0299: stv0299_send_diseqc_burst
stv0299: stv0299_wait_diseqc_idle
stv0299: stv0299_wait_diseqc_idle
stv0299: stv0299_wait_diseqc_idle
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x03
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x02
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x01
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x00
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x00
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x03
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x03
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x02
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x02
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x01
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x03
stv0299: stv0299_read_signal_strength : FE_READ_SIGNAL_STRENGTH : AGC2I: 0x858b, signal=0x7a79
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x00
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x04
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x04
stv0299: stv0299_set_frontend : FE_SET_FRONTEND
stv0299: stv0299_set_FEC
stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x03

Does gdb needs to run on dreambox to further debug module, or are some /proc/sys/debug options available, it seems the minisatip 0.4 version doesn't have any debug or verbose options yet?

from dm500-satip.

Hmm, from the dmesg I see that minisatip is correctly issuing the ioctls and the kernel is processing them. So yes, like I said, the next step would probably be to reverse engineer the drivers on the stock firmware (in particular by sniffing their I2C transfers, since the I2C module is open source, and comparing them to the transfers done by our driver).

Although the 0.4 branch had a older date than your 0.4 branch I was able to verify that the DiSEqC code was already working there.

Good. In the README there's a link to my minisatip fork, in particular it shows the differences between upstream 0.4 and the version on dm500-satip. I don't remember touching anything related to DiSEqC, but I may be wrong.

Does gdb needs to run on dreambox to further debug module, or are some /proc/sys/debug options available, it seems the minisatip 0.4 version doesn't have any debug or verbose options yet?

I'd say it had at least some sort of debug system, in the form of command line options and you could adjust the log level.

In any case, you should be able to adjust buildroot to include a gdb / gdbserver to debug further... Or debug the kernel via kgdb.

from dm500-satip.