What is the status of the Montage-3103b.v2 Branch?

[JMS-1]

As an owner of two TechnoTrend S2-4600 boxes which are currently not working under Ubuntu 18.04.3 (Chip_Id=38 unknown, no frontend0 device) I was wondering if your fix has been confirmed - I tried to follow your long discussion with CvH but I'm not sure about the outcome. I'm a bit concerned since the problematic Chip_Id in the discussion was 52 and not 38 - I opened one of my boxes and there is indeed a M88DS3103B installed, so what's the deal?

And more important: if the fix is working (and able to detect and support both pre- and post-2018 versions of the hardware correctly) will it find it's way to the media_tree master and to Ubuntu as well?

Regards

Jochen

[b-rad-NDi]

My driver is (was) confirmed working for many end users. However, I broke something, and now there is an issue I am working to determine now. Any vendor that does not change their usb vid:pid when they change internal chips is out of luck.

[JMS-1]

But as I understand for S2-4600 it will be working - even if vid:pid has not been changed in the 2018+ version of the hardware?

What is the behaviour of the broken issue?

Thanks so far!

[b-rad-NDi]

Read the issue reports here. I do not have access to any satellite signals.

There is no auto detection of chips. The 3103 and 3103b operate completely differently. You need to explicitly tell a driver to use 3103b. The downstream ds3k driver is full of wacky work arounds and would never be accepted upstream.

[JMS-1]

How do you (or CvH?) even find out how to operate the new hardware? Is there some kind of operation manual for the chipset (I found only a data sheet for the M88DS3103 from 2010 but nothing for the B) since it doesn't seem to be "fairly equal" - at least to me if I look at your commited changes? Where does the firmware come from - so how well known is what the driver is working against / with?

In your discussion with CvH (and what he did before on the other forum) it seems to me as if the ds3k driver at least got it working. Do I understand your work right (sorry - Linux driver noob) that you tried to detect the different hardware by probing it multiple times (with different firmware) and then porting the ds2k stuff making it "upstream approvable"? I'm not quite sure if I interpret the init/probe cycles correctly but since the chip_id validation is still in the probe I guessed that the new firmware will differ at least from the vendors one to report the expected old (3103-non-B) id - in fact: wouldn't this the point to detect the different chipset (again I'm stubmling because my id is NOT 52 but 38)? As I understand the firmware is loaded in prior so this doesn't feel to be possible at all but then again: what is this new firmware?

Regards

Jochen

[b-rad-NDi]

Apparently it works. I just fudged up the board config in the bridge driver.

I have no datasheet and it's doubtful Montage would give me one, my bosses have already asked.

I produced my modifications by instrumenting downstream and upstream drivers, then painstakingly figuring out what's different.

Determining that the chip is a 3103b and sending it the correct firmware is probably the easiest part. The entire custom clocking features of a daughter i2c chip was the source of difficulties.

[b-rad-NDi]

btw, your S2-4600, if it actually has identical usb vid:pid will have to do something non-standard and have the bridge driver determine the i2c address of the demod and whether it's a 3103 or 3103b. The fact that a single usb vid:pid can have different i2c addresses for different versions of a demod means that the "old and deprecated" dvb_attach function has to be used. New drivers rightfully aren't allowed to use such kludgy hacks anymore, they create i2c_devices.

I left this issue open to remind me to at least give a look at the bridge driver for your device to see if I can get it working.

[b-rad-NDi]

Also, I don't really know what device you have, but if it's the one I just merged a pull request for--then it should work if you compile my Montage-3103b.v3 branch.

If it does please let me know so I can close this issue.

[JMS-1]

I'll give it a try as soon as I can - not experienced in this field. Currently I'm running Ubuntu 19.10.

But: if it's working for others you should try to upstream the branch as soon as possible - concerning this specific device I've seen reports on it not working since early 2018! Although I do currently not fully understand if you are supporting both variants connected to the same machine - which might be an additional issue at least for me (4x3103 + 1x3103b).

[b-rad-NDi]

Upstreaming "as soon as possible" is not as fast as you are imagining I fear.

First off the code has to be proven actually working. Next it has to be sent to the mailing list, then it gets the long process of awaiting reviews and comments, then barring any show stoppers and after I've fixed any issues brought up the whole process starts again until it makes everyone happy.

We're still at step one.

As far as suppporting both chip versions if you are running hauppauge 461e then you can have as many of either revision as you desire, because there is different vid:pid and therefore everything correctly loads.

[JMS-1]

Thank you for your answers and patience! But as far as I understand I may be kind of lost. The four active devices (guess 3103) report as 0b48:3011 in lsusb AND THE two (guess 3103b) as well. In the startup code the chip_id is reported (line 1822) as 38 and unsupported for these two devices - must be 70 for the other four (funny - twice the value, must be by luck).

[b-rad-NDi]

How about you attach your full dmesg here. If I can quickly hobble up something to support your device I will. The more devices I can included in my upstream series the better.

[JMS-1]

No problem. one_bad is my development system with one 3103B connected (sure, opened it), the other my production SAT>IP server with four 3103 (educated guess since it's working AND in addition these are quite old, definitly older than two years).

Regards

Jochen

dmesg_four_good.zip dmesg_one_bad.zip

PS: the log of the four_good is a bit weird, since only three firmware downloads are reported. All four devices are functional.

[b-rad-NDi]

Your device is most likely sorted out by commits contributed by someone here. They're included in both my v2 and v3 branches. If you compile my v3 branch your device should work.

Note, you require a firmware file: dvb-fe-ds3103.fw

[JMS-1]

Thanks, that's good news. I'll try to find a block of time to test - maybe on the weekend.

So long

Jochen

[b-rad-NDi]

If you test and find you're sorted out lemme know and one of us can close this issue.

[JMS-1]

Sorry, but to do so I've some questions. First about the code: since I'm doing this the first time I thought using media-build should be a good idea. After embedding your changes there is one complaint (warning, may be ok, you'll know):

m88ds3103.c:908:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (dev->chiptype == M88DS3103_CHIPTYPE_3103B) {

Indeed there is no break or explicit goto which could be fine - is it?

But there is a real error which may induce that I'd better choose another path to build:

em28xx-dvb.c:47:10: fatal error: drx39xyj/drx39xxj.h: No such file or directory #include "drx39xyj/drx39xxj.h"

I think this is related to the build concept inside the media-build environment. Although I'm a bit wondering why it worked before (build master sucessfully). For the test I'll change the #include to reference the symbolic link which seems to work fine.

In addition there is something about the firmware files.

1. My system already has a dvb-fe-ds3103.fw [and a dvb-demod-m88ds3103.fw]. Do I have to get a new one?
2. I can see no dvb-fe-ds3103.fw reference in your branch. Do I miss something?
3. On the other hand I can see references to dvb-demod-m88ds3103b.fw, dvb-demod-m88ds3103.fw and dvb-demod-m88rs6000.fw. What is the correct place to get these? https://github.com/CoreELEC/dvb-firmware/tree/master/firmware seems to be a good start. But there is no dvb-fe-ds3103.fw which could be from https://github.com/OpenELEC/dvb-firmware/tree/master/firmware. I think that has to do with file maintenance / ownership but I would like to be sure before using wrong firmware.

Thank you very much in advance for any clearification!

Jochen

[JMS-1]

Interim result - will start testing in the next few days: the device is detected and seems to be functional. [Special test will be a mixed mode access to S2-4600 with old and new chipset at the same time connected to the system.]

dmesg output contains some strange errors (and expected warnings due to the replaced media-tree modules). I uploaded it below just if you want to check.

Some hope! Thank you

Jochen

dmesg_b.zip

[b-rad-NDi]

definitely a lot of bridge errors reported. No visible failures in the demod driver though, so unsure why the bridge is unhappy.

[JMS-1]

Ok, so first thing I did was a full transponder scan. In regular read mode there seem to be no more of these.

[JMS-1]

So maybe some bad news: I took an old (3103) device from my SAT>IP setup and although it is detected correctly with the new driver it doesn't get a signal. Could it be a mess with the firmwares - see above, I tried some different combinations of "what-worked-before" / OpenELEC / CoreELEC without any success [to be honest: I did no binary compare and I'm still guessing most of it to be identical].

I connected the 3103 back to the SAT>IP and it's still working. So I think is is neither a general hardware or connection issue.

Any idea?

dmesg_old.zip

[JMS-1]

Hm, 3103 does not work in vanilla Ubuntu 19.10 (Kernel 5.3.0.26) as well! So I may need to investigate further what happens.

Regards

Jochen

dmsg_1910.zip

[JMS-1]

I tested various version of the kernel down to 5.0.0 but with 19.10 I do not get the 3103 running - so I think this is definitly not related to your code. Currently I've some more ideas how to investigate but honestly I'm out ouf ideas - at leat 18.04 with 5.0 still is runnig fine.

At least good on the 1303B side

Jochen

[stpf99]

for 3103b you must use this firmware file: https://github.com/CoreELEC/dvb-firmware/blob/master/firmware/dvb-demod-m88ds3103b.fw

[JMS-1]

Thanks! That's what I use and currently 3103B is absolutly fine.

I have some trouble with 3103 but after quite of bit of investigation (various kernel versions down to 5.0.0, code review of changes, ...) I'm sure the problem is somewhere here - cabling, power supply, ...

The modified driver correctly detects the 3103 and seems to send the correct commands but the device does not lock on the signal. But there is no indication at all that is is related to the driver, so we're good. I even installed a virtual machine with 18.04 and 5.0.0.37 (identical to my working production system which also provides the firmware files) which shows the same behavior.

Although I'm still in a bit of trouble on my side for me this issue could be closed.

Thanks a lot b-rad-NDi! Hopefully your fix will find it's way into Ubuntu in the more or less near future.

Jochen

[b-rad-NDi]

It's close to being submitted upstream :)

[JMS-1]

Final note: it's working with 5.7rc1. Thanks a lot again!

[b-rad-NDi]

hey @JMS-1 : If you find any satellites that do not work please contact me, my utility eeprom-tinker can change the usb transport mode and optimize device operations.