Kernel 3.17.0 broke xc4000-based DTV1800h

Kernel 3.17.0 broke xc4000-based DTV1800h

[Rodney Baker]

Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my 
xc4000/zl10353/cx88 based DTV card has failed to initialise on boot.

The following messages are from dmesg; 

[   78.468221] xc4000: I2C read failed
[   80.074604] xc4000: I2C read failed
[   80.074605] Unable to read tuner registers.
[   82.622062] Selecting best matching firmware (7 bits differ) for type=(0), 
id 000000200000b700:
[   82.626375] i2c i2c-0: sendbytes: NAK bailout.
[  148.063594] xc4000: I2C read failed
[  149.669994] xc4000: I2C read failed
[  149.669995] Unable to read tuner registers.
[  149.670198] cx88[0]/0: registered device video1 [v4l2]
[  149.670287] cx88[0]/0: registered device vbi0
[  149.670338] cx88[0]/0: registered device radio0
[  149.670340] cx88[0]/0: failed to create cx88 audio thread, err=-4
[  149.670382] cx88[0]/2: cx2388x based DVB/ATSC card
[  149.670384] cx8802_alloc_frontends() allocating 1 frontend(s)
[  149.670515] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
[  151.305364] zl10353_read_register: readreg error (reg=127, ret==-6)
[  151.305367] cx88[0]/2: frontend initialization failed
[  151.305369] cx88[0]/2: dvb_register failed (err = -22)
[  151.305370] cx88[0]/2: cx8802 probe failed, err = -22

It worked with 3.16.3-1.gd2bbe7f-desktop on the same machine.

Regards,
Rodney.

-- 
==============================================================
Rodney Baker VK5ZTV
rodney.baker@iinet.net.au
==============================================================

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[Rodney Baker]

Ping? Does anybody have any idea where to star digging on this? 

Sent from my iPad

> On 16 Oct 2014, at 17:33, Rodney Baker <rodney.baker@iinet.net.au> wrote:
> 
> Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my 
> xc4000/zl10353/cx88 based DTV card has failed to initialise on boot.
> 
> The following messages are from dmesg; 
> 
> [   78.468221] xc4000: I2C read failed
> [   80.074604] xc4000: I2C read failed
> [   80.074605] Unable to read tuner registers.
> [   82.622062] Selecting best matching firmware (7 bits differ) for type=(0), 
> id 000000200000b700:
> [   82.626375] i2c i2c-0: sendbytes: NAK bailout.
> [  148.063594] xc4000: I2C read failed
> [  149.669994] xc4000: I2C read failed
> [  149.669995] Unable to read tuner registers.
> [  149.670198] cx88[0]/0: registered device video1 [v4l2]
> [  149.670287] cx88[0]/0: registered device vbi0
> [  149.670338] cx88[0]/0: registered device radio0
> [  149.670340] cx88[0]/0: failed to create cx88 audio thread, err=-4
> [  149.670382] cx88[0]/2: cx2388x based DVB/ATSC card
> [  149.670384] cx8802_alloc_frontends() allocating 1 frontend(s)
> [  149.670515] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
> [  151.305364] zl10353_read_register: readreg error (reg=127, ret==-6)
> [  151.305367] cx88[0]/2: frontend initialization failed
> [  151.305369] cx88[0]/2: dvb_register failed (err = -22)
> [  151.305370] cx88[0]/2: cx8802 probe failed, err = -22
> 
> It worked with 3.16.3-1.gd2bbe7f-desktop on the same machine.
> 
> Regards,
> Rodney.
> 
> -- 
> ==============================================================
> Rodney Baker VK5ZTV
> rodney.baker@iinet.net.au
> ==============================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[István, Varga]

> On 16 Oct 2014, at 17:33, Rodney Baker <rodney.baker <at> iinet.net.au> wrote:
>
> Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my
> xc4000/zl10353/cx88 based DTV card has failed to initialise on boot.

Apparently, the default firmware file name has been changed to
dvb-fe-xc4000-1.4.1.fw,
and the firmware package for the kernel now includes this file from
kernellabs.com.
However, this firmware file is incomplete (only includes minimal DVB-T
support for the
PCTV 340e), and also incompatible with the driver. That is why trying
to load it results
in i2c errors.

To get a firmware file that actually works, download this package, and build it:
  http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz
Actually, it was posted to the linux-media list in the past, but the
file did not end up being
included with the kernel firmware packages for some reason. The include path to
tuner-xc2028-types.h needs to be changed in build_fw.c, since the
"tuners" subdirectory is
now in "drivers/media", rather than "drivers/media/common". After
that, running make will
produce a correct firmware file named dvb-fe-xc4000-1.4.fw.

Some distributions include older firmware files from this page:
  http://istvanv.users.sourceforge.net/v4l/xc4000.html
These are slightly different from the newer one, and are extracted
from the Windows
drivers, rather than from the xc4000_firmwares.h file provided by
Xceive, but should still
work nevertheless.

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[Mauro Carvalho Chehab]

Hi István,

Em Sun, 30 Nov 2014 18:38:24 +0100
"István, Varga" <istvan_v@mailbox.hu> escreveu:

> > On 16 Oct 2014, at 17:33, Rodney Baker <rodney.baker <at> iinet.net.au> wrote:
> >
> > Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my
> > xc4000/zl10353/cx88 based DTV card has failed to initialise on boot.
> 
> Apparently, the default firmware file name has been changed to
> dvb-fe-xc4000-1.4.1.fw,

Actually, changeset da7bfa2c5df3 added support for both names. It tries
first dvb-fe-xc4000-1.4.1.fw. If not found, it falls back to 
dvb-fe-xc4000-1.4.fw.

> and the firmware package for the kernel now includes this file from
> kernellabs.com.

Yeah, Xceive granted a license to redistribute such firmware file via
Hauppauge. The firmware we sent to linux-firmware is this one with
the proper license.

> However, this firmware file is incomplete (only includes minimal DVB-T
> support for the
> PCTV 340e), and also incompatible with the driver. That is why trying
> to load it results
> in i2c errors.

Hmm... I remember I did some tests with PCTV 340e using that firmware
and it works for me.

There were a bug at xc4000 that were causing PCTV 340e to not work,
that got fixed on changeset 4c07e32884ab6957. Basically, get_frequency()
were returning the wrong frequency, with caused dib7000p to adjust IF
to a wrong value. With that change, at least for pctv 340e, xc4000 driver
is working fine.

Such change shouldn't affect devices with zl10153, as this demod doesn't
call tuner's get_frequency().

> 
> To get a firmware file that actually works, download this package, and build it:
>   http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz
> Actually, it was posted to the linux-media list in the past, but the
> file did not end up being
> included with the kernel firmware packages for some reason.

For a firmware to be added at the Kernel firmware, the manufacturer
has to grant a license to redistribute the binaries. I was not aware
that there are actually two different versions of the xc4000 firmware
with the same name. This is a really bad idea.

What we should do is to name those versions differently, and pass the
firmware name as a parameter to the xc4000 attach function.

On a quick look, it seems that those are the devices that use the
xc4000 tuner:

cx23885:
	Leadtek Winfast PxDVR3200 H XC4000
cx88:
	Leadtek WinFast DTV1800 H (XC4000)
	Leadtek WinFast DTV2000 H PLUS

dib0700:
	PCTV 340e

Do you know if the firmware that works with Leadtek devices also work
without any regressions with PCTV 340e? If so, then if Leadtek could
get a license from Xceive to redistribute the firmwares at the Kernel,
we could update the firmware file at the linux-firmware tree.

However, if the firmware doesn't work properly with PCTV 340e and/or
Leadtek/Xceive cannot grant a license to redistribute the other version
of the firmware, the best would be to rename the firmware file used
by Leadtek devices to dvb-fe-xc4000-leadtek-1.4.fw, in order to avoid
confusion.

I won't doubt that the version that works with dib0700 would be different
than the ones that work with other devices, as the IF used on dib0700
could be different (I think most dib0700 devices use a zero-IF tuner).

> The include path to
> tuner-xc2028-types.h needs to be changed in build_fw.c, since the
> "tuners" subdirectory is
> now in "drivers/media", rather than "drivers/media/common". After
> that, running make will
> produce a correct firmware file named dvb-fe-xc4000-1.4.fw.
> 
> Some distributions include older firmware files from this page:
>   http://istvanv.users.sourceforge.net/v4l/xc4000.html
> These are slightly different from the newer one, and are extracted
> from the Windows
> drivers, rather than from the xc4000_firmwares.h file provided by
> Xceive, but should still
> work nevertheless.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[István, Varga]

2014-12-01 10:20 GMT+01:00 Mauro Carvalho Chehab <mchehab@osg.samsung.com>:

> Hi István,
>
> Yeah, Xceive granted a license to redistribute such firmware file via
> Hauppauge. The firmware we sent to linux-firmware is this one with
> the proper license.

Hi, does the license apply specifically to the kernellabs.com firmware file,
or the header files released by Xceive (xc4000_firmwares.h, xc4000_scodes.h) ?
In the latter case, it should cover my firmware file
(dvb-fe-xc4000-1.4.fw) as well,
because it is generated from the same headers. Also, it is no longer generated
from the Leadtek Windows drivers (like it was in the past before I had access to
the Xceive header files), so it should in theory only be licensed by
Xceive, rather
than Leadtek.

> Hmm... I remember I did some tests with PCTV 340e using that firmware
> and it works for me.

>From a quick look at the contents of dvb-fe-xc4000-1.4.1.fw (the kernellabs.com
file), it appears to be missing all the firmware data related to
analog TV and radio
standards, and all scodes are (incorrectly) a copy of the one needed for
int_freq = 5400. Therefore, it only works with the demodulator used on the PCTV
340e, which is using that frequency, but not with the Leadtek cards
with zl10153,
since those require 4560 instead. It also seems to be missing some standard and
firmware type flags. I am not sure if those are responsible for the
I2C errors, or
simply the lack of the analog firmwares. Perhaps the latter if the errors do not
occur with the (currently DVB-only) PCTV 340e.

> Such change shouldn't affect devices with zl10153, as this demod doesn't
> call tuner's get_frequency().

The get_frequency() change is not an issue, the kernellabs.com firmware that is
now the default and part of the kernel packages does not include data that is
required for the Leadtek cards to work.

> However, if the firmware doesn't work properly with PCTV 340e and/or
> Leadtek/Xceive cannot grant a license to redistribute the other version
> of the firmware, the best would be to rename the firmware file used
> by Leadtek devices to dvb-fe-xc4000-leadtek-1.4.fw, in order to avoid
> confusion.

Although I did not test it, the firmware should work with the PCTV 340e as
well. It definitely does with the Leadtek devices in DVB-T mode, and on the
PCTV 340e the only difference is the IF (5400 vs. 4560).

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[Mauro Carvalho Chehab]

Em Mon, 01 Dec 2014 13:24:50 +0100
"István, Varga" <istvan_v@mailbox.hu> escreveu:

> 2014-12-01 10:20 GMT+01:00 Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> 
> > Hi István,
> >
> > Yeah, Xceive granted a license to redistribute such firmware file via
> > Hauppauge. The firmware we sent to linux-firmware is this one with
> > the proper license.
> 
> Hi, does the license apply specifically to the kernellabs.com firmware file,
> or the header files released by Xceive (xc4000_firmwares.h, xc4000_scodes.h) ?

My understanding is that it covers that specific firmware file.

> In the latter case, it should cover my firmware file
> (dvb-fe-xc4000-1.4.fw) as well,
> because it is generated from the same headers. Also, it is no longer generated
> from the Leadtek Windows drivers (like it was in the past before I had access to
> the Xceive header files), so it should in theory only be licensed by
> Xceive, rather
> than Leadtek.

True, just Xceive's SOB would be enough, but in general, it is easier
to get chipset manufacturer's license via the hardware manufacturer
(Leadtek, in this case).

So, we need either someone at Xceive to SOB the patch or someone at Leadtek
that has internally some authorization to release the firmware files in their
behalf.

> 
> > Hmm... I remember I did some tests with PCTV 340e using that firmware
> > and it works for me.
> 
> >From a quick look at the contents of dvb-fe-xc4000-1.4.1.fw (the kernellabs.com
> file), it appears to be missing all the firmware data related to
> analog TV and radio
> standards, and all scodes are (incorrectly) a copy of the one needed for
> int_freq = 5400.

Maybe the scodes are patched for some specific interworking scenario with
dib0700.

> Therefore, it only works with the demodulator used on the PCTV
> 340e, which is using that frequency, but not with the Leadtek cards
> with zl10153,
> since those require 4560 instead. It also seems to be missing some standard and
> firmware type flags. 

I see.

> I am not sure if those are responsible for the
> I2C errors, or
> simply the lack of the analog firmwares. Perhaps the latter if the errors do not
> occur with the (currently DVB-only) PCTV 340e.

Maybe.

> > Such change shouldn't affect devices with zl10153, as this demod doesn't
> > call tuner's get_frequency().
> 
> The get_frequency() change is not an issue,

It used to be for PCTV 340e before the fixup patch, after some changes that
happened at dib0700 driver.

> the kernellabs.com firmware that is
> now the default and part of the kernel packages does not include data that is
> required for the Leadtek cards to work.

I see.
> 
> > However, if the firmware doesn't work properly with PCTV 340e and/or
> > Leadtek/Xceive cannot grant a license to redistribute the other version
> > of the firmware, the best would be to rename the firmware file used
> > by Leadtek devices to dvb-fe-xc4000-leadtek-1.4.fw, in order to avoid
> > confusion.
> 
> Although I did not test it, the firmware should work with the PCTV 340e as
> well. It definitely does with the Leadtek devices in DVB-T mode, and on the
> PCTV 340e the only difference is the IF (5400 vs. 4560).

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[Devin Heitmueller]

> My understanding is that it covers that specific firmware file.

In this case the license was actually against the header file.  I was
responsible for generating the binary blob based on the header files
in the Xceive sources (and got the appropriate permission).  There
should be no licensing issue generating a second blob that includes
the analog standards (I just never got around to it because I didn't
analog support and hence couldn't test the result).

If somebody wants to send me an updated blob, I'm happy to host a copy
at kernellabs.com alongside the file that is currently there (please
make sure it has a different filename though).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[István, Varga]

2014-12-01 15:15 GMT+01:00 Devin Heitmueller <dheitmueller@kernellabs.com>:

> If somebody wants to send me an updated blob, I'm happy to host a copy
> at kernellabs.com alongside the file that is currently there (please
> make sure it has a different filename though).

My firmware package is available here:
  http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz
The only relevant files are build_fw.c and the two original headers from Xceive
(xc4000_*.h). Although other programs for extracting the firmware from the
Windows drivers are also included, they are no longer needed.

To compile build_fw.c on current kernels without errors, the include path to
tuner-xc2028-types.h needs to be fixed at line 11. Other than that, it should
work without problems. It takes one optional command line argument, which
is the name of the output file.

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[István, Varga]

2014-12-01 15:15 GMT+01:00 Devin Heitmueller <dheitmueller@kernellabs.com>:

> If somebody wants to send me an updated blob, I'm happy to host a copy
> at kernellabs.com alongside the file that is currently there (please
> make sure it has a different filename though).

It would probably be the least confusing to users if the updated
firmware was simply named "dvb-fe-xc4000-1.4.2.fw", as it is a
fixed/more complete version built from the same Xceive 1.4 source
files.

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[István, Varga]

2014-12-01 13:52 GMT+01:00 Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> Em Mon, 01 Dec 2014 13:24:50 +0100
> "István, Varga" <istvan_v@mailbox.hu> escreveu:
>> I am not sure if those are responsible for the
>> I2C errors, or
>> simply the lack of the analog firmwares. Perhaps the latter if the errors do not
>> occur with the (currently DVB-only) PCTV 340e.
>
> Maybe.

The driver searches for the firmware image that matches the selected analog TV
standard the best, and if the firmware file does not include any, then
it currently
attempts to load whatever else is found (for example, the base firmware).
This problem should perhaps be fixed, although the ideal solution is
to provide a
complete firmware file.

Re: Kernel 3.17.0 broke xc4000-based DTV1800h

[István, Varga]

By the way, from the xc4000_firmware.tar.gz package, the only files
that are actually needed are:
  build_fw.c (source code of simple program to write the firmware file)
  xc4000_firmwares.h (header file from Xceive)
  xc4000_scodes.h (also from Xceive)

Everything else is related to extracting the firmware from Windows drivers,
and was included only for completeness.

The license for the Xceive header files can be found here:
  http://www.kernellabs.com/firmware/xc4000/README.xc4000