About Si2168 Part, Revision and ROM detection.

About Si2168 Part, Revision and ROM detection.

[Unembossed Name]

Hi,

Information below was given by a hardware vendor, who uses these demodulators on their dvb-t2 products. As an explanation on our 
questions for Si2168 Linux driver development.
I think it can give more clue with Part, Revision and ROM detection algorithm in Linux driver for that demodulator.

Also, I would like to suggest a following naming method for files containing firmware patches. It's self explaining:
dvb-demod-si2168-a30-rom3_0_2-patch-build3_0_20.fw
dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw.tar.gz
dvb-demod-si2168-b40-rom4_0_2-startup-without-patch-stub.fw
(Stub code to startup B40 without patch at all: 0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00)
I think such naming scheme can help to avoid possible mess with fw patch versions.

Here is a detection code:
NTSTATUS si2168_cmd_part_info(tPART_INFO *part_info)
{
    NTSTATUS ntStatus;

    BYTE cmdBuffer[1] = {Si2168_PART_INFO_CMD};
    BYTE rspBuffer[13] = {0};

    ntStatus = si2168_cmd_rsp(cmdBuffer, sizeof(cmdBuffer), rspBuffer, sizeof(rspBuffer));
    if (ntStatus != STATUS_SUCCESS)
        return ntStatus;

    part_info->chiprev = rspBuffer[1] & 0x0F;
    part_info->part = rspBuffer[2];
    part_info->pmajor = rspBuffer[3];
    part_info->pminor = rspBuffer[4];
    part_info->pbuild = rspBuffer[5];
    part_info->serial = ((ULONG)rspBuffer[11] << 24) | ((ULONG)rspBuffer[10] << 16) | ((ULONG)rspBuffer[9] << 8) | 
((ULONG)rspBuffer[8]);
    part_info->romid = rspBuffer[12];

    DBGPRINT(("CHIP REV   : %d\n", part_info->chiprev));
    DBGPRINT(("CHIP PART  : %d\n", part_info->part));
    DBGPRINT(("CHIP PMAJOR: %c\n", part_info->pmajor));
    DBGPRINT(("CHIP PMINOR: %c\n", part_info->pminor));
    DBGPRINT(("CHIP PBUILD: %d\n", part_info->pbuild));
    DBGPRINT(("CHIP SERIAL: %08X\n", part_info->serial ));
    DBGPRINT(("CHIP ROMID : %d\n", part_info->romid));

    return STATUS_SUCCESS;
}

Best regards. 

Re: About Si2168 Part, Revision and ROM detection.

[Antti Palosaari]

On 06/06/2015 08:03 AM, Unembossed Name wrote:
> Information below was given by a hardware vendor, who uses these
> demodulators on their dvb-t2 products. As an explanation on our
> questions for Si2168 Linux driver development.
> I think it can give more clue with Part, Revision and ROM detection
> algorithm in Linux driver for that demodulator.
>
> Also, I would like to suggest a following naming method for files
> containing firmware patches. It's self explaining:
> dvb-demod-si2168-a30-rom3_0_2-patch-build3_0_20.fw
> dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw.tar.gz
> dvb-demod-si2168-b40-rom4_0_2-startup-without-patch-stub.fw

There is very little idea to add firmware version number to name as then 
you cannot update firmware without driver update. Also, it is not 
possible to change names as it is regression after kernel update.

> (Stub code to startup B40 without patch at all:
> 0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00)
> I think such naming scheme can help to avoid possible mess with fw patch
> versions.

Current driver selects firmware by reading chip revision (A, B) and 
PMAJOR/PMINOR, which means A20, A30 and B40 are detected.

PBUILD is 2 and ROMID is 1 for me Si2168-B40 chip, without firmware 
upgrade it boots up with fw version 4.0.2. Those numbers are just same 
than PMAJOR.PMINOR.PBUILD, but are those?

It is not clear at all what the hell is role of ROMID.

I know that there is many firmware updates available and all are not 
compatible with chip revisions. But I expect it is only waste of some 
time when upload always biggest firmware to chip.

Lets say there is old B40 having 4.0.2 on ROM. Then there is newer B40 
having 4.0.10 on ROM. Then there is firmware upgrade to 4.0.11, one for 
4.0.2 and another for 4.0.10. 4.0.2 is significant bigger and as 4.0.10 
very close to 4.0.11 it is significantly smaller. However, you could 
download that 4.0.2 => 4.0.11 upgrade to both chips and it leads same, 
but chip with 4.0.2 fw on ROM will not work if you upload 4.0.10 => 
4.0.11 upgrade. I haven't tested that theory, but currently driver does 
that as there is no any other detection than A20/A30/B40 and it seems to 
work pretty well. Downside is just that large fw update done always.

regards
Antti

-- 
http://palosaari.fi/

Re: About Si2168 Part, Revision and ROM detection.

[Unembossed Name]

From: "Antti Palosaari"
To: "Unembossed Name" <severe.siberian.man@mail.ru>; <linux-media@vger.kernel.org>
Sent: Monday, June 08, 2015 10:22 PM
Subject: Re: About Si2168 Part, Revision and ROM detection.


>> Also, I would like to suggest a following naming method for files
>> containing firmware patches. It's self explaining:
>> dvb-demod-si2168-a30-rom3_0_2-patch-build3_0_20.fw
>> dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw.tar.gz
>> dvb-demod-si2168-b40-rom4_0_2-startup-without-patch-stub.fw
> 
> There is very little idea to add firmware version number to name as then 
> you cannot update firmware without driver update. Also, it is not 
> possible to change names as it is regression after kernel update.

I'm sure, that demodulator will accept firmware patch only if that patch will be
matched with ROM version it's designed for. In all other cases patch will be
rejected by IC. This is because this patches is not a completely new ROM code
containing firmware update. Probably, for Si2168 such kind of updates has never
existed and never will be.

One user has reported, that with his A30 revision of demodulator, he was unable
to upload firmware patch, wich was taken from
http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-A30/3f2bc2c63285ef9323cce8689ef8a6cb/dvb-demod-si2168-a30-01.fw
And at the same time, he was able to successfully upload firmware patch, that
designed for A30 ROM 3.0.2 and makes version 3.0.2 => 3.0.20 after patching
completes. Here it is: http://beholder.ru/bb/download/file.php?id=732

What can be cause of that? Probably it's either broken or corrupted firmware
(I doubt in it), or possibly it's designed for A30 revision, but with another ROM
version?
Looking inside their HEX I cannot say, for what ROM version it is designed.
Or wich version it will make after patching completes. Thats why i suggested to
specify all this in a file name.

And, having all info about IC in one hand and necessary info about available fw
patches in /lib/firmware/ in the other, we can fully automate IC patching process.
Or left the driver code untouched, and it will be depend from an end user,  how
to choose right fw patch and properly rename it.
And in case of automated way, user also always be able to choose wich patches
are unneccesary. Just by deleting unwanted files with patches from /lib/firmware/
 
> Current driver selects firmware by reading chip revision (A, B) and 
> PMAJOR/PMINOR, which means A20, A30 and B40 are detected.
> 
> PBUILD is 2 and ROMID is 1 for me Si2168-B40 chip, without firmware 
> upgrade it boots up with fw version 4.0.2. Those numbers are just same 
> than PMAJOR.PMINOR.PBUILD, but are those?
>
> It is not clear at all what the hell is role of ROMID.

Agreed. And hardware vendor also didn't mention anything special about ROMID.
I think it can be ignored if we can't use it.
 
> I know that there is many firmware updates available and all are not 
> compatible with chip revisions. But I expect it is only waste of some 
> time when upload always biggest firmware to chip.
>
> Lets say there is old B40 having 4.0.2 on ROM. Then there is newer B40 
> having 4.0.10 on ROM. Then there is firmware upgrade to 4.0.11, one for 
> 4.0.2 and another for 4.0.10. 4.0.2 is significant bigger and as 4.0.10 
> very close to 4.0.11 it is significantly smaller. However, you could 
> download that 4.0.2 => 4.0.11 upgrade to both chips and it leads same, 
> but chip with 4.0.2 fw on ROM will not work if you upload 4.0.10 => 
> 4.0.11 upgrade. I haven't tested that theory, but currently driver does 
> that as there is no any other detection than A20/A30/B40 and it seems to 
> work pretty well. Downside is just that large fw update done always.

I have understood that you are explaining.
But, are you sure, that download patch 4.0.2 => 4.0.11 to a chip with ROM 4.0.10 will be successful?
Most likely, it will be rejected, because of ROM difference. Because it is a patch. It is not a whole new firmware.
AFAIK, it is will be designed to make changes to 4.0.2 ROM only.

Here is more info, that i forgot to enclose last time. This is a verification constants:

#define Si2168A_ROM2_2_0_3_PART      68
#define Si2168A_ROM2_2_0_3_ROM      2
#define Si2168A_ROM2_2_0_3_PMAJOR   '2'
#define Si2168A_ROM2_2_0_3_PMINOR   '0'
#define Si2168A_ROM2_2_0_3_PBUILD   3

#define Si2168A_ROM3_3_0_2_PART      68
#define Si2168A_ROM3_3_0_2_ROM      3
#define Si2168A_ROM3_3_0_2_PMAJOR   '3'
#define Si2168A_ROM3_3_0_2_PMINOR   '0'
#define Si2168A_ROM3_3_0_2_PBUILD   2

#define Si2168B_ROM1_4_0_2_PART      68
#define Si2168B_ROM1_4_0_2_ROM      1
#define Si2168B_ROM1_4_0_2_PMAJOR   '4'
#define Si2168B_ROM1_4_0_2_PMINOR   '0'
#define Si2168B_ROM1_4_0_2_PBUILD   2

Here we can see here, that ROM from a chip vendor can come as:
PMAJOR   '2'
PMINOR   '0'
PBUILD   3
And not only 2.0.2, 3.0.2, 4.0.2 and so on.

Best regards.

Re: About Si2168 Part, Revision and ROM detection.

[Antti Palosaari]

On 06/09/2015 01:14 AM, Unembossed Name wrote:

First of all, unfortunately I don't any other chip revisions than B40, 
but these sniffs I found somewhere on my logs (replies to command 0x02):

Si2168 40 "\x80\x42\x44\x34\x30\x02\x00\x00\x00\x00\x00\x00\x01"
Si2168 20 "\x80\x41\x44\x33\x30\x02\x00\x00\x00\x00\x00\x00\x03"
si2168      x80 x41 x44 x32 x30 x03 x00 x00 x00 x00 x00 x00 x02

So lets put that to following table:
Si2168A 1.0-X ROM 1 (just guessed)
Si2168A 2.0-3 ROM 2
Si2168A 3.0-2 ROM 3
Si2168B 4.0-2 ROM 1

I guessed that Si2168-10A to point out ROM is probably just running 
number for ROM update withing same chip revision. Anyhow, it could be 
interesting to see which is FW version for Si2168A having ROM 4 (not 
sure if it even exists).

>>> Also, I would like to suggest a following naming method for files
>>> containing firmware patches. It's self explaining:
>>> dvb-demod-si2168-a30-rom3_0_2-patch-build3_0_20.fw
>>> dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw.tar.gz
>>> dvb-demod-si2168-b40-rom4_0_2-startup-without-patch-stub.fw
>>
>> There is very little idea to add firmware version number to name as
>> then you cannot update firmware without driver update. Also, it is not
>> possible to change names as it is regression after kernel update.
>
> I'm sure, that demodulator will accept firmware patch only if that patch
> will be
> matched with ROM version it's designed for. In all other cases patch
> will be
> rejected by IC. This is because this patches is not a completely new ROM
> code
> containing firmware update. Probably, for Si2168 such kind of updates
> has never
> existed and never will be.
>
> One user has reported, that with his A30 revision of demodulator, he was
> unable
> to upload firmware patch, wich was taken from
> http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-A30/3f2bc2c63285ef9323cce8689ef8a6cb/dvb-demod-si2168-a30-01.fw
>
> And at the same time, he was able to successfully upload firmware patch,
> that
> designed for A30 ROM 3.0.2 and makes version 3.0.2 => 3.0.20 after patching
> completes. Here it is: http://beholder.ru/bb/download/file.php?id=732
>
> What can be cause of that? Probably it's either broken or corrupted
> firmware
> (I doubt in it), or possibly it's designed for A30 revision, but with
> another ROM
> version?

I expected dvb-demod-si2168-a30-01.fw to be update for 3.0.2 ROM. But 
not sure. Olli surely has sniffs to check which ROM and PBUILD device 
has replied. If it appears to be some other than 3.0.2 it explains some 
things (why firmware is incompatible).

> Looking inside their HEX I cannot say, for what ROM version it is designed.
> Or wich version it will make after patching completes. Thats why i
> suggested to
> specify all this in a file name.

Feel free to collect list of chip revisions, initial firmware version 
and ROM number.

> And, having all info about IC in one hand and necessary info about
> available fw
> patches in /lib/firmware/ in the other, we can fully automate IC
> patching process.
> Or left the driver code untouched, and it will be depend from an end
> user,  how
> to choose right fw patch and properly rename it.
> And in case of automated way, user also always be able to choose wich
> patches
> are unneccesary. Just by deleting unwanted files with patches from
> /lib/firmware/
>
>> Current driver selects firmware by reading chip revision (A, B) and
>> PMAJOR/PMINOR, which means A20, A30 and B40 are detected.
>>
>> PBUILD is 2 and ROMID is 1 for me Si2168-B40 chip, without firmware
>> upgrade it boots up with fw version 4.0.2. Those numbers are just same
>> than PMAJOR.PMINOR.PBUILD, but are those?
>>
>> It is not clear at all what the hell is role of ROMID.
>
> Agreed. And hardware vendor also didn't mention anything special about
> ROMID.
> I think it can be ignored if we can't use it.

For me it also looks like not interesting at all - but my data is very 
limited. More data collecting is needed.

>> I know that there is many firmware updates available and all are not
>> compatible with chip revisions. But I expect it is only waste of some
>> time when upload always biggest firmware to chip.
>>
>> Lets say there is old B40 having 4.0.2 on ROM. Then there is newer B40
>> having 4.0.10 on ROM. Then there is firmware upgrade to 4.0.11, one
>> for 4.0.2 and another for 4.0.10. 4.0.2 is significant bigger and as
>> 4.0.10 very close to 4.0.11 it is significantly smaller. However, you
>> could download that 4.0.2 => 4.0.11 upgrade to both chips and it leads
>> same, but chip with 4.0.2 fw on ROM will not work if you upload 4.0.10
>> => 4.0.11 upgrade. I haven't tested that theory, but currently driver
>> does that as there is no any other detection than A20/A30/B40 and it
>> seems to work pretty well. Downside is just that large fw update done
>> always.
>
> I have understood that you are explaining.
> But, are you sure, that download patch 4.0.2 => 4.0.11 to a chip with
> ROM 4.0.10 will be successful?
> Most likely, it will be rejected, because of ROM difference. Because it
> is a patch. It is not a whole new firmware.
> AFAIK, it is will be designed to make changes to 4.0.2 ROM only.

No, I don't, as I mentioned it is only theory. I don't have devices to test.

> Here is more info, that i forgot to enclose last time. This is a
> verification constants:
>
> #define Si2168A_ROM2_2_0_3_PART      68
> #define Si2168A_ROM2_2_0_3_ROM      2
> #define Si2168A_ROM2_2_0_3_PMAJOR   '2'
> #define Si2168A_ROM2_2_0_3_PMINOR   '0'
> #define Si2168A_ROM2_2_0_3_PBUILD   3
>
> #define Si2168A_ROM3_3_0_2_PART      68
> #define Si2168A_ROM3_3_0_2_ROM      3
> #define Si2168A_ROM3_3_0_2_PMAJOR   '3'
> #define Si2168A_ROM3_3_0_2_PMINOR   '0'
> #define Si2168A_ROM3_3_0_2_PBUILD   2
>
> #define Si2168B_ROM1_4_0_2_PART      68
> #define Si2168B_ROM1_4_0_2_ROM      1
> #define Si2168B_ROM1_4_0_2_PMAJOR   '4'
> #define Si2168B_ROM1_4_0_2_PMINOR   '0'
> #define Si2168B_ROM1_4_0_2_PBUILD   2
>
> Here we can see here, that ROM from a chip vendor can come as:
> PMAJOR   '2'
> PMINOR   '0'
> PBUILD   3
> And not only 2.0.2, 3.0.2, 4.0.2 and so on.

These values meet 100% for those sniffs. But is there really any other 
than these? Have you seen any other version than Si2168-B 4.0.2 for example?

regards
Antti

-- 
http://palosaari.fi/

Re: About Si2168 Part, Revision and ROM detection.

[Unembossed Name]

From: "Antti Palosaari"
To: "Unembossed Name" <severe.siberian.man@mail.ru>; <linux-media@vger.kernel.org>
Sent: Tuesday, June 09, 2015 6:46 AM
Subject: Re: About Si2168 Part, Revision and ROM detection.


>> And at the same time, he was able to successfully upload firmware patch,
>> that
>> designed for A30 ROM 3.0.2 and makes version 3.0.2 => 3.0.20 after patching
>> completes. Here it is: http://beholder.ru/bb/download/file.php?id=732
>>
>> What can be cause of that? Probably it's either broken or corrupted
>> firmware
>> (I doubt in it), or possibly it's designed for A30 revision, but with
>> another ROM
>> version?
> 
> I expected dvb-demod-si2168-a30-01.fw to be update for 3.0.2 ROM. But 
> not sure. Olli surely has sniffs to check which ROM and PBUILD device 
> has replied. If it appears to be some other than 3.0.2 it explains some 
> things (why firmware is incompatible).

That would be really good to retest it somehow. 

>> #define Si2168B_ROM1_4_0_2_PBUILD   2
>>
>> Here we can see here, that ROM from a chip vendor can come as:
>> PMAJOR   '2'
>> PMINOR   '0'
>> PBUILD   3
>> And not only 2.0.2, 3.0.2, 4.0.2 and so on.
> 
> These values meet 100% for those sniffs. But is there really any other 
> than these? Have you seen any other version than Si2168-B 4.0.2 for example?

No, I have not seen. And a hw vendor, who gave us this little info, also wrote about 4.0.2
But, there is nothing impossible. If they already done that one time. Why not to do it again.

BTW: I've found that I've missed a few more things.
1. It is also possible to start A30 without patch and even stub code. Just boot it.

2. Hw vendor gave us a little advice. I'm not sure, will it be useful for you, but, as he wrote: 
"when you checking CTS status, check it by a mask 0x3C and she should be empty,
because sometimes you can receive a wrong status, you should ignore it, if by
a mask 0x3C not  zeroes".

3. After fw download completion, it's possible to switch a demod into a sleep mode with a
command Si2168_POWER_DOWN_CMD (without CTS status checking). And wake
it when it needed with a command Si2168_START_CLK_CMD (with a parameter
Si2168_POWER_UP_CMD_WAKE_UP_WAKE_UP) any desired number of times. 
After that you do not need to reupload fw patch again.

4. After you switching chip pins with a command Si2168_DD_EXT_AGC_TER_CMD, 
you have to give a command Si2168_DD_RESTART_CMD, otherwise pins will not be 
switched. And after Si2168_DD_RESTART_CMD you have to wait minimum 10ms.

Re: About Si2168 Part, Revision and ROM detection.

[Unembossed Name]

From: "Antti Palosaari"
To: "Unembossed Name" <severe.siberian.man@mail.ru>; <linux-media@vger.kernel.org>
Sent: Tuesday, June 09, 2015 6:46 AM
Subject: Re: About Si2168 Part, Revision and ROM detection.


>>>> Also, I would like to suggest a following naming method for files
>>>> containing firmware patches. It's self explaining:
>>>> dvb-demod-si2168-a30-rom3_0_2-patch-build3_0_20.fw
>>>> dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw.tar.gz
>>>> dvb-demod-si2168-b40-rom4_0_2-startup-without-patch-stub.fw
>>>
>>> There is very little idea to add firmware version number to name as
>>> then you cannot update firmware without driver update. Also, it is not
>>> possible to change names as it is regression after kernel update.
>>
>> I'm sure, that demodulator will accept firmware patch only if that patch
>> will be
>> matched with ROM version it's designed for. In all other cases patch
>> will be
>> rejected by IC. This is because this patches is not a completely new ROM
>> code
>> containing firmware update. Probably, for Si2168 such kind of updates
>> has never
>> existed and never will be.
>>
>> One user has reported, that with his A30 revision of demodulator, he was
>> unable
>> to upload firmware patch, wich was taken from
>> http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-A30/3f2bc2c63285ef9323cce8689ef8a6cb/dvb-demod-si2168-a30-01.fw
>>
>> And at the same time, he was able to successfully upload firmware patch,
>> that
>> designed for A30 ROM 3.0.2 and makes version 3.0.2 => 3.0.20 after patching
>> completes. Here it is: http://beholder.ru/bb/download/file.php?id=732
>>
>> What can be cause of that? Probably it's either broken or corrupted
>> firmware
>> (I doubt in it), or possibly it's designed for A30 revision, but with
>> another ROM
>> version?
>
> I expected dvb-demod-si2168-a30-01.fw to be update for 3.0.2 ROM. But not sure. Olli surely has sniffs to check which ROM and 
> PBUILD device has replied. If it appears to be some other than 3.0.2 it explains some things (why firmware is incompatible).

I've just been contacted by this user again.

It seems, he is also reading linux-media list and saw our conversation.

He downloaded that firmware again: 
http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-A30/3f2bc2c63285ef9323cce8689ef8a6cb/dvb-demod-si2168-a30-01.fw and retried 
to upload it to demodulator.

He reported, that on this time, there was no any errors, and demod Si2168 A30 3.0.2 accepted it and version of demod's firmware 
became 3.0.16
Here is a part of his dmesg log:

si2168 10-0064: found a 'Silicon Labs Si2168-A30 build 2 id 0'
si2168 10-0064: firmware download took 35976 ms
si2168 10-0064: firmware version: 3.0.16

He believes, that since his last attempt it's something has been changed in the fw download code of the driver.

So. It is confirmed now, that it is absolutely enough to detect only revision of the chip,
and is no need to track fw patch build or ROM build of the chip.

I was wrong. Apologize for wasted your time.

Best regards.