Mailing List Archive

Test message and new firmware extractor script: ivtvfwextract
There's already a system utility on your machine that does the
equivalent of extract-fw.c, called "dd":
dd if=/home/tmk/driver.sys of=/tmp/enc-fw.bin bs=1 count=256k skip=710648

But you shouldn't need to know offset and whatnot, you should
just need to run a single script to do it all for you.

Attached is a perl-script that uses the (required, but quite
common) "unzip" utility to extract the encoder and decoder
images. By default it looks in /mnt/cdrom and "find"s
pvr48xxx.exe and extracts hcwpvrp2.sys and searches for the
magic bytes for the encoder and decoder images, and writes them
(just by default) to /lib/modules/ivtv-enc-fw.bin and
/lib/modules/ivtv-dec-fw.bin respectively. Point it to a file
(presumably pvr48xxx.exe-like) and it extracts hcwpvrp2.sys
from that. Other examples:
ivtvfwextract pvr48xxx.exe
ivtvfwextract /mnt/cdrom /tmp/enc.img /tmp/dec.img

The script refuses to write any images if it finds multiple
encoder or decoder images.

Beware: I tried it on the downloaded pvr48_1620352.exe from
Hauppauge, but it seems there are actually *two* encoder images
in the hcwpvrp2.sys in that file; one at offset 0x74538 (version
2.02.021) and one at offset 0xb4538 (version 2.02.203). I
verified using emacs hexl-mode, so it's not just a bug in the
script. Clues? Should it work on that file, and if so, which
encoder image should it choose?

Ok to commit to ivtv/ivtv/utils?

(What's with the two ivtv:s? Fingers slipped during
cvs import? ;-) (I certainly recognize this pitfall.)

brgds, H-P