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
> >
> > > Hopefully something in there can help.
> > >
> > > I'll try out the Windows tools and see if they can extract the
> > > firmware and
> > > so forth.
> > >
> > > Regards,
> > >
> > > Josh
> >
> > _______________________________________________
> > ivtv-users mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
> 
> _______________________________________________
> ivtv-users mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
> 


_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Reply via email to