This document describes the details of how I got linux running on my friend Peter's eOne computer. (You'll hear a lot of badmouthing of the eOne below. Just ignore it: it's a pretty good little machine.)
The eone is a quirky little piece of hardware: it reminds me a lot of a Mac: non-standard, undocument hardware "features" that can lead to some frustration trying to get linux running well.
The hardware also reminds me a lot of a laptop: for example, the machine comes with pcmcia slots for expansion, and video can only be displayed using the "panel" modes specified by the video card. I suspect they might actually be using a laptop motherboard.
Peter had wanted me to install Redhat on this machine, but after smashing my head against the wall trying to download some 7.0 images, I broke down and installed Debian (my preferred distribution by far).
In addition to being a robust (things actually work!) and secure distribution, debian's package system leaves Redhat in the dust! apt-get is brilliant!
Imagine being able to just type "apt-get install [program x]" and having the package manager automatically download the latest version of program x, automatically determine all of the other packages program x depends on, download them too, install them in the right order, and configure them! And further more, all of the packages work really well: they log things properly (redhat's logs are an embarresement), they are secure (no moronic default settings), and they are compiled to work specifically with your exact system (no more trying to install Suse packages on a redhat system).
Also, you can set up apt so that it can download packages from either the stable distribution or, if you want, from the "unstable" distribution, so you can get the bleeding edge version of the software precompiled to work with your system. At the time of writing, there were 4402 package in the stable release and were 5877 packages in the development (unstable) release. That's a lot of packages.
The one big downside to Debian is that is really designed for computers with high speed internet access. Without it, many of it's advantages over other distributions are not so big. It also tends to be much more text based, which is great for veteran linux hackers, but can be intimidating for newbies. I started out using redhat--the graphical configuration tools are nice (when the bothered to work properly, which was infrequently)--but once I started to learn more, I moved on to debian. Also, I found that since the config files on redhat were designed to work with their gui tools, they were impossible to edit by hand when the gui tools didn't work (which was frequently).
Anyways, enough about debian, lets start talking about the eOne.
As I mentioned above, the eOne seems to use a special "panel" video mode that is defined in the hardware somewhere.
Although the monitor is most likely multiple sync monitor (ie. it should be able to be driven at multiple horizontal and vertical sync frequencies), trying to run the monitor at any set of frequencies other than the ones that the "panel" mode uses will cause the monitor to shut itself down into a power saving mode.
The solution is to install Xfree86 4.0: this seems to be able to detect that this panel mode is present and use it. (Xfree86 3.3.6 actually did give a message that the panel mode was detected, but did not seem to be able to use it.) In fact, in your XF86Config file for 4.0.1 with this machine, you don't have to specify any modelines!
Debian's testing distribution now ships with X 4.0.1. You can download the install disks from their website.
You may have to futz around with the config file. Note that X4 now uses /etc/X11/XF86Config-4 as it's config file.
It may be possible to run this machine with 3.3.6 if you choose a modeline that matches the "panel" mode: I used xvidtune to determine the modeline:
Modeline "eone" 78.05 1024 1072 1168 1376 768 768 771 798
This corresponds to a pixel clock of 78.05 MHz, a horizontal sync of 56.72 kHz, and a vertical refresh rate of 71.08 Hz. This seems to be the only mode that the machine is happy running in.
To use this, insert this line into your XF86Config file in the "Monitor" section, make sure the sync ranges you've chosen include the frequencies I mentioned above, and in the "Screen" section, list "eone" as your only modeline. Let me know if you have any success with this modeline in Xfree86 3.3.6.
This was another frustrating piece of hardware. The linux drivers initially identified it as a tulip card: specifically an Intel 21145 chip.
This was confusing to me since the tulip chip is a 100baseT chip, but the card in the eOne was supposed to be a 10baseT card. When the driver modules was inserted, I got a list of messages, including one that said there was no MII transceiver. If I tried to send packets out on the card, I got a bunch of errors popping out in the logs and even on the console.
The trick is that the card is a crippled tulip chip: it doen't have a 100baseT transciever. Furthermore, the type of transciever it does have is not autodetected by the linux driver, so you have to specify it manually when you insert the kernel module.
To get the card working, first download the source code for the latest version of the driver from the linux tulip driver homepage (you need at least version 0.92: version 0.91g did not work for me). You will need to have the kernel source code header files installed, and have the gcc c compiler installed. (You did install the c compiler, didn't you?)
Instruction for compiling the driver are given in detail on the above webpage: you will need to download the following files into a temporary directory:
The command for compiling the source code is included at the end of the c files in comments. If you have trouble (like errors about finding a file modversions.h), you may have to add an "include" line to the compile command, telling your compiler where the linux kernel source code header files are. For example, if you installed the source code for the kernel version you are using are in the directory /usr/local/src/linux, you would add the command line option:
-I/usr/local/src/linux/includeto the compile command. If you still have errors, cd into the kernel source code directory and do a "make dep". This will remake all of the kernel header files.
Compiling these will produce two kernel modules: pci-scan.o and tulip.o. First insert the pci-scan module into the kernel:
Now insert the tulip driver module, and give it the flag "options=4" to tell the driver to use the 10baseT-FDX transceiver:
insmod tulip.o options=4
You should now be able to bring up the eth0 interface, and send and recieve packets on your ethernet card. You should copy the tulip.o and pci-scan.o files into your module directory, /lib/modules/$(kernel version)/net, overwriting the old tulip.o driver.
Getting these to load automatically on startup will depend on which linux distribution you are using. In debian, you will add a line "tulip options=4" in the file /etc/modules. This file is simply a list of the modules you want the operation system to load automatically at startup. Check with the documentation of your distribution to find out how they handle modules loading.