<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">From: Antti P Miettinen <<a href="mailto:ananaza@iki.fi">ananaza@iki.fi</a>><br>To:
<a href="mailto:linux-dvb@linuxtv.org">linux-dvb@linuxtv.org</a><br>Date: Sat, 10 Mar 2007 21:44:37 +0200<br>Subject: [linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel oops...<br>"Henrik Beckman" <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:henrik.list@gmail.com">
henrik.list@gmail.com</a>> writes:<br>> Are there any differences in the windows stream ?<br><br>Well, I've only managed to look at the beginning so far, but there<br>seem to be at least some minor differences.<br>
<br>The trace starts (after some descriptor reads) with firmware<br>loading. The firmware seems to be in more or less Intel hex record [1]<br>format and checked against that assumption I think what I extracted<br>from the trace should be more or less OK. At least the record wise
<br>checksums match.<br><br>There are some messages for which I cannot find any counterparts in<br>the linux driver code. Before the firmware download starts the windows<br>driver sends a five byte bulk packet to EP1:<br>
<br> 02 a1 00 00 08<br><br>and receives eight byte bulk packet:<br><br> d0 40 20 50 99 00 01 05<br><br>Then the firmware is sent just like in linux. Before the jumpram<br>message, there is one 12 byte read:<br><br> 00 00 00 00 70 00 00 00 06 11 60 d4
<br><br>Looks like this contains the start address, maybe some kind of<br>checksum.<br><br>Then some decsriptor reading, setting configs, and then something that<br>looks like the GPIO setting in the linux driver, but there's a small
<br>difference from what is done in bristol_frontend_attach(). If I'm<br>interpreting the log correctly the windows driver is doing the<br>equivalent of:<br><br> dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 1);<br>
dib0700_set_gpio(adap->dev, GPIO9, GPIO_OUT, 0);<br> dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 0);<br> msleep(10);<br> dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 1);<br><br>And then I got tired :-)
<br><br>I'll try deciphering the log more later.<br><br>[1] <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://en.wikipedia.org/wiki/Intel_HEX" target="_blank">http://en.wikipedia.org/wiki/Intel_HEX
</a><br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.iki.fi/%7Eananaza/" target="_blank">http://www.iki.fi/~ananaza/</a><br></blockquote></div><br><br><br>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...).
<br><br>I don't know if this can help you in any way, but in my case the equation is pretty clear:<br><ul><li>EIT = USB disconnect</li><li>No EIT = No USB disconnect</li></ul>:D<br><br>Cheers, and thank you again for your hard work.
<br> Eduard<br><br><br><br><br>