I keep seeing people asking about support for these two devices, so I figured I should provide a status update.
Just so you know, they are basically both the same piece of hardware – em28xx bridge, xc3028 tuner, and drx-d demodulator. The issue preventing it from being supported is the drx-d demod.
With Michael Krufky’s help, I did get the board working in the mainline kernel and am pretty satisfied with the tuning performance. The only big issue remaining is we need to write a firmware extraction script for the drx-d microcode, since we do not have the legal rights to redistribute it.
Now, typically such a script just has to unzip the windows driver and run “dd” against a particular set of bytes in one of the DLLs, writing the output to a file. However, the drx-d firmware format that Henk setup when he wrote the original reverse engineered driver is much more complicated. Like the xc3028 firmware format, the file contains a series of images, and there needs to be a proper encapsulation so that the different images can be found.
To make matters worse, Henk created his file based on a usbsnoop trace (which is perfectly reasonable), and therefore it contains encapsulation that is normally done by the driver (and hence not a part of the binary firmware image stored in the Windows driver DLL).
I’m also not yet confident that the firmware currently shipping in the Hauppauge and PCTV Windows drivers is the same Henk used when he wrote the original support. If it’s different then it is unlikely to work with the driver he wrote. This had me scouring the Internet for ancient versions of the Windows driver (he wrote the support almost two and a half years ago).
In other words, it’s a whole lot more work than is typical for a firmware extraction script. I spent about five hours working on it last night, and it’s pretty clear that more time is required. I’ve had to take the time to fully understand the firmware format used by the Windows driver as well as the encoding scheme Henk used.
I was really hoping this would be a quick project I could knock out in one night, but it turned out to be quite a bit more.
Unfortunately, I can’t make any promises when I will have a tree that users can try out. For me, this is just a side-project I am working on in between consulting projects.
This whole thing about writing a program/script to extract a known in advance firmware
from a distro is reminiscent of steganography.
This might have been over a zillion times, but how come Hauppauge is not willing
o give permission, given that in the end this will allow them to sell more devices ?
Hauppauge has no say in the matter – it’s the chipset vendor who owns the rights to the firmware and won’t permit redistribution. In this case, Micronas (now owned by Trident Microsystems).
I agree though, the lengths I have to go through so you can generate a 12KB file that I could just hand over to you is *really* annoying.
Ah, ok. Hauppauge pays some royalties then to be able to distribute with his soft
the needed firmware…
Well, finding a max length binary match between the needed firmware and the
available DLLs, one of which has to have it, should not be that hard.
Well, that’s how it is in most cases – do a binary search of the DLL, find the blob and extract it. But, as I thought the blog post made pretty clear, this is *not* one of those cases. The code is embedded in the DLL, however the expected firmware format in the Linux driver has the framing and encapsulation that is normally done by the driver before sending it onto the i2c bus. In this case, that means either I have to change the driver to expect the unencapsulated data (and then add all the encapsulation/framing code to the driver). Or I have to perform the transform as part of the extraction script, which is less intuitive but has the benefit of the resulting binary exactly matching the current Linux driver’s expectations, which means the entire driver doesn’t have to be retested.
Unfortunately, it’s one of those cases where it’s easy to say “oh that shouldn’t be that hard” until you get into the details and realize it’s a considerable undertaking…
Hi Devin, I’m one of the guys who asked for support for HVR 900 R2, so I’d like to say thank you again and to give my moral support!
Nicola
Yeah, if I can ever get the damn extraction script finished, I did the testing with the 900 R2 so it should “just work”.
Cheers,
Devin
Also all my moral support; I have also asked for the 330e to work. This firmware problem looks so stupid…
Oh, it’s definitely stupid. I am in the United States, so I assumed the hardest part would be getting access to a DVB generator so I could test the driver and debug any issues. Who knew that all that would go perfectly and then I would get stuck on a stupid script to generate the firmware image?
Devin
Unlikely to be useful at this stage but I couldn’t just ignore the possibility.
http://drivers.softpedia.com/downloadTag/100i—110i—300i—310i—320e—330e—800e—3010iX—7010iX+D
Hi J.D.
Yeah, I had already looked at that one. I’ve looked at five different packagings of the drx-d firmware, and none of the match the original. Fortunately, I’m in touch with Henk now (the original offer of the reverse engineered driver), so my hope is we will get it straightened out soon.
Devin
Is there any news about it?
Unfortunately, I have been tied up in other projects and unable to work on this. Because I was unable to find the original firmware, I will need to update to the latest firmware and that will require me to retest all the code (since the new firmware may require additional driver changes).
Devin
Hi,
I don’t mean to hassle, but is there any progress on the HVR900 R2 firmware issue?
I have this hardware which I would love to get working with mythtv.
I’m happy to assist with testing if necessary.
Hello Stu,
Unfortunately, at this point the answer is “not right now”. I’m waiting for the DVB generator to arrive, at which point I should be able to complete the work.
Devin
hi devin
i have PCT 330e and i hope to see my favorite DVB channel for christmas 🙂
THX for your work and good luck.
If you need help for testing please let me know…
One more tester and moral support here!
thx for your work, i support you
unfortunately i can’t give any help, but if you need testers, i would be glad 🙂
i appreciate your work, thanks!
i own an old version of the em28xx-new, which includes the firmware. is there any way to get it separated, so i can use it?
Hi Daniel,
The big issue is that the firmware in the em28xx-new driver is not the same firmware that was used to write the in-kernel driver. It’s also encoded in a different format, meaning the extraction script would have to re-encode the blob before it can be loaded into the driver. Unfortunately, this is not a case where the firmware is a single binary blob that you “dd” out of a .sys file and load into the chip. It’s a complex file format with multiple sections and the firmware image that is sent to the driver has to conform to that standard. And since we were unable to locate the firmware used when the Linux driver was written, we’re going to have to adjust the driver to work with the newer firmware that is available in Windows drivers that you can download today.
Devin
it’s a pity. anyway, thanks for explanation.
Hi Daniel,
I agree that it is a pity. I did invest some time to start refactoring the firmware so that it can be extracted from the Windows driver and used under Linux. However, it’s a fairly complicated and time-consuming process (I’ve put about 15 hours into it so far), and with limited resources I felt my time was better spent working on newer hardware (like the PCTV 340e). I’ll get back to it at some point, but I just don’t know when.
Devin
Yes, it’s really a pity… I fear I will have to put my 330e on ebay 🙁
Thank you for the explanation.
Just a stupid idea. Would it not be possible to write an extraction script that work on Windows by sniffing the USB port. Many users, either have Windows or at least know someone who have it…
Hi Olive,
I haven’t wanted to announce it yet because it hasn’t been tested, but I do now have a GPL driver for the drx-d which includes redistribution rights for the latest firmware (which is not the same firmware as the in-kernel driver). So I am optimistic that this will get worked out in the near future.
Stay tuned!
Devin
I’m so happy that you are working on this. I wasn’t aware of the chipset issue until recently. Thought I was stupid since I couldn’t get HVR-900 (B2C0) to work with in-kernel driver. Recompiled 1000 times, even tried 28xx-new. It keeps loading the ancient 2.7 firmware which actually makes analog work – but no dvb. I see now why this is more complicated than I suspected. Thanks for all your work on this. It is greatly appreciated!
I have a 330e and can’t wait to get it working.
Thank you for your time that you put into this.