Re: XC5000C 0x14b4 status
IMHO, the best is to get the latest firmware licensed is the best thing to do. Does that new xc5000c come with a firmware pre-loaded already? I've got firmware here that is indicated as being for the xc5300 (i.e. 0x14b4). That said, I am not sure if it's the same as the original 5000c firmware. Definitely makes sense to do an I2C dump and compare the firmware images since using the wrong firmware can damage the part. I'm not against an additional #define for the 0x14b4 part ID, but it shouldn't be accepted upstream until we have corresponding firmware and have seen the tuner working. Do you have digital signal lock working with this device under Linux and the issue is strictly with part identification? Hello. There are new details. My assumption, that such behaviour of IC can be because of an old or incorrect (for that HW) firmware, was wrong. It does not matter which FW version we use. With a fresh (beginning of 2015) media_build, even with an old firmware, RF tuner always and stably returns status 0x14b4. Also it's stably detects an already loaded firmware from another instance of the driver (analog part initialisation). And there is no i2c errors. With an old media_build from beginning of 2014, there is some problem with detection of already loaded firmware, there is i2c errors, and it gives the 50/50 status either 0x1388 or 0x14b4. My mistake I didn't checked a fresh media_build before. So, the only thing we need is to add an additional #define for the 0x14b4 part ID to a driver's code, as I wrote before. If you have any more questions, please ask. Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
I just received a confirmation, that firmware in file latest-dvb-fe-xc5000c-0.6.30.5.fw is working. xc5000: Firmware latest-dvb-fe-xc5000c-0.6.30.5.fw loaded and running xc5000: *** HW: V6.0, FW: V 0.6.40990 So, it's has a build number 40990 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
IMHO, the best is to get the latest firmware licensed is the best thing to do. Does that new xc5000c come with a firmware pre-loaded already? I've got firmware here that is indicated as being for the xc5300 (i.e. 0x14b4). That said, I am not sure if it's the same as the original 5000c firmware. Definitely makes sense to do an I2C dump and compare the firmware images since using the wrong firmware can damage the part. I'm not against an additional #define for the 0x14b4 part ID, but it shouldn't be accepted upstream until we have corresponding firmware and have seen the tuner working. Do you have digital signal lock working with this device under Linux and the issue is strictly with part identification? I just finished extraction of firmware for xc5000c. By the way found one even for xc4000/4100. xc5000c matches by size, signatures, but I have not tested it on a hardware. xc4000/4100 matches only by a beginning signature, but should be ok. Have not tested it on a hardware too. files: http://beholder.ru/bb/download/file.php?id=868 http://beholder.ru/bb/download/file.php?id=869 How to extract it yourself: Again, you have to download zipped file from http://beholder.ru/files/drv_v5510.zip Unpack beholder.bin from it, and then use that commands to extract firmware: dd if=beholder.bin bs=1 skip=27663 count=16497 of=latest-dvb-fe-xc5000c-0.6.30.5.fw dd if=beholder.bin bs=1 skip=1718 count=13567 of=unconfirmed-dvb-fe-xc4000-xc4100-1.04.26.fw Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
Here is a link on a chinese site with datasheet for xc5100. http://wenku.baidu.com/view/7f92f3fe700abb68a982fb96.html If you look at it, after reading Product ID we also should receive 0x14b4 (5300 decimal) I'll try extract a FW from a Windows driver and will share results, in case of success. Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
It's not new IC. It's XC5000C. Maybe i was interpreted wrong. As I have understood, such behaviour can depends from FW version. HW vendor says, that with his latest FW he always gets response 0x14b4. Ah, so you're running a completely different firmware image? Well in that case that would explain the different response for the firmware loaded indication. No no no. I used a FW image, which was taken from KernelLabs site, and it was intended for use with XC5000C. And partnumber of IC was XC5000C ( I have opened RF shild to check it) Not a 0x1388. And I think, that these ICs still come without pre-loaded FW. HW vendor also didn't says anything about FW pre-load possibility. Correct. These are not parts that have any form of default firmware in their ROM mask (i.e. not like the silabs or micronas parts which have a default firmware and the ability to patch the ROM via a software loaded code update). The firmware must be loaded every time the chip is brought out of reset or it won't work at all. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
Correct. These are not parts that have any form of default firmware in their ROM mask (i.e. not like the silabs or micronas parts which have a default firmware and the ability to patch the ROM via a software loaded code update). The firmware must be loaded every time the chip is brought out of reset or it won't work at all. An image of the top of the tuner clearly showing any manufacturing markings would be welcome - assuming its accessible. It's a best picture I could find: http://www.reviews.ru/clause/over/T7_2/image41.jpg Also, at least 2 users was successful with using Behold TV T7 tuner with my Linux driver for it, then I shared it with others a year ago. HW vendor also says, that Linux FW 4.1.30.7 for XC5000C (from KernelLabs) reminds him an old 4.1 numeration scheme from 2010 year. But he was unable to understand it's date. Also he says, that for XC5000C they are already long time using 0.6.30.5, and it's always gives a 0x14b4. // Filename : Xc5000_firmwares.h // Generated : 2012/3/5 ¤W¤È 08:34:27 // Firmware version : 0.6; Release Number: 30.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
From: Mauro Carvalho Chehab To: Unembossed Name Cc: linux-media@vger.kernel.org; Devin Heitmueller Sent: Friday, June 26, 2015 4:22 PM Subject: Re: XC5000C 0x14b4 status After that RF tuner identification became always successful. I had a conversation with a hardware vendor. Now I can say, that such behaviour, most likely, because of early firmware for XC5000C. This hardware vendor is using for his Windows driver a latest firmware, and reading Product ID register always gives 0x14b4 status. As he says, 0x1388 status is only for previous XC5000 IC. (Without C at end of a P/N) Is this possible to patch xc5000.c with something like this: #define XC_PRODUCT_ID_FW_LOADED 0x1388 +#define XC_PRODUCT_ID_FW_LOADED_XC5000C 0x14b4 case XC_PRODUCT_ID_FW_LOADED: + case XC_PRODUCT_ID_FW_LOADED_XC5000C: printk(KERN_INFO xc5000: Successfully identified at address 0x%02x\n, Or to try to get a chip vendor's permission for using a latest firmware for XC5000C in Linux, and then anyway, patch the driver? IMHO, the best is to get the latest firmware licensed is the best thing to do. Agreed. If that possible of course. Does that new xc5000c come with a firmware pre-loaded already? It's not new IC. It's XC5000C. Maybe i was interpreted wrong. As I have understood, such behaviour can depends from FW version. HW vendor says, that with his latest FW he always gets response 0x14b4. Not a 0x1388. And I think, that these ICs still come without pre-loaded FW. HW vendor also didn't says anything about FW pre-load possibility. Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
IMHO, the best is to get the latest firmware licensed is the best thing to do. Does that new xc5000c come with a firmware pre-loaded already? I've got firmware here that is indicated as being for the xc5300 (i.e. 0x14b4). That said, I am not sure if it's the same as the original 5000c firmware. Definitely makes sense to do an I2C dump and compare the firmware images since using the wrong firmware can damage the part. As I have understood, reading Poduct ID register (together with reading checksum register) is primarily for check integrity of uploaded FW. It's not indicates IC's P/N which FW should belong. I'm not against an additional #define for the 0x14b4 part ID, but it shouldn't be accepted upstream until we have corresponding firmware and have seen the tuner working. Do you have digital signal lock working with this device under Linux and the issue is strictly with part identification? With that RF tuner IC, Linux driver and public available FW for XC5000C (from Kernel Labs) I successfully received analog and digital transmissions over an air. Didn't checked it with DVC-C though. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
XC5000C 0x14b4 status
Hi, I was working on a Linux driver for a hybrid TV-tuner with SAA7134 PCI bridge, XC5000C RF tuner and Si2168 DVB demodulator by a combining all existent at that time drivers together. During that work, I had an issue with XC5000C. Episodically, after attaching to DVB and reading XREG_PRODUCT_ID register, it was possible to receive 0x14b4 instead of usual 0x1388 status. And as a result get a xc5000: Device not found at addr 0x%02x (0x%x)\n in dmesg. To workaround these, I added a few strings to a source of a driver to make it's behaviour the same for 0x14b4, as for 0x1388. After that RF tuner identification became always successful. I had a conversation with a hardware vendor. Now I can say, that such behaviour, most likely, because of early firmware for XC5000C. This hardware vendor is using for his Windows driver a latest firmware, and reading Product ID register always gives 0x14b4 status. As he says, 0x1388 status is only for previous XC5000 IC. (Without C at end of a P/N) Is this possible to patch xc5000.c with something like this: #define XC_PRODUCT_ID_FW_LOADED 0x1388 +#define XC_PRODUCT_ID_FW_LOADED_XC5000C 0x14b4 case XC_PRODUCT_ID_FW_LOADED: + case XC_PRODUCT_ID_FW_LOADED_XC5000C: printk(KERN_INFO xc5000: Successfully identified at address 0x%02x\n, Or to try to get a chip vendor's permission for using a latest firmware for XC5000C in Linux, and then anyway, patch the driver? Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Si2168 Part, Revision and ROM detection.
From: Antti Palosaari To: Unembossed Name severe.siberian@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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http
Re: About Si2168 Part, Revision and ROM detection.
From: Antti Palosaari To: Unembossed Name severe.siberian@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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Si2168 Part, Revision and ROM detection.
From: Antti Palosaari To: Unembossed Name severe.siberian@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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Si2168 B40 frimware.
Hi Hurda, What's new with that firmware? It's twice as big as 4.0.11, so there got to be a lot of changes and fixes. I can't tell exactly what 4.0.19 does. May be I'm wrong, but I suppose, patch 4.0.19 for B40 has so big size, because most likely it resolves the same issues as patch 3.0.20 for A30: Here, in Russia, TV broadcasters actively using Multi PLP in DVB-T2 transmissions. In some cities, were problems with switching to PLP#1 or PLP#2 without A30 3.0.20 patch. (Different cities in different time zones lead to a separate mux transport streams for them.) What I can tell exactly, is that A30 3.0.20 contains an update for Si2168, which allows demodulator to lock PLP#2 with an old type OFDM frame encoding. Also it speed up locking for low bitrates PLP. In short: it fixes a serious issue with Multi PLP locking. I assume the info originates from http://beholder.ru/bb/viewtopic.php?f=11t=14101 , but I don't understand Russian at all. Yes, you are right. Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Si2168 B40 frimware.
From: Antti Palosaari To: Unembossed Name Sent: Sunday, June 07, 2015 12:43 AM Subject: Re: Si2168 B40 frimware. Anybody want to test it? Unfortunately, I can not do it myself, because I do not own hardware with B40 revision. That does not even download. It looks like 17 byte chunk format, but it does not divide by 17. Probably there is some bytes missing or too many at the end of file. That is how first 16 bytes of those firmwares looks: 4.0.4: 05 00 aa 4d 56 40 00 00 0c 6a 7e aa ef 51 da 89 4.0.11: 08 05 00 8d fc 56 40 00 00 00 00 00 00 00 00 00 4.0.19: 08 05 00 f0 9a 56 40 00 00 00 00 00 00 00 00 00 4.0.4 is 8 byte chunks, 4.0.11 is 17 byte. Hi Antti, You're right. I've made a mistake with determining of the end of a patch. It seems I blindly used an obsolete information about size it should be. And because of that, these version of a patch can be even more recent. Like 4.0.20. Could you please check it again? And in case of success see which version it is? file name:dvb-demod-si2168-b40-rom4_0_2-patch-build-probably4_0_19.fw.tar.gz http://beholder.ru/bb/download/file.php?id=857 Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Si2168 B40 frimware.
From: Antti Palosaari To: Unembossed Name severe.siberian@mail.ru; linux-media@vger.kernel.org Sent: Sunday, June 07, 2015 3:14 AM Subject: Re: Si2168 B40 frimware. Could you please check it again? And in case of success see which version it is? file name:dvb-demod-si2168-b40-rom4_0_2-patch-build-probably4_0_19.fw.tar.gz http://beholder.ru/bb/download/file.php?id=857 Best regards. That one works, DVB-T/T2 scan tested. si2168 6-0064: found a 'Silicon Labs Si2168-B40' si2168 6-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' si2168 6-0064: firmware version: 4.0.19 si2157 7-0060: found a 'Silicon Labs Si2157-A30' si2157 7-0060: firmware version: 3.0.5 Hi Antti, Great! Thank you. Instructions, on how to extract 4.0.19 for Si2168 B40 demod: First, you have to download zipped file from http://beholder.ru/files/drv_v5510.zip Unpack beholder.bin from it, and then use that command to extract firmware patch: dd if=beholder.bin bs=1 skip=69520 count=13651 of=dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Si2168 B40 frimware.
Hi, Yesterday I extracted a new firmware for Si2168 B40 rev. from Windows driver. It's designed for ROM version 4.0.2 and has a version build 4.0.19 Here is a name of file:dvb-demod-si2168-b40-rom4_0_2-patch-build4_0_19.fw.tar.gz And a link for download: http://beholder.ru/bb/download/file.php?id=854 Anybody want to test it? Unfortunately, I can not do it myself, because I do not own hardware with B40 revision. Best regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About Si2168 Part, Revision and ROM detection.
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.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
