Device Profile: Dreambox DM7000 — an open TV hacker’s paradise
Oct 9, 2003 — by LinuxDevices Staff — from the LinuxDevices Archive — 171 viewsThe Dreambox DM7000 from Dream-Multimedia-Tv (DMM) is a $395 Linux-based digital radio and digital TV (DVB) satellite (or cable) receiver with digital video recorder (DVR) functions and PC connectivity. It is implemented using IBM's STB04500 set-top box chipset, which provides the necessary DVB functions like transport stream demultiplexing and MPEG2 decoding inexpensively. A minimalistic, GPL'd Linux-based software implementation has made the DM7000 popular with Linux programmers and TV device hackers.
The DM7000 features a Common Interface (CI) slot with the same form-factor as PCMCIA (but not the same handling) for conditional access (CA) modules, enabling reception of clear and encoded ASTRA and EUTELSAT digital video broadcasts. It includes a connector for an internal hard disk, a compact flash reader, and an on-screen display and remote control. The device's open-source nature has resulted in availability of dozens of plugins, from various CA modules to games and installation helpers.
The on-screen display menu includes:
- Info menu
- Games menu (Snake and Tetris included)
- File menu (manage local file)
- Setup menu
- Channels (automatic search, manual search)
- Satellite Channels
- Channels — Satellites — Low Noise Block-downconvertor (LNB)
- Network (set up LAN)
- On-screen display settings
- LCD
- Remote control
- Video
- Skin
- Language
- Timer
- Hard disk
- Common
- Firmware upgrade
- Electronic program guide
What's inside?
The Dreambox DM7000 runs on an IBM STB Chip Pallas Pro processor clocked at 250 MHz for 350 million instructions per second (MIPs). It has 64MB of RAM, and boots from 8MB of internal flash memory. It can store video on an internal hard drive (not included), on CompactFlash (via an internal CompactFlash connector), on USB memory stick, or on other external devices.
Dreambox DM7000 front and back panels. Click for larger view
The device offers a maze of interfaces, including serial, parallel, USB, IrDA (not high data-rate — just for remote control), digital I/O (IIC), LAN (100Mbps Ethernet), wireless Ethernet, Audio AC3, RGB, FBAS, YPbPr, audio analog, CI-Interface, SmartCard reader, and CompactFlash Reader. It has a deep standby power-saving mode that uses only 1.2 watts.
DMM provides a complete list of features and specifications on its Web site.
Dreambox DM7000 with hard-drive added.
Software
According to Felix Felix Domke, Software Developer with DMM, the DM7000 runs a linuxppc-2.4.2x-devel kernel, with some minor patches for the Memory Technology Device (MTD) mapping, among other things. “Basically, an unpatched linuxppc-2.4-devel. I have heard that a non-devel will boot, including network, ide, etc.”
DMM chose not to use an off-the-shelf GUI/windowing system such as XFree86, Qt/Embedded, or Microwindows. Instead, the company built its own system, based on the standard Linux framebuffer. This offered the necessary features and a nice C++ interface “without being bloated like QTE.” Domke notes, “I don't want to say that the alternatives were not good — but they just didn't fit into 'our way' for the application. The limited 8MB Flash memory was a reason for not using a generalized GUI library. Of course, this is with the cost that we cannot use or embed standard components like a web browser without much work.”
The Dreambox's main program, enigma, includes a built-in webserver, but Domke notes that some people are using thttpd or even apache as well as edonkey. “Basically, everybody's free to do anything with this box, but in our standard, tv-centric application we don't use many external applications.”
Why Linux?
Domke says that DMM chose Linux because:
- no license fees for offering production quality features like tcp/ip, filesystem, driver framework, etc.
- less experience with other real time operating systems (RTOSs) like VxWorks
- the dreambox should always be “open” for everyone. This wouldn't be possible with commercial operating systems, and there wouldn't be so much acceptance among other developers.
Domke also mentioned a few considerations why some might not want to use Linux:
- more flash/ram overhead
- some performance overhead because of the kernel/user split, or at least it requires more thinking to work around these.
Domke says that the “hardcore” Linux port for the Dreambox was based on MontaVista kernel patches released under the GPL. DMM based the rest of the distribution heavily on the non-commercial linux-on-dbox2 distribution from Tuxbox.org. This saved them from having to buy Hard Hat from MontaVista, according to Domke.
Domke notes that drivers were already available from IBM for the IBM STB04500 chipset that Dreambox is based on, but he says they were not stable enough. “In the end, we dropped them and rewrote them from scratch. The IBM drivers were at that date simply not stable enough, and were too complicated in some points to 'just fix some errors.' As the hardware is very nice to program, we wrote our own drivers, which exactly fit our needs, and we know how to debug them if there are any problems left.”
Standardized (bloated) vs. “DIY” (specialized) approach
Domke wonders if it might have been better or faster in some ways to use standard software components. “Often we decided after trying out available software / libraries / drivers that it would be better to rewrite them instead of fixing them. While 'our' versions of these things often were more lightweight, faster, and more fitting, the downside was that there weren't any programmers who already knew these libraries, and we didn't have much time to write documentation.”
“In retrospect, maybe it would have been better if we had choosen standard components, even if they had a larger memory footprint, were more complicated, etc,” he adds. “[Our do-it-yourself (DIY) approach] meant we had to search bugs from the top level (the application) down to the hardware, since almost no components (except the kernel) were really tested in other environments or in stress tests. Choosing standard things would have maybe saved time for us. But this is pure speculation. I don't know.”
Domke expects time-to-market to replace hardware costs as the most important factor affecting embedded Linux development projects. “As memory and processing power get cheaper, the dominating factor will be more and more the time-to-market instead of hardware costs. The benefit of using a tight (realtime) operating system will be really small compared to other costs.”
Domke also notes that standard embedded Linux components increase portability. “We could use our application 1:1 on another hardware platform with the same API. Since we're using standard APIs (for digital video broadcasting [DVB], for example), our application today runs on the Dreambox, the dbox2 (as part of the Tuxbox project) and — in a limited way — on a PC.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.