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

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

 



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/



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:
:D

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




_______________________________________________
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