"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/ _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
