This archive contains a test program to demonstrate the digital video overlay capability of the EM8400 board in a GCT-Allwell STB6086N2-MPEG2 box. It should work with other boxes of similar like - all you should have to play with is the REQUIRED_PORT_NUMBER define near the top. For the majority of video chipsets, that is going to be somewhere between 1 and 4. Suck it and see!
This works for me, but I offer no warranty of any description. If you blow your box up, that's your problem!

Prerequisites:
1) A GCT-Allwell STB6086-MPEG2 box with an EM8400 based decoder card in it and the VIP (26 way flat ribbon) correctly connected to the video port on the video card.
2) Linux and XFree86 installed (I'm on Redhat 7.2, kernel 2.4.9 with XFree86-4.1.0-25).
3) The appropriate video card drivers (for the GCT-Allwell boxes, this is tvia_drv.o) for XFree86 and the RealMagic drivers for Linux installed (I'm using 1.3.62.0).
4) You need to enable Video4Linux in your XF86Config file. This is usually just Load "v4l" somewhere near the top. You'll know if you haven't done this because it'll complain about the XVideo extension not being there.
5) If you want the TV out to work, you'll need to add the appropriate options to the XF86Config
6) Patience and a probably unhealthy interest in digital video transfer :->
7) X11 development libraries and gcc installed and working.

How to compile
Errr, make. That's it. The 'atoms.c' is stolen directly from xawtv.

How to run
ikldvd <regionno>
e.g. ikldvd 2 to play a region 2 disk.
If the region you request doesn't match that of the EM8400, the program will change the EM8400 region code and exit. Just restart and it should be OK (yes, I know this is just me being lazy!).

NOTE: I have an RPC1 drive and my EM8400 has changed regions many times during the course of this development. I've had no problems. You may end up with a board and/or drive tied to a particular region. Tough!

What it does
Well, it plays DVD's. There is some very basic navigation from the keyboard : Q,q, escape - quits. {h,,j,k,l} is {left, down, up, right} for button navigation. "Enter" selects the current button

That's it!

Comments are welcome to ian@syntaxis-technology.co.uk
download the souce code: em8400_vip.zip

Have fun!
Ian Levy.

This code was almost all written by Ian Levy in 2002. Although I do not claim to be much of a programmer, I was able to modify this code to respond to the native codes sent by the GCT Allwell remote that comes with the STB3036N and 6086N2 set top boxes. This is an ugly hack and I'm sure my code could be improved upon. It does work for me, however YMMV.

The Allwell remote sends ASCII control sequences box just as though you entered the sequence from the keyboard. I have modified the code in ikldvd.c to respond to the following buttons:
The binary was built on a system with GLIB version 2.1.92 and gcc 2.96. You may need to recompile if your system differs significantly. I put the binary in /usr/bin and use a script called playdvd to call the ikldvd binary with a region code of 1 (US). You may need to modify the region code in the included script. This assumes you have already loaded the NetStream2000 drivers as root, and have a script to set ENV vars for the NetStream. I put mine in /etc, so you may have to modify the name and location of that file as well. The environment var file is found in the main NetStream driver directory after the driver has been built for your current kernel.

Enjoy.
download the souce code: ikldvd-remote-hack.tgz

William J. Stotts
wstotts@snet.net

Why is routerlinux here?

Short Version
I wanted a Linux based replacement for Cisco(tm) routers.

Long Version
The company I work has a wide variety of networking needs. I have to maintain more office-to-office tunnels than I can count on my extremities.

The first factor is that, in the old days, Cisco(tm) or Lucent(tm) routers were purchased for each and every office and GRE tunnels were set up to link the offices. GRE tunnels are no longer acceptable for my company, and IPSec is the new norm. Of course every single one of these routers my company owns are NOT capable of 3des IPSec or would require several hundred dollars each in hardware and/or software upgrades in order to become IPSec capable. Pfft I say!

Another factor is that years ago, I made the mistake of opening my big mouth and suggesting that we were paying way to much for those proprietary solutions and that we could recycle our old PC's as Linux routers. Well, it seemed like a good idea at the time, but as it turns out, 10 year old PC's just aren't very reliable. I've had more hard drive and fan failures than I care to recall.

These two factors were the driving force behind routerlinux. An article on linuxdevices.com pointed me at the GCT Allwell STB1030N . This machine provided me with the best of both worlds: it has no moving parts (not even a fan) and is built on the same x86 architecture of my beloved flock of 486 junkers. Also, the PCI expansion slot gives the GCT Allwell machines a wealth of flexibility.

I bought my first GCT Allwell 1030N off EBay for $50 and built up a nice linux distribution from scratch to run on its DiskOnChip. It worked great, so I suggested to my company that we buy a bunch of them and replace all of our incompatable equipment with them. I got 3 more 1030N's and 3 3036N's and when the time came to install Linux on them, I realized what a mess I had made from my first install as I had kept no notes on how I built things. I said 'screw it' and started all over again using same approach Patrick Volkerding uses to build packages for his Slackware Linux distribution. Routerlinux was born.

routerlinux
 

Routerlinux is a GNU/Linux distribution created specifically for turning the GCT Allwell set top boxes into multi-purpose IP routers. Designed to be installed on a 16Mb DiskOnChip module, routerlinux and GCT Allwell hardware combine to form a powerful, reliable, and multi-purpose networking tool.

Intended for use by experienced Linux users, routerlinux lacks an easy to use configuration interface. However, in the true Linux tradition, where it lacks in ease of use, it easily makes up for in functionality:

• IPSec tunnels (manual or automatically keyed) to a variety of platforms using freeswan.
• GRE tunnels
• Full Linux 2.4 netfilter support. This includes IP Forwarding, Masquerading (NAT), Firewalling, etc.
• Run an SNMP server for the purpose of remote traffic monitoring.
• Make a PPP dialup connection via a modem.
• Accept incoming phone calls and either serve a PPP link or a terminal login.
• Make a PPPoE connection (required by many DSL providers).
• Serve PPTP (VPN) connections.
• Speak RIP, OSPF, and/or BGP routing protocols via the zebra package.
• Allow for remote administration through SSH
• Serve out IP addresses with DHCP
• Use DHCP to get an address.
• Answer IDENT requests (albeit fraudulently).
• Run a caching DNS nameserver.
• Allow you to set up tasks to run on regular intervals (crond).
• Use a DB9 serial port to connect to another device with a terminal (microcom ).
• Scan a network or host with nmap
• and more

For more information about routerlinux, visit http://www.routerlinux.com
Contact the author: tony@webteam.net

Since the some of the GCT platforms integrate the TVIA chipset onboard, we must all be prepared to deal with the issue of linux compatibility for development, integration and deployment purposes. This should give you a quick background and guide to the TVIA linux kernel FB world. As it stands, TVIA doesn't release source to any of their drivers unless you pay the [expensive] fee for support. This is pretty standard practice and could be well worth its weight in gold depending on your needs. Thankfully, they do release binary kernel FB modules and XFree86 drivers for linux compatibility.

Fortunately, they have publicly released a kernel FB module for 2.4.4 and 2.4.18. If I remember correctly, the 2.4.4 kernel module was build against a vanilla branch of the linux kernel, while the 2.4.18 fb module is built against a patched version of the 2.4.18 kernel (2.4.18-3 specifically).

On to the meat:

Since I really wanted to be using a 2.4.18 kernel, I tested the compatibility of this 2.4.18-3 module with the 2.4.18 kernel. So far so good.... and I've been testing/using this same module for months now and
developing with the TVIA SDK without any crashes or malfunctions.

Since the 2.4.18-3 fb module is missing a few external dependancies, you cannot insert it into the kernel with the standard 'insmod' command. If you _do_ have the major FB dependancies resolved (see README file), you may insert it into the kernel if you insert the module like this:

insmod -f tviafb.o

Essentially forcing it to load into a somewhat mismatched kernel.

Recently, TVIA has graciously sent me a 2.4.20 kernel module that has been compiled against a vanilla 2.4.20 linux kernel. The only advantage is true compatibility, but like I said, the 2.4.18 kernel module is stable.

Of course the optimal solution would be to have the source and be able to compile support for the CyberPro5k into the kernel, but unless you and/or your company really, really need this, the binary module works just fine.

There is an open-source CyberPro2k,3k,5k kernel driver for linux that is somewhat compatible with the hardware, but it is still in its infancy and does not provide the type of support that the official driver includes. I was also unable to use the TVIA SDK with this open-source driver.

2.4.20 release of the TVIA FB module.
tvia_bin_k2[1]4.20.3.01a.tar.gz

2.4.30 release of the TVIA FB module support Xlib v4.3.(new release)
XFree86_4.3.0_3.00_bin.zip

Sr. Systems Engineer
Codehost, Inc
Rafael Barrero (rbarrero@codehost.com)

Before we begin... This procedure is not for the faint of heart. This requires a really good sense of preparing and configuring kernels, working with kernel modules (compiling, inserting, removing) and linux development (working with gcc, make, and a shell).

Understanding MPEG playback on the GCT set top box

The GCT set top box comes equipped with two graphics cards. The first graphics card is the TVIA on-board card that handles VGA, composite, and S-Video out. The other Sigma card merely decodes MPEGs (and also
has an SPDIF output).

** In order to display decoded mpegs, you will need to enable the VPE port for video overlay from the Sigma decoder to the TVIA chipset. This will require the synclock utility that is part of the TVIA SDK.

*** If you synclock before there is data in the video buffer of the MPEG decoder, you will either experience a system crash, or your video outputs will be unusable. This is why you have to play the video and then initiate the synclock utility.

Warning:
During my testing of these drivers, I have found that depending on the use, you may crash your system or lose your display (in FB mode). Some people have found it easier to laod X windows in order to setup these drivers. However, becuase of my system restraints, I did not use XFree86 at all, and was able to get this up-and-running in no time. I'll explain later on the advantages and drawbacks of XFree86 and the FrameBuffer approach.

Here we go...

If you plan on doing your testing in console mode, I would definitely make use of the TVIA framebuffer. Load the framebuffer module for your particular kernel.

0. insmod tviafb.o

This will give you a framebuffer console and will allow you some luxuries while testing that a normal text mode console would not. I also found I had fewer crashes this way. Note: If you want to load this framebuffer module, you will require some basic FB infrastructure compiled into your kernel. See tvia docs.

1. Gunzip and Untar the drivers (Netstream2000-1.3.62.0.tar.gz)

tar zxvpf Netstream2000-1.3.62.0.tar.gz

2. Compile and load the real magic kerneldriver

cd Netstream2000-1.3.62.0/

./loaddriver 0x8471 (in our case, we're using the mpeg1/2/4 card)

This script will compile the kernel module, insert it and set some environment variables. The 'loaddriver' script takes one argument as
input: 0x8400 or 0x8471 (depending on your hardware decoder). This basically instructs the script which module to compile.

At this point, you have the module loaded and don't necessarily have to logout and login again.

3. Prepare and build the synclock utility

Using 'pico' or 'vi', edit the slkdemo.c file included in the TVIA SDK (tvia/sdkbin.4.20/sample/synclock/slkdemo.c).

You will see two lines:
#define TVMODE PAL640x480
#define STD PAL

Change these values to fit your desired output device. Mine look like this:

#define TVMODE NTSC640x480
#define STD NTSC

Now find the line that calls the synclock function. Looks like:

Tvia_DoSyncLock(PORTB, STD, TVMODE, FORMAT);

Change it to:

Tvia_DoSyncLock(PORTA, STD, TVMODE, FORMAT);

Change PORTB to PORTA becuase that's what the GCT folks say we're using.

Type 'make'

If you have build problems, make sure you have your includes and libraries in the right place so that the compiler can find them and use them during compilation.

After compilation, you will have a 'slkdemo' binary. This is your synclock utility!

4. Play your movie

The Sigma Real Magic drivers include some utilities that utilize their API to decode mpegs. One of these utilities is named 'playfile'. To run this file, you will need to make sure you have the appropriate library dependencies resolved.

You can determine the library dependancies by typing:

ldd playfile

If there are any missing libraries (aka "not found"), locate the Real Magic library directory and add it to your LD_LIBRARY_PATH or /etc/ld.so.conf file.

For example:

./playfile
./playfile: error in loading shared libraries: libEM84xx.so: cannot open shared object file: no such file or directory

ldd playfile
libpthread.so.0 => /lib/libpthread.so.0 (address)
libEM84xx.so => (not found)
libc.so.6 => /lib/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2

export LD_LIBRARY_PATH=/root/Netstream2000-1.3.62.0/lib/

./playfile
(Now it will run and give you usage information)

For my example, I'll play a local MPEG file on my hard drive:

./playfile s /root/video-files/my_movie.mpg

5. Run the synclock utility (slkdemo)

As soon as you have the movie playing, you'll need to run the synclock utility to actually see anything on the output monitor.

If you are running X-Windows, you can simply open another xterm and run the slkdemo binary.

If you don't want to run X-Windows (like me), you can switch to another console (Alt-F2) and run the slkdemo from there. Please note that if you don't have the tviafb.o module loaded, you may have problems switching to-and-fro from consoles in text mode.

./slkdemo

At this point, you should see the mpeg playback on the output device (composite and s-video only - no vga).

6. Automation

Becuase this is a tedious manual process, we have created some shell scripts that will insert the appropriate modules, setup the correct environment and run the utilities. The 'loaddriver' script will also do some of this, but it will also compile the kernel module each and every time, and not play the files, or run the synclock utility.

<snippit>
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export USE_KERNEL_CDROM_SEND_PACKET=/yes
export USE_DRIVE=/dev/hdc

insmod tviafb.o
insmod realmagic84xx.o quasar_dev_id=0x8471

/usr/local/bin/playfile s /root/my_movie.mpg

/usr/local/bin/slkdemo

</snippit>

7. Further development

Here at Codehost, I found the task of running the 'slkdemo' utility after the 'playfile' a real pain to deal with when attempting to automate and simplify our platform.

In this case, I merged both the 'playfile' source and the 'slkdemo' source into one binary that would handle the two functions appropriately. We also customized the 'playfile' program so that it would play any number of files it was passed.

8. Help and Resources

AllWell ( tony@gctglobal.com)
Codehost (rbarrero@codehost.com

Hope this helps!