Re: Nova-T 500 Channel scanning + EIT + Kernel oops...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm using VDR. Could someone with more understanding tell me, can EIT
be disabled in VDR? Or, alternatively, give an educated guess why
enabling EIT causes USB disconnects?

On 3/11/07, Eduard Huguet <eduardhc@xxxxxxxxx> wrote:
>
> From: Antti P Miettinen <ananaza@xxxxxx>
> To: linux-dvb@xxxxxxxxxxx
> Date: Sat, 10 Mar 2007 21:44:37 +0200
> Subject:  Re: Nova-T 500 Channel scanning + EIT + Kernel
> oops...
> "Henrik Beckman" <henrik.list@xxxxxxxxx> writes:
> > Are there any differences in the windows stream ?
>
> Well, I've only managed to look at the beginning so far, but there
> seem to be at least some minor differences.
>
> The trace starts (after some descriptor reads) with firmware
> loading. The firmware seems to be in more or less Intel hex record [1]
> format and checked against that assumption I think what I extracted
> from the trace should be more or less OK. At least the record wise
> checksums match.
>
> There are some messages for which I cannot find any counterparts in
> the linux driver code. Before the firmware download starts the windows
> driver sends a five byte bulk packet to EP1:
>
>  02 a1 00 00 08
>
> and receives eight byte bulk packet:
>
>  d0 40 20 50 99 00 01 05
>
> Then the firmware is sent just like in linux. Before the jumpram
> message, there is one 12 byte read:
>
>  00 00 00 00 70 00 00 00 06 11 60 d4
>
> Looks like this contains the start address, maybe some kind of
> checksum.
>
> Then some decsriptor reading, setting configs, and then something that
> looks like the GPIO setting in the linux driver, but there's a small
> difference from what is done in bristol_frontend_attach(). If I'm
> interpreting the log correctly the windows driver is doing the
> equivalent of:
>
>  dib0700_set_gpio(adap->dev, GPIO6,  GPIO_OUT, 1);
>  dib0700_set_gpio(adap->dev, GPIO9,  GPIO_OUT, 0);
>  dib0700_set_gpio(adap->dev, GPIO10,  GPIO_OUT, 0);
>  msleep(10);
>  dib0700_set_gpio(adap->dev, GPIO10,  GPIO_OUT, 1);
>
> And then I got tired :-)
>
> I'll try deciphering the log more later.
>
> [1] http://en.wikipedia.org/wiki/Intel_HEX
>
> --
> http://www.iki.fi/~ananaza/ <http://www.iki.fi/%7Eananaza/>
>



Just as a matter of update, I've reenabled EIT scanning in MythTV just for
testing. It took less than 5 min to get a kernel oops due to the USB
disconnect ("dmesg | grep disconn" was explicit enough...).

I don't know if this can help you in any way, but in my case the equation is
pretty clear:

   - EIT = USB disconnect
   - No EIT = No USB disconnect

:D

Cheers, and thank you again for your hard work.
  Eduard



--
jussi

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux