Last year was a very busy year and I didn’t have much time for posting, but this year seems to be much better.
In fact, the first good news is that the QBoxHD Team released the source code of almost all the software that runs in these boxes.
If you want to see the sources right away, you can go the project’s homepage at SourceForge.
You can get the sources from the SVN repository:
svn co https://qboxhd.svn.sourceforge.net/svnroot/qboxhd/trunk qboxhd
Some of the most important components were already OSS such as the kernel and the application software Enigma2, so they had to be released anyway. As a matter of fact, they were released several months ago, but they were never updated, although they were in an SVN repository. This was due to the team that worked in a private repository and never sync’ed to the public one.
Although Duolabs is doing a great effort for opening their development process (you can see that the SourceForge’s SVN repository is actively used), not all the software is being released. Some critical parts such as everything related to the FPGA remains proprietary.
However, most of the sources that before were proprietary, now are OSS released under the GPLv2. And this, along with a simple mechanism for compiling these sources, are the relevant part that could mean an advantage for these decoders.
Let’s start with the development environment.
It is a simple, yet useful system targeted for compiling the kernel, drivers and the middleware and application software. This environment is just a set of scripts that only allows to:
- Compile the boot loader
- Compile the kernel
- Compile the drivers (only the OSS)
- Compile enigma2 (middleware and application software)
- Work with an NFS filesystem and an TFTP server
- Create releases using the official procedure
These tools consist of a Makefile, a configuration file config.in and some other Shell and Perl scripts inside the /sdk directory. If you want to check the details you can have a look at the project’s wiki that is far from being complete, but at least it describes the basic procedure for compiling the mentioned sources.
It’s a quite simple set of tools. Thus, do not expect any development environment such as the ones used in projects like MeeGo or Android. Properly speaking, this is not an SDK, only a set of scripts that allows to build the sources and create a release almost identical to the official one.
These QboxHD tools were developed one bit at a time as requirements were added to the system and to fit the needs of a small team, taking into account that the development was done in a closed fashion, different from an open development that everybody can follow. I think that’s the reason why, in one hand, they have a specific and practical purpose, and in the other hand, are quite limited if compared to full-blown development environments.
It would be quite nice if this system was migrated to a real full-platform build tool such as Poky. Unfortunately, the SH4-based processors don’t have any support of this kind.
Now let’s move to the source code that was released.
Besides the already known OSS (U-Boot, Linux kernel and Enigma2), the relevant part is in the /src/drivers directory in which some of the drivers that previously were proprietary were now released under the GPLv2.
Inside this directory we get the following drivers:
The drivers avs, e2_proc, includes, multicom, player2 and stmfb were basically taken from the sh4 duckbox project and STLinux and modified accordingly, so these are not really new.
The rest of the drivers are the ones used for controlling most of the decoder’s hardware. The hardware between both boards is quite different, so you’ll see specific drivers and/or macros that differentiate them.
Notice that all the drivers and applications regarding the FPGA inside these boxes remains strictly proprietary…
The fpanel is used for controlling the colours and behaviour of the sense-wheel and front-button of the QBoxHD and QBoxHD-mini, respectively. You can regulate the colours leds… nothing useful, but at least fun.
The lcd controls the front panel LCDs. Since they support at least 64k colours, you can display nice images although the data-transfer speed is not high.
The lpc is only present in the QBoxHD-mini and controls the Stand-By functionality.
The qboxhd_generic resets the tuners at boot time, boring…
The scart drivers controls the analog A/V outputs (SCART, components, composite and audio stereo). The digital video output (HDMI) is controlled by the stmfb driver that is part of the STLinux2.3 distribution.
The frontends directory contains the drivers for the DVB-S2/T/C tuners and pll’s. All of them are based on drivers taken from the mainline Linux kernel, except the DVB-S2 AVL2108 demod (with stv6306 pll) that was developed specifically for these decoders. I don’t know of any DVB-S2 PCI card or USB adapter that mounts this demod, because this driver could be re-used and maybe included in the mainline kernel.
Another interesting directory, specially for the people that wants to start playing around in userland, is the /src/apps directory in which several relatively simple applications such as display_image can be used as example for gaining confidence with the development for these decoders and, in general, with the embedded devices development.
In this directory you can find too the modified sources of Busybox and libdvbsi++ that are Open Source Projects.
As you can see, with all these sources licensed under the GPL, these decoders can be a good platform for people that want to start developing in user or kernel space with Embedded Linux and with a special focus in High Definition DVB devices.
Another benefit is that these boxes could become a reference point regarding openness in the High Definition DVB decoders market since these are basically the only decoders with almost all their sources available.
Openness is a factor that cannot be under estimated.
When i compile this source code by “make BOARD=qboxhd all”, player2 have problem.
player2 cannot found “ACC_Transformers/Audio_DecoderTypes.h” file.
When i found this file ?
Hi, when building the target all it will try to compile even the drivers that need code that is not provided.
You have two options:
1. Compile one driver at a time skipping player2.
For help type
2. Get the missing header files from internet. Google for Audio_DecoderTypes.h.
You SDK use QBoxHD only.
I have MB442 Board.
QBoxHD use First Stage Bootloader, but MB442 have no First Stage Bootloader.
How to write your Binary to MB442 ?
Hi JaeYong, you can write the second-stage bootloader (U-Boot), once written, you can check its environment and adjust it according to your needs. It will give you some errors (it won’t find the front panel LCD nor the fpga) but I think it will keep going with the kernel and filesystem loading.
I have a question maybe stupid, can you please answer it?
Why the QBoxHD Team release the source code? With the source code, I think other people can develop the similar products and compete with QBox.
I am always curious with this idea even I had worked on STB field for years 🙂
Hi, paguilar!~ I am came here, for long time.
Previously, I was busy with myself business(It’s very complex situation),So I didn’t often visit your blog.
Anyway I’m glad come back with good news!.
Previous to joining the company was in the HUMAX of Korea.
Thank u for always good post. Bye.. Regards.
Living from open source software is nothing new, you can see several successful companies doing it such as RedHat that has several competitors. This companies differentiate from others by selling services related to the software such as professional support or by selling premium packages of their software.
In the QBoxHD case and other products from other companies and different markets, the ‘trick’ is that there is a piece of hardware, normally an FPGA, that controls a critical functionality of the system. The firmware that runs in these chips are always proprietary and that helps to prevent others from copying the product.
I hope this answer your question!
Welcome back 🙂
for some reason my QBoxHD is not running so smoothly with the current image provided by DuoLabs. The QboxHD even stops playing a recorded HD video and doesn’t react anymore after approx. 10 seconds playback. Do you know a reason for that? If the QBox would run more smoothly and wouldn’t “crash” after playback, it would be good receiver, but currently it’s useless.
I suceeded in building the kernel and all the modules (incl. player2 stuff) of the current svn revision, but the QBoxHD runs even worse. It seems to block a lot of times during watching television.
Is DuoLabs improving this software revision anymore? I think they will not, am I right? Can you give me some hints, how to find the source of this blocking and video playback crashing?!
Thank you so much!
I cannot say anything on behalf Duolabs nor anything of the current project status since I don’t work for them anymore.
What I can tell you is that the last official release should work fine. I have seen that several people doesn’t have the problems that you mention. To be honest, I haven ‘t tested the latest version, I’m still using 1.0.14.
Try to install only the official release, once you are sure that this works, you can add additional plug-ins, etc.
I remember that, when playback a file, there are some bitrates and/or formats that the QBoxHD doesn’t like and that could give you some problems, but I don’t remember exactly the details.
Once you installed an official release and tried other recorded HD files that don’t give you the problem you could say that the system is ok and that the problem would be what I mentioned above or a hardware problem, but this last option is not likely since a live stream seems to be ok,
Note: If you build everything from svn, there are a few drivers (*.ko files) that are not built (due to license issues) causing some audio/video codecs to be missed.
First of all I have to say sorry for the late answer. I spend a lot of time using different images for the QBoxHD and unfortunately I discovered further/other problems. The root cause of the stopping video playback seemed to be the HDD which I had connected to the eSATA-port. It was the official release which shows this problem! The QBox doesn’t like using the eSATA port, which I wasn’t aware of. After connecting the HDD to the USB port the problems were gone, but new problems arised: Establishing two TCP connections (I tried one FTP and a SSH connection) at the same time seems to make problems. Don’t know why! At least one connection “crashes” or the whole system crashes or is inoperable.
I decided to try to port the current sourcecode to STLinux2.4 and the provided kernel 2.6.32. The kernel, LCD driver and the framebuffer is running without problems now! Of course there are more things to do, but now I’m stuck: The module protocol.ko seems to be responsible for the FPGA stuff. Loading the old module into the new kernel is not possible (even patched). As I don’t have the sources, I can’t compile the module for the new kernel.
Can you tell me which function the FPGA has?! I guess it has something to do with the different frontends / DVB tuner. Is that correct? So if I don’t load the “protocol” module, my QBox won’t be able to decode/receive the DVB stream? If the answer is yes, the story of STLinux 2.4 on QBoxHD will end here :-((.
Yes, the QBoxHD never supported officially eSata hdd; some people was lucky and didn’t have problems, but for most of the people it was unusable.
I never heard about the two TCP connections, so I’m afraid I cannot help with this 🙁
Porting to the 2.6.32 kernel is a thing I always wanted to do, but I haven’t found time for it. It’s very nice that you’re doing it!
Unfortunately, there are some drivers whose source code was never released, at the moment I remember protocol.ko and pti.ko. Let me check if I can get the binaries for the 2.6.32 so you can keep going with the good work.
I hope, the eSATA port will work with the new kernel. Currently I can’t think of a reason, why this port shouldn’t work!
With the new kernel, two TCP connections seem to work without a problem, so the box seems to be more stable.
It would be very nice and cool, if you could arrange, that I’ll get the compiled protocol.ko and pti.ko! I just bought the STMicroConnect to be able to fully debug the QBoxHD, as KDEBUG isn’t supported anymore in STLinux 2.4. So, I hope to hear from you soon! Unfortunately, I haven’t found your mail address. Perhaps we can exchange it in some way?!
By the way: Do you know a person, who is responsible for the Duolabs forum? I can’t get access to it…or rather…no one grants me access to it!
The eSata issue was a problem with the sh4 processor, not the kernel. ST has a (very old) official list of supported eSata hdd. A new kernel could improve the situation but it won’t solve it completely.
Btw, my email address is:
pedro ( dot ) aguilar ( dot ) iniestra ( at )
gmail ( dot ) com
Hi! Since duolabs stopped supporting qboxhd, I was wondering if it is possible to modify the duckbox code for adding support to this box.
If I understood correctly, the current firmware already took part of the driver code from that project.
Do you think it will be possible to adapt the duckbox code for adding qboxhd?
Yes, I think it can be done!
The only thing in which special care must be taken is the FPGA from which there are no sources, only binaries.
I think this could be the only way for having a qboxhd/qboxhd-mini alive.
At the moment I’m very busy with my real job, but if I have time in the near future I would like to contribute 🙂
Thanks for your answer! Good to hear that can be done. I agree with you, this should be the only way to resume this box, that potentially can be a good receiver..
I will try to take a look to the two gits to see if I am able to do something with them. Unfortunately, in this period my job is drastically reducing my free time, too. Do you have any suggestions on where to start? Considering previous comments, I guess it is better to stay on stm2.3 and port the patches of the duo code to a duckbox 2.3 model.
Anyway, when you will be free from real jobs any help will be appreciated 🙂
IS There any luck that you could upload or send archive file source ..? Sourceforge is dead ….
And seems there is no copy on github … if someone can upload a tree files dump somewhere !!!
Hi, sorry for the late reply.
You can find the sources in sourceforge:
Since there hasn’t been any development in a long time, it doesn’t seem necessary to move the sources.