I received this today from Mark Weaver: Mark Weaver wrote: >Josh Becigneul wrote:
>> Hello, I am writing to ask about support for the lirc_pvr150 package >>while used with the HVR-1600 capture card. The reciever code works, and we >> are attempting to generate a .bin file for use with it. The files >>generated by your Windows utility appear correct at first, but lack the >>data portion. I'm starting to guess that the tool "parseLog.pl" is what >>inserts the data, but I am not sure what other file is needed. Here is an >>example of the output of the program on my machine: >It needs a log file from the driver, which is generated using dbgview and >a hacked version of the pvr150 driver. The driver from hauppauge contains > a whole load of debug trace information, which includes all the i2c traffic, > and this is the information that parseLog.pl is after. The hack I think >just turns the debug flag on in the driver binary. I can try to replicate >this with the hvr1600 driver if you don't know anyone good with a disassembler! >> Other <data></data> blocks are the same, empty, and the file is only >>1084KB. Any help you can lend would be greatly appreciated. We have a >>discussion >going on the ivtv-users mailing list. >Feel free to cc: me in future in case I can be any more help. >Mark On Sun, 13 Jul 2008 09:58:40 -0400, Andy Walls <[EMAIL PROTECTED]> wrote: > On Sun, 2008-07-13 at 10:43 +0200, Hans Verkuil wrote: >> On Sunday 13 July 2008 06:01, Josh Becigneul wrote: >> > Well, I've compiled the utility for extracting the firmware, ran it >> > successfully, and compared the file generated against the one from >> > http://www.blushingpenguin.com/svn/trunk/3rdparty/lirc/tools/pvr150/ >> > >> > Original, meant for the PVR-150: >> > >> > <?xml version="1.0" encoding="utf-8"?> >> > <!DOCTYPE codeset-data SYSTEM "IRcodesets.dtd"> >> > <codeset-data version="API=2.4, FW=1.3.0"> >> > <boot> >> > >> > <data>6000015B02044B1A7988B11F87F51661A6D9EC9A0FA7AB27489D7E1AD90C0 >> >E489177D63D09441860E512C66CBA32C426E3760148A27D815990288F487961B40A0B5 >> >7216E0078AD62B568A227424EDA6C94630E2A1A303B45FA3425E5CB1EC1EE000000</d >> >ata> </boot> >> > >> > The new one that I generated for the HVR-1600: >> > >> > <?xml version="1.0" encoding="utf-8"?> >> > <!DOCTYPE codeset-data SYSTEM "IRcodesets.dtd"> >> > <codeset-data version="API=2.4, FW=2.1.0"> >> > <boot> >> > <data> >> > </data> >> > </boot> >> > >> > As you can see, something between the -150 and -1600 is different. >> > The utility would have to be modified in order to generate the >> > required data. I'll try and see if I can. >> > >> > Would Hauppauge be helpful with this? They've allowed redistribution >> > of the firmware, and there is a Windows utility available, so in my >> > opinion, it shouldn't be a big deal. >> >> Probably not. The IR firmware code is third-party and as such not under >> the control of Hauppauge. > > > And on top of that, it's not really firmware. What Mark's utility > builds is a snapshot of the message traffic of a Zilog API while it's > setting up the IR blaster function and sending codes. > > The actual IR firmware is, for the most part, burned into the flash of > the Zilog Chip. It's technically extractable with a lot of work. > > It looks like Mark developed his code to develop snapshots of the API > traffic with a bit of reverse engineering of the Hauppauge and Zilog > provided Windows drivers. I think the driver file names may have > changed, but some of those names look hard-coded in mark's VB code. > > Also, we still might just have I2C problems in the cx18 driver and > nothing else. I'll have a chance to start playing with this come > Friday. (I have no means to compile and run Mark's VB code on a Windows > platform.) > > Thanks for your efforts so far. > > Regards, > Andy > > >> Regards, >> >> Hans >> >> > >> > Regards, >> > >> > Josh >> > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
