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
>> 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 Thanks. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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
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
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
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. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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. > 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. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: ; "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
Em Fri, 26 Jun 2015 03:58:48 +0700 "Unembossed Name" escreveu: > 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? 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? Regards, Mauro -- 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
