| Message ID | 1406059938-21141-2-git-send-email-zzam@gentoo.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Moikka Matthias On 07/22/2014 11:12 PM, Matthias Schwarzott wrote: > Signed-off-by: Matthias Schwarzott <zzam@gentoo.org> > --- > Documentation/dvb/get_dvb_firmware | 33 ++++++++++++++++++++++++++++++++- > 1 file changed, 32 insertions(+), 1 deletion(-) > > diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware > index d91b8be..26c623d 100755 > --- a/Documentation/dvb/get_dvb_firmware > +++ b/Documentation/dvb/get_dvb_firmware > @@ -29,7 +29,7 @@ use IO::Handle; > "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", > "lme2510c_s7395_old", "drxk", "drxk_terratec_h5", > "drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv", > - "drxk_terratec_htc_stick", "sms1xxx_hcw"); > + "drxk_terratec_htc_stick", "sms1xxx_hcw", "si2165"); > > # Check args > syntax() if (scalar(@ARGV) != 1); > @@ -783,6 +783,37 @@ sub sms1xxx_hcw { > $allfiles; > } > > +sub si2165 { > + my $sourcefile = "model_111xxx_122xxx_driver_6_0_119_31191_WHQL.zip"; > + my $url = "http://www.hauppauge.de/files/drivers/"; > + my $hash = "76633e7c76b0edee47c3ba18ded99336"; > + my $fwfile = "dvb-demod-si2165.fw"; > + my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); > + > + checkstandard(); > + > + wgetfile($sourcefile, $url . $sourcefile); > + verify($sourcefile, $hash); > + unzip($sourcefile, $tmpdir); > + extract("$tmpdir/Driver10/Hcw10bda.sys", 0x80788, 0x81E08-0x80788, "$tmpdir/fw1"); > + > + delzero("$tmpdir/fw1","$tmpdir/fw1-1"); > + #verify("$tmpdir/fw1","5e0909858fdf0b5b09ad48b9fe622e70"); > + > + my $CRC="\x0A\xCC"; > + my $BLOCKS_MAIN="\x27"; > + open FW,">$fwfile"; > + print FW "\x01\x00"; # just a version id for the driver itself > + print FW "\x9A"; # fw version > + print FW "\x00"; # padding > + print FW "$BLOCKS_MAIN"; # number of blocks of main part > + print FW "\x00"; # padding > + print FW "$CRC"; # 16bit crc value of main part > + appendfile(FW,"$tmpdir/fw1"); I have to say I little bit dislike that kind of own headers. There is no way to read firmware version from binary itself (very often there is)? Whats is benefit of telling how many blocks there is? Isn't it possible to detect somehow by examining firmware image itself runtime? Anyhow, you are the author of that driver and even I don't personally like those, I think it is up to your decision as a author. regards Antti > + > + "$fwfile"; > +} > + > # --------------------------------------------------------------- > # Utilities > >
On 23.07.2014 11:20, Antti Palosaari wrote: > Moikka Matthias > Moikka Antti, > On 07/22/2014 11:12 PM, Matthias Schwarzott wrote: >> + >> + my $CRC="\x0A\xCC"; >> + my $BLOCKS_MAIN="\x27"; >> + open FW,">$fwfile"; >> + print FW "\x01\x00"; # just a version id for the driver itself >> + print FW "\x9A"; # fw version >> + print FW "\x00"; # padding >> + print FW "$BLOCKS_MAIN"; # number of blocks of main part >> + print FW "\x00"; # padding >> + print FW "$CRC"; # 16bit crc value of main part >> + appendfile(FW,"$tmpdir/fw1"); > > I have to say I little bit dislike that kind of own headers. There is no > way to read firmware version from binary itself (very often there is)? > Whats is benefit of telling how many blocks there is? Isn't it possible > to detect somehow by examining firmware image itself runtime? > > Anyhow, you are the author of that driver and even I don't personally > like those, I think it is up to your decision as a author. > I thought a bit about the need for the header. And yes, some fields I can get rid of. firmware version: I guess that the exact version number is not really needed - it is just written to a seperate register - and later only read to check if firmware was already downloaded (but for documentation it might be interesting). I have no clue where it could be in the raw block - it looks like it is writing to just some memory addresses. But for the pure process it would also work to write a random number != 0x00. For $BLOCKS_MAIN: The firmware is downloaded like this: * write 1 block * reset crc logic * write $BLOCKS_MAIN * read out crc and compare against $CRC in header * write last 5 blocks so the number of blocks in $BLOCKS_MAIN could be checked by iterating over all blocks counting them and then substracting 6. The crc value: It protects the content of the file until it is in the demod - so calculating it on my own would only check if the data is correctly transferred from the driver into the chip. But for this I needed to know the algorithm and which data is checksummed exactly. Are the different algorithms for CRC values that give 16 bit of output? Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 23 Jul 2014 21:03:14 +0200 Matthias Schwarzott <zzam@gentoo.org> wrote: [...] > The crc value: > It protects the content of the file until it is in the demod - so > calculating it on my own would only check if the data is correctly > transferred from the driver into the chip. > But for this I needed to know the algorithm and which data is > checksummed exactly. > > Are the different algorithms for CRC values that give 16 bit of output? > You could try jacksum[1] and see if any algorithm it supports gives you the expected result, there is a handful of 16 bits ones: jacksum -a all -F "#ALGONAME{i} = #CHECKSUM{i}" payload.bin Ciao, Antonio [1] http://www.jonelo.de/java/jacksum/
On 23.07.2014 22:10, Antonio Ospite wrote: > On Wed, 23 Jul 2014 21:03:14 +0200 > Matthias Schwarzott <zzam@gentoo.org> wrote: > > [...] >> The crc value: >> It protects the content of the file until it is in the demod - so >> calculating it on my own would only check if the data is correctly >> transferred from the driver into the chip. >> But for this I needed to know the algorithm and which data is >> checksummed exactly. >> >> Are the different algorithms for CRC values that give 16 bit of output? >> > > You could try jacksum[1] and see if any algorithm it supports > gives you the expected result, there is a handful of 16 bits ones: > > jacksum -a all -F "#ALGONAME{i} = #CHECKSUM{i}" payload.bin > Hi Antonio, I tried jacksum on the complete firmware and on parts - but it never matched the results from the chip. I now found out, that the crc register changes after every 32bit write to the data register - the fw control registers do not affect it. So I can try what crc results from writing 32bit portions of data. But even that did not help in guessing the algorithm, because I do not want to do 100s of experiments. some of my experiments: crc=0x0000, data=0x00000000 -> crc=0x0000 crc=0x0000, data=0x00000001 -> crc=0x1021 crc=0x0000, data=0x00000002 -> crc=0x2042 crc=0x0000, data=0x00000004 -> crc=0x4084 crc=0x0000, data=0x00000008 -> crc=0x8108 crc=0x0000, data=0x00000010 -> crc=0x1231 Is there some systematic way to get the formula? I can write arbitrary data and check what crc it results in. I don't know if it is worth using the crc algorithm compared to storing the crc with the firmware, because currently it is an end to end verification of firmware data. Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 29 Jul 2014 07:37:44 +0200 Matthias Schwarzott <zzam@gentoo.org> wrote: > On 23.07.2014 22:10, Antonio Ospite wrote: > > On Wed, 23 Jul 2014 21:03:14 +0200 > > Matthias Schwarzott <zzam@gentoo.org> wrote: > > > > [...] > >> The crc value: > >> It protects the content of the file until it is in the demod - so > >> calculating it on my own would only check if the data is correctly > >> transferred from the driver into the chip. > >> But for this I needed to know the algorithm and which data is > >> checksummed exactly. > >> > >> Are the different algorithms for CRC values that give 16 bit of output? > >> > > > > You could try jacksum[1] and see if any algorithm it supports > > gives you the expected result, there is a handful of 16 bits ones: > > > > jacksum -a all -F "#ALGONAME{i} = #CHECKSUM{i}" payload.bin > > > Hi Antonio, > > I tried jacksum on the complete firmware and on parts - but it never > matched the results from the chip. > > I now found out, that the crc register changes after every 32bit write > to the data register - the fw control registers do not affect it. > > So I can try what crc results from writing 32bit portions of data. > But even that did not help in guessing the algorithm, because I do not > want to do 100s of experiments. > > some of my experiments: > crc=0x0000, data=0x00000000 -> crc=0x0000 > crc=0x0000, data=0x00000001 -> crc=0x1021 > crc=0x0000, data=0x00000002 -> crc=0x2042 > crc=0x0000, data=0x00000004 -> crc=0x4084 > crc=0x0000, data=0x00000008 -> crc=0x8108 > crc=0x0000, data=0x00000010 -> crc=0x1231 > > Is there some systematic way to get the formula? I don't know much about crc, but the values you are getting look like the entries in the table in lib/crc-itu-t.c so maybe compare the crc you are getting with the ones calculated with crc_itu_t() from include/linux/crc-itu-t.h I just did a quick test with jacksum, the crc-itu-t parameters can be expressed like this: jacksum -x -a crc:16,1021,0,false,false,0 -q 00000010 and the output is the expected 0x1231 for the 0x00000010 sequence. [...] Ciao, Antonio
On 07/29/2014 11:53 AM, Antonio Ospite wrote: > On Tue, 29 Jul 2014 07:37:44 +0200 > Matthias Schwarzott <zzam@gentoo.org> wrote: > >> On 23.07.2014 22:10, Antonio Ospite wrote: >>> On Wed, 23 Jul 2014 21:03:14 +0200 >>> Matthias Schwarzott <zzam@gentoo.org> wrote: >>> >>> [...] >>>> The crc value: >>>> It protects the content of the file until it is in the demod - so >>>> calculating it on my own would only check if the data is correctly >>>> transferred from the driver into the chip. >>>> But for this I needed to know the algorithm and which data is >>>> checksummed exactly. >>>> >>>> Are the different algorithms for CRC values that give 16 bit of output? >>>> >>> >>> You could try jacksum[1] and see if any algorithm it supports >>> gives you the expected result, there is a handful of 16 bits ones: >>> >>> jacksum -a all -F "#ALGONAME{i} = #CHECKSUM{i}" payload.bin >>> >> Hi Antonio, >> >> I tried jacksum on the complete firmware and on parts - but it never >> matched the results from the chip. >> >> I now found out, that the crc register changes after every 32bit write >> to the data register - the fw control registers do not affect it. >> >> So I can try what crc results from writing 32bit portions of data. >> But even that did not help in guessing the algorithm, because I do not >> want to do 100s of experiments. >> >> some of my experiments: >> crc=0x0000, data=0x00000000 -> crc=0x0000 >> crc=0x0000, data=0x00000001 -> crc=0x1021 >> crc=0x0000, data=0x00000002 -> crc=0x2042 >> crc=0x0000, data=0x00000004 -> crc=0x4084 >> crc=0x0000, data=0x00000008 -> crc=0x8108 >> crc=0x0000, data=0x00000010 -> crc=0x1231 >> >> Is there some systematic way to get the formula? > > I don't know much about crc, but the values you are getting look like > the entries in the table in lib/crc-itu-t.c so maybe compare the crc > you are getting with the ones calculated with crc_itu_t() from > include/linux/crc-itu-t.h > > I just did a quick test with jacksum, the crc-itu-t parameters can > be expressed like this: > > jacksum -x -a crc:16,1021,0,false,false,0 -q 00000010 > > and the output is the expected 0x1231 for the 0x00000010 sequence. maybe crc = crc + crc(val) Antti
On 29.07.2014 13:34, Antti Palosaari wrote: > > > On 07/29/2014 11:53 AM, Antonio Ospite wrote: >> On Tue, 29 Jul 2014 07:37:44 +0200 >> Matthias Schwarzott <zzam@gentoo.org> wrote: >> >>> On 23.07.2014 22:10, Antonio Ospite wrote: >>>> On Wed, 23 Jul 2014 21:03:14 +0200 >>>> Matthias Schwarzott <zzam@gentoo.org> wrote: >>>> >>>> [...] >>>>> The crc value: >>>>> It protects the content of the file until it is in the demod - so >>>>> calculating it on my own would only check if the data is correctly >>>>> transferred from the driver into the chip. >>>>> But for this I needed to know the algorithm and which data is >>>>> checksummed exactly. >>>>> >>>>> Are the different algorithms for CRC values that give 16 bit of >>>>> output? >>>>> >>>> >>>> You could try jacksum[1] and see if any algorithm it supports >>>> gives you the expected result, there is a handful of 16 bits ones: >>>> >>>> jacksum -a all -F "#ALGONAME{i} = #CHECKSUM{i}" payload.bin >>>> >>> Hi Antonio, >>> >>> I tried jacksum on the complete firmware and on parts - but it never >>> matched the results from the chip. >>> >>> I now found out, that the crc register changes after every 32bit write >>> to the data register - the fw control registers do not affect it. >>> >>> So I can try what crc results from writing 32bit portions of data. >>> But even that did not help in guessing the algorithm, because I do not >>> want to do 100s of experiments. >>> >>> some of my experiments: >>> crc=0x0000, data=0x00000000 -> crc=0x0000 >>> crc=0x0000, data=0x00000001 -> crc=0x1021 >>> crc=0x0000, data=0x00000002 -> crc=0x2042 >>> crc=0x0000, data=0x00000004 -> crc=0x4084 >>> crc=0x0000, data=0x00000008 -> crc=0x8108 >>> crc=0x0000, data=0x00000010 -> crc=0x1231 >>> >>> Is there some systematic way to get the formula? >> >> I don't know much about crc, but the values you are getting look like >> the entries in the table in lib/crc-itu-t.c so maybe compare the crc >> you are getting with the ones calculated with crc_itu_t() from >> include/linux/crc-itu-t.h >> >> I just did a quick test with jacksum, the crc-itu-t parameters can >> be expressed like this: >> >> jacksum -x -a crc:16,1021,0,false,false,0 -q 00000010 >> >> and the output is the expected 0x1231 for the 0x00000010 sequence. > > maybe crc = crc + crc(val) > It worked to apply crc_itu_t to the written data in 32bit blocks, but starting with the last byte: crc = crc_itu_t_byte(crc, *(data+offset+3)); crc = crc_itu_t_byte(crc, *(data+offset+2)); crc = crc_itu_t_byte(crc, *(data+offset+1)); crc = crc_itu_t_byte(crc, *(data+offset+0)); It would also have worked without knowing the crc because it is only actively read and compared in the driver - but better to know if upload did work. Now I am still not sure if it is worth to change the firmware file to now have the crc explicitly. Counting blocks is also easy todo. But the firmware version is not inside the data I think. So there will still remain something to be added to the raw data. Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/29/2014 10:22 PM, Matthias Schwarzott wrote: > On 29.07.2014 13:34, Antti Palosaari wrote: >> >> >> On 07/29/2014 11:53 AM, Antonio Ospite wrote: >>> On Tue, 29 Jul 2014 07:37:44 +0200 >>> Matthias Schwarzott <zzam@gentoo.org> wrote: >>> >>>> On 23.07.2014 22:10, Antonio Ospite wrote: >>>>> On Wed, 23 Jul 2014 21:03:14 +0200 >>>>> Matthias Schwarzott <zzam@gentoo.org> wrote: >>>>> >>>>> [...] >>>>>> The crc value: >>>>>> It protects the content of the file until it is in the demod - so >>>>>> calculating it on my own would only check if the data is correctly >>>>>> transferred from the driver into the chip. >>>>>> But for this I needed to know the algorithm and which data is >>>>>> checksummed exactly. >>>>>> >>>>>> Are the different algorithms for CRC values that give 16 bit of >>>>>> output? >>>>>> >>>>> >>>>> You could try jacksum[1] and see if any algorithm it supports >>>>> gives you the expected result, there is a handful of 16 bits ones: >>>>> >>>>> jacksum -a all -F "#ALGONAME{i} = #CHECKSUM{i}" payload.bin >>>>> >>>> Hi Antonio, >>>> >>>> I tried jacksum on the complete firmware and on parts - but it never >>>> matched the results from the chip. >>>> >>>> I now found out, that the crc register changes after every 32bit write >>>> to the data register - the fw control registers do not affect it. >>>> >>>> So I can try what crc results from writing 32bit portions of data. >>>> But even that did not help in guessing the algorithm, because I do not >>>> want to do 100s of experiments. >>>> >>>> some of my experiments: >>>> crc=0x0000, data=0x00000000 -> crc=0x0000 >>>> crc=0x0000, data=0x00000001 -> crc=0x1021 >>>> crc=0x0000, data=0x00000002 -> crc=0x2042 >>>> crc=0x0000, data=0x00000004 -> crc=0x4084 >>>> crc=0x0000, data=0x00000008 -> crc=0x8108 >>>> crc=0x0000, data=0x00000010 -> crc=0x1231 >>>> >>>> Is there some systematic way to get the formula? >>> >>> I don't know much about crc, but the values you are getting look like >>> the entries in the table in lib/crc-itu-t.c so maybe compare the crc >>> you are getting with the ones calculated with crc_itu_t() from >>> include/linux/crc-itu-t.h >>> >>> I just did a quick test with jacksum, the crc-itu-t parameters can >>> be expressed like this: >>> >>> jacksum -x -a crc:16,1021,0,false,false,0 -q 00000010 >>> >>> and the output is the expected 0x1231 for the 0x00000010 sequence. >> >> maybe crc = crc + crc(val) >> > It worked to apply crc_itu_t to the written data in 32bit blocks, > but starting with the last byte: > > crc = crc_itu_t_byte(crc, *(data+offset+3)); > crc = crc_itu_t_byte(crc, *(data+offset+2)); > crc = crc_itu_t_byte(crc, *(data+offset+1)); > crc = crc_itu_t_byte(crc, *(data+offset+0)); > > It would also have worked without knowing the crc because it is only > actively read and compared in the driver - but better to know if upload > did work. > > Now I am still not sure if it is worth to change the firmware file to > now have the crc explicitly. > Counting blocks is also easy todo. > But the firmware version is not inside the data I think. > > So there will still remain something to be added to the raw data. Do you need to know whole firmware version? How did you obtain it, from sniff? What happens if you don't tell fw version to chip at all? Usually, almost 100%, firmware version as well all the other needed information, is included to firmware image itself. I don't remember many cases where special handling is needed. One (only one?) of such case is af9013, where I resolved issues by calculating fw checksum by the driver. IIRC chip didn't boot if there was wrong checksum for fw. Own headers and checksums causes troubles if I someone would like to extract different firmwares from various windows binaries to test. If windows driver needs to know that kind of things, those are usually found very near firmware image from the driver binary. Most often just dump 32 bytes after firmware image and it is somewhere there. Or before firmware image. That is because those are values are stored to same source code file => compiler puts that stuff ~same location. static const unsigned char firmware[] = { 0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff, }; static const unsigned int firmware_checksum = 0x01234567; static const unsigned int firmware_version = 0x0000002b; regards Antti
On 29.07.2014 21:45, Antti Palosaari wrote: > > Do you need to know whole firmware version? There is only 1 byte to be used and it is called patch version. > How did you obtain it, from > sniff? Yes - but it also is visible in code near crc version (see below). > What happens if you don't tell fw version to chip at all? > In other places it is read to verify a fw was uploaded (compare to be not equal 0x00). I guess the exact value is never needed (so just for information). But I did not try it. > Usually, almost 100%, firmware version as well all the other needed > information, is included to firmware image itself. I don't remember many > cases where special handling is needed. One (only one?) of such case is > af9013, where I resolved issues by calculating fw checksum by the > driver. IIRC chip didn't boot if there was wrong checksum for fw. The checksum is not needed to get the device working. The chip itself only calculates it when uploading data - and the driver reads out the calculated checksum and compares it to the expected value. It is only a verification of the correct upload. > > Own headers and checksums causes troubles if I someone would like to > extract different firmwares from various windows binaries to test. > > If windows driver needs to know that kind of things, those are usually > found very near firmware image from the driver binary. Most often just > dump 32 bytes after firmware image and it is somewhere there. Or before > firmware image. That is because those are values are stored to same > source code file => compiler puts that stuff ~same location. > I had a look at the driver - the code itself has the constants compiled in - they are really mixed with the assembly code. Rewritten in C it is code that has fixed values as parameters to functions. ret = load_firmware(firmware, 0x12, /* patch version */ 48, /* block count */ 0xaa0c /* crc */ ); I also would prefer your version with static const variables near the data. > static const unsigned char firmware[] = { > 0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, > 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff, > }; > > static const unsigned int firmware_checksum = 0x01234567; > static const unsigned int firmware_version = 0x0000002b; > Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
All-in-all, did I understand correctly none of those header values are not required anymore? hdr[0] own FW version. used by driver to print our own FW file version hdr[1] --''-- hdr[2] vendor FW version. programmed to chip register but chip does not need it. read back in order to detect if FW is loaded or not hdr[3] padding. not used hdr[4] number of FW blocks. driver could calculate it. hdr[5] padding. not used hdr[6] crc. not mandatory & driver could calculate it. not 100% FW related, chip uses it for every write. verify xfer errors hdr[7] --''-- regards Antti On 07/30/2014 09:50 PM, Matthias Schwarzott wrote: > On 29.07.2014 21:45, Antti Palosaari wrote: >> >> Do you need to know whole firmware version? > There is only 1 byte to be used and it is called patch version. >> How did you obtain it, from >> sniff? > Yes - but it also is visible in code near crc version (see below). > >> What happens if you don't tell fw version to chip at all? >> > In other places it is read to verify a fw was uploaded (compare to be > not equal 0x00). > I guess the exact value is never needed (so just for information). > But I did not try it. > >> Usually, almost 100%, firmware version as well all the other needed >> information, is included to firmware image itself. I don't remember many >> cases where special handling is needed. One (only one?) of such case is >> af9013, where I resolved issues by calculating fw checksum by the >> driver. IIRC chip didn't boot if there was wrong checksum for fw. > > The checksum is not needed to get the device working. > The chip itself only calculates it when uploading data - and the driver > reads out the calculated checksum and compares it to the expected value. > It is only a verification of the correct upload. > >> >> Own headers and checksums causes troubles if I someone would like to >> extract different firmwares from various windows binaries to test. >> >> If windows driver needs to know that kind of things, those are usually >> found very near firmware image from the driver binary. Most often just >> dump 32 bytes after firmware image and it is somewhere there. Or before >> firmware image. That is because those are values are stored to same >> source code file => compiler puts that stuff ~same location. >> > I had a look at the driver - the code itself has the constants compiled > in - they are really mixed with the assembly code. > > Rewritten in C it is code that has fixed values as parameters to functions. > > ret = load_firmware(firmware, > 0x12, /* patch version */ > 48, /* block count */ > 0xaa0c /* crc */ > ); > > I also would prefer your version with static const variables near the data. > >> static const unsigned char firmware[] = { >> 0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, >> 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff, >> }; >> >> static const unsigned int firmware_checksum = 0x01234567; >> static const unsigned int firmware_version = 0x0000002b; >> > Regards > Matthias >
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index d91b8be..26c623d 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -29,7 +29,7 @@ use IO::Handle; "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", "lme2510c_s7395_old", "drxk", "drxk_terratec_h5", "drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv", - "drxk_terratec_htc_stick", "sms1xxx_hcw"); + "drxk_terratec_htc_stick", "sms1xxx_hcw", "si2165"); # Check args syntax() if (scalar(@ARGV) != 1); @@ -783,6 +783,37 @@ sub sms1xxx_hcw { $allfiles; } +sub si2165 { + my $sourcefile = "model_111xxx_122xxx_driver_6_0_119_31191_WHQL.zip"; + my $url = "http://www.hauppauge.de/files/drivers/"; + my $hash = "76633e7c76b0edee47c3ba18ded99336"; + my $fwfile = "dvb-demod-si2165.fw"; + my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); + + checkstandard(); + + wgetfile($sourcefile, $url . $sourcefile); + verify($sourcefile, $hash); + unzip($sourcefile, $tmpdir); + extract("$tmpdir/Driver10/Hcw10bda.sys", 0x80788, 0x81E08-0x80788, "$tmpdir/fw1"); + + delzero("$tmpdir/fw1","$tmpdir/fw1-1"); + #verify("$tmpdir/fw1","5e0909858fdf0b5b09ad48b9fe622e70"); + + my $CRC="\x0A\xCC"; + my $BLOCKS_MAIN="\x27"; + open FW,">$fwfile"; + print FW "\x01\x00"; # just a version id for the driver itself + print FW "\x9A"; # fw version + print FW "\x00"; # padding + print FW "$BLOCKS_MAIN"; # number of blocks of main part + print FW "\x00"; # padding + print FW "$CRC"; # 16bit crc value of main part + appendfile(FW,"$tmpdir/fw1"); + + "$fwfile"; +} + # --------------------------------------------------------------- # Utilities
Signed-off-by: Matthias Schwarzott <zzam@gentoo.org> --- Documentation/dvb/get_dvb_firmware | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-)