linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Schwarzott <zzam@gentoo.org>
To: Antti Palosaari <crope@iki.fi>, Antonio Ospite <ao2@ao2.it>
Cc: m.chehab@samsung.com, linux-media@vger.kernel.org
Subject: Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
Date: Wed, 30 Jul 2014 20:50:12 +0200	[thread overview]
Message-ID: <53D93E64.6080907@gentoo.org> (raw)
In-Reply-To: <53D7F9DD.7080308@iki.fi>

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


  reply	other threads:[~2014-07-30 18:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22 20:12 [PATCH 0/8] add si2165 demod driver Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165 Matthias Schwarzott
2014-07-23  9:20   ` Antti Palosaari
2014-07-23 19:03     ` Matthias Schwarzott
2014-07-23 20:10       ` Antonio Ospite
2014-07-29  5:37         ` Matthias Schwarzott
2014-07-29  8:53           ` Antonio Ospite
2014-07-29 11:34             ` Antti Palosaari
2014-07-29 19:22               ` Matthias Schwarzott
2014-07-29 19:45                 ` Antti Palosaari
2014-07-30 18:50                   ` Matthias Schwarzott [this message]
2014-07-30 19:29                     ` Antti Palosaari
2014-07-22 20:12 ` [PATCH 2/8] si2165: Add demod driver for DVB-T only Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 3/8] cx23885: Add si2165 support for HVR-5500 Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 4/8] cx231xx: prepare for i2c_client attachment Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 5/8] cx231xx: Add digital support for [2040:b130] Hauppauge WinTV 930C-HD (model 1113xx) Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 6/8] cx231xx: Add digital support for [2040:b131] Hauppauge WinTV 930C-HD (model 1114xx) Matthias Schwarzott
2014-07-26 19:27   ` Mauro Carvalho Chehab
2014-07-27  9:32     ` Matthias Schwarzott
2014-07-27 13:44       ` Mauro Carvalho Chehab
2014-07-27 14:32         ` Mauro Carvalho Chehab
2014-07-27 14:59           ` Mauro Carvalho Chehab
2014-07-27 19:42             ` Mauro Carvalho Chehab
2014-07-29  5:39               ` Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 7/8] cx231xx: Add [2013:0259] PCTV QuatroStick 521e Matthias Schwarzott
2014-07-22 20:12 ` [PATCH 8/8] cx231xx: Add [2013:025e] PCTV QuatroStick 522e Matthias Schwarzott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D93E64.6080907@gentoo.org \
    --to=zzam@gentoo.org \
    --cc=ao2@ao2.it \
    --cc=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).