<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">From:&nbsp;Antti P Miettinen &lt;<a href="mailto:ananaza@iki.fi">ananaza@iki.fi</a>&gt;<br>To:&nbsp;
<a href="mailto:linux-dvb@linuxtv.org">linux-dvb@linuxtv.org</a><br>Date:&nbsp;Sat, 10 Mar 2007 21:44:37 +0200<br>Subject:&nbsp;[linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel oops...<br>&quot;Henrik Beckman&quot; &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:henrik.list@gmail.com">
henrik.list@gmail.com</a>&gt; writes:<br>&gt; Are there any differences in the windows stream ?<br><br>Well, I&#39;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> &nbsp;02 a1 00 00 08<br><br>and receives eight byte bulk packet:<br><br> &nbsp;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> &nbsp;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&#39;s a small
<br>difference from what is done in bristol_frontend_attach(). If I&#39;m<br>interpreting the log correctly the windows driver is doing the<br>equivalent of:<br><br> &nbsp;dib0700_set_gpio(adap-&gt;dev, GPIO6, &nbsp;GPIO_OUT, 1);<br>
 &nbsp;dib0700_set_gpio(adap-&gt;dev, GPIO9, &nbsp;GPIO_OUT, 0);<br> &nbsp;dib0700_set_gpio(adap-&gt;dev, GPIO10, &nbsp;GPIO_OUT, 0);<br> &nbsp;msleep(10);<br> &nbsp;dib0700_set_gpio(adap-&gt;dev, GPIO10, &nbsp;GPIO_OUT, 1);<br><br>And then I got tired :-)
<br><br>I&#39;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&#39;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 (&quot;dmesg | grep disconn&quot; was explicit enough...).
<br><br>I don&#39;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>&nbsp; Eduard<br><br><br><br><br>