[linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel oops...

Antti P Miettinen ananaza at iki.fi
Sat Mar 10 20:44:37 CET 2007


"Henrik Beckman" <henrik.list at gmail.com> 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/




More information about the linux-dvb mailing list