Thomas It works for me. Fantastic.. Peter Smith On Fri, 2006-06-23 at 00:31 +0200, Thomas Rokamp wrote: > Finally - It is working :D > > After searching the net for about 3-4 hours, I finally found the missing > scripts. So thanks to Patrick Boettcher and his reply to a post in Dec > 2005 > (http://www.linuxtv.org/pipermail/linux-dvb/2005-December/007247.html), > I now have a working firmware for the Hauppauge WinTV-NOVA-T usb2 93004, > rev. C1A2. > > If anyone is interested in the generated firmware file, I have > temporarily uploaded it here: > > http://home.crax.dk/dvb-usb-nova-t-usb2-01.fw > > Would be nice to know, if it is working for other than me... > I have not tested it yet, only seen that it is loaded correctly in linux > and that the frontend is attached. > > Thanks for all the input! > > /Thomas > > > > > > On Thu, 22 Jun 2006, Thomas Rokamp wrote: > > > > > > Ok - I have now managed to sniff the data that goes from the windows PC > > > to the usb unit. > > > I have also with success replayed the stream of data from the Linux pc > > > to the usb unit, making it initialize correctly (using usbreplay) > > > > Excellent! Good work. > > > > > So - I now have an analyzed version of the usbsnoop logfile which can be > > > replayed using usbreplay, so the next step is to find a way to extract > > > the correct data to a file, that the driver autimatically can upload to > > > the usb unit (firmware?) > > > > Yep. > > > > > I have uploaded the analyzed log here: > > > http://home.crax.dk/analyzed.log > > > > > > Anyone who knows what to do? > > > > You need to make a file that the function dvb_usb_get_hexline in the file > > dvb-usb-firmware.c can parse. There may be a tool to help you do this but > > the basic idea is the file contains many records, in each record there is > > an address (on the box) and then a block of data to write there. IIRC > this > > is an 'intel hex format' file. > > > > OK now how do you parse your analyzed.log file? Each line there is a > write > > to some address in the FX2. Look at the first line: the '40 a0' means > > write request. Then there is the address (little-endian) of '00 e6' so > > we're writing to address 0xe600. Then there's an unused field and then > the > > length of the data to write. '01 00' or 0x0001 bytes. Finally you have > the > > actual data that gets written. > > > > Now all you have to do is turn each line from your log into a record in > > the .fw file - easy! > > > > Those first 4 lines that are identical are putting the chip into reset - > > this is handled for you automatically by the firmware uploader so you can > > leave that out of your file. The first interesting line writes 16 > bytes to > > address 0x146c. Same deal with the last 5 for rebooting it. And there's a > > few in the middle that you can probably leave out too... 'tho I'm not > 100% > > sure about that, maybe they are necessary. > > > > Normally when you find firmware like this in a block it starts with '02' > > and ends wiht lots of 'aa's... but I'm glad I didn't suggest that here as > > it looks like it isn't in a block at all in the windows driver files. > > > > > Thanks, > > > Thomas > > > > {P^/ > > > > > _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
