EPIA HOWTO Andrew Howlett
andrew (at) howlett.net
This Howto explains how to enable linux on an EPIA mainboard. Introduction General The EPIA products are small form factor mainboards, measuring about seven inches by seven inches. They features on-board ethernet, USB, firewire, audio, video, hardware monitoring and CPU frequency control. The EPIA boards use the C3 family of processors which implement Cyrix x86 emulation. The EPIA products are well suited for use in embedded application and silent terminal projects. So first I did the hype, here's the reality - you will have to do some work if you want to use the EPIA features with linux. Sure, you could just install debian, Red Hat or Suse on it, and it will run, but many features will not be available. If you want to get the most out of your EPIA mainboard, you must do some work. This howto explains what you have to do. Some features are better supported than others. In this HowTo I will explain each feature. Here is a brief summary of the state of each feature: Ethernet - well supported, should work "out of the box" on most distros USB - USB 1 is well supported, USB 2 is experimental in most recent distros firewire - experimental in recent distros audio - supported out of the box in a few distros. Others should install ALSA drivers video - VESA works unaccelerated. VIA provides CLE266 accelerated video drivers for some distros. DVD hardware acceleration is only available as a binary library for via-xine. An experimental accelerated frame buffer driver has been released in source code form. hardware monitoring - older EPIA boards lack reliable temperature sensors. Owners of newer boards (i.e. EPIA M series) must compile and install i2c and lm_sensors. CPU Frequency Control - supported by add-on kernel module. Random Number Generation - supported, requires a kernel compile Cardbus/PCMCIA & CompactFlash - supported on all major distributions VIA EPIA CPUs The VIA EPIA boards use VIA CPUs. The identity of the CPUs is very confusing. VIA uses three brand names: Eden, C3 and Nehemiah. The Eden and C3 CPUs use identical technology according to this quote from the Eden ESP FAQ:
The VIA Eden™ Platform is "guaranteed" for fanless designs where the VIA C3™ processor (EBGA Package) is aimed at the general PC market that where there is a demand for higher speeds and less demand for fanless systems. Both the VIA Eden™ ESP processor and the VIA C3™ processor are based on the same process technology. The difference comes in where the VIA Eden™ ESP processor goes through a different production flow where the conditions for testing and reliability control for ultra low voltage and power, as well as high Tcase, are implemented. Customers may try to lower the speed/voltage of VIA C3™ processor (EBGA package) to achieve the same goal but VIA does not guarantee the stability of the platform while running fanless, out-of-spec VIA C3™ processors (EBGA package) where the Tcase specification is limited to 70 degrees C. Note: The VIA C3™ processor can operate in a "fanless" environment that has been "customized" for passive cooling, but this is not guaranteed for general designs. As for LongHaul2 technology (that can lower the voltage), this is only supported in the uFCPGA package used in the mobile market. From the core design perspective, we do leverage the design intelligence from the same R&D team (Centaur) that designed the VIA C3™ processor, but VIA Eden™ ESP processors are specially processed for fanless designs.
So Eden and C3 are marketing terms for chips which are technologically identical but have different heat and power related guarantees. On the other hand Nehemiah does describe a different technology - the Nehemiah core. But what technology did older C3s use? The older C3 (and Eden) processors use Samuel, Ezra and Ezra-T cores. The table below presents what little data I have found regarding these CPUs. Please provide additional data if you have it. VIA CPUs ID Name Core Fam.Mod.Step Speed (MHz) Comments flags C5A VIA Cyrix 3 Samuel 6.6.0 500-733 12 stage pipeline; FPU @ 50% clock; 1.8-2.0v; CPGA; 75 mm2; 0.18u Al; 11.3 mil transistors; 2001-06-06 C5B VIA C3 Samuel 2 6.7.0-7 450-650 12 stage pipeline; FPU @ 50% clock; 1.6v; CPGA/EBGA; 52 mm2; 0.15u Al; 15.2 mil transistors; 2001-03-25 (fpu de tsc msr cx8 mtrr pge mmx 3dnow) -march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer -mmmx C5C VIA C3 Ezra 6.7.8-f 800-1000 12 stage pipeline; FPU @ 50% clock; 1.35v; CPGA/EBGA; 52 mm2; 0.15u/0.13u hybrid Al; 15.4 mil transistors; 2001-09-11 -march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer -mmmx C5M/C5N VIA C3 Ezra-T 6.8.0-f 900-1200 12 stage pipeline; FPU @ 50% clock; CPGA/EBGA/uPGA2/uFCPGA; 56 mm2; 0.15/0.13u hybrid (Cu); 15.5 mil transistors; C5N=copper interconnectrs; 2002 -march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer -mmmx C5X VIA C3 Nehemiah 6.?.? 1100-1300 16 stage pipeline; 2 SSE units; FPU @ full clock; 0.13 (Cu); 78 mm2; 2003-01-22 -march=i686 -msse -mmmx -mfpmath=sse -O3 -pipe -fomit-frame-pointer C5XL VIA C3 Nehemiah 6.9.0-5 1000-1200 16 stage pipeline; 2 SSE units; FPU @ full clock; 0.13 (Cu); 54 mm2 (fpu de tsc msr mtrr pge cmov mmx fxsr sse) -march=i686 -msse -mmmx -mfpmath=sse -O3 -pipe -fomit-frame-pointer C5P VIA C3 Antaur 6.9.8 1000 - 1200 GHz 16 stage pipeline; 200 MHz FSB; 2 SSE units; FPU @ full clock; SMP; 2xRNG+AES module; 47 mm2; (fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse rng rng_en ace ace_en) -march= -mcpu=i686 -funroll-loops -msse -mmmx -mfpmath=sse -O3 -pipe -fomit-frame-pointer C5I VIA C4 Esther 2 GHz Pentium M bus, new chipset (?), SMP, SSE2; RNG+AES+SHA1 module
The C5P and C5I information was taken from the extremetech.com article. The clock speeds are approximate. Technically, CPU speed is determined by the front side bus speed and the cpu multiplier and is limited by heat dissipation. For more information regarding FSB and cpu multiplier, see the CPU Freqency Control section. The compilation flags have been determined by experimentation. Some users claim that -march=i486 produces more efficient code than -i586. Also, starting in gcc 3.3 you may use the -march=c3 flag to specify VIA Samuel, Samuel2, Ezra and Ezra-T processors. Some experimenters suggest that code compiled using -Os (compile for size) will run faster than -O3 (compile for speed) because the VIA processors have very small cache and the smaller code will improve the chances of cache hits. I haven't seen any numbers to confirm this - maybe someone will try it and let me know if it is true. For more information on gcc optimizations see the excellent Wiki at courville.org Some other tidbits: the Nehemiah processors can run at bus speeds of 66, 100 and 133 MHz and use the Tualatin protocol. The Nehemiah is designed by Centaur Technologies. VIA bought Centaur and Cyrix many years ago, but the Cyrix team quit, so the newer VIA processors contain no Cyrix technology. VIA EPIA Models There are six families of EPIA mainboards. The primary difference lies in the choice of chipset - the north bridge and south bridge chips. The north bridge chip connects to the CPU, RAM, and AGP bus. In the case of the EPIA boards the AGP graphics processor is integrated on the Northbridge chip. The EPIA boards use one of two Northbridge chips: the PLE133 or the CLE266. The PLE133 uses 133 MHz SDRAM. The CLE266 is more powerful - it uses DDR266 modules. Both have integrated 2d/3d accerated AGP4x graphics processors with MPEG2 decoder. Both include the PCI bus controller; both can provide both 100 and 133 MHz front side bus. The south bridge chip connects to peripheral devices. The EPIA boards use one of two different south bridge chips: the VT8231 or the VT8235. Both chips include a keyboard and mouse interface, floppy disc controller, parallel printer, serial ports, game port, infra red, 100BaseT ethernet, SB-Pro and AC97 codec, UDMA EIDE controller, RTC, ACPI, hardware monitoring, and USB. Note that although the chips support all these functions some may not be implemented on a particular board - for instance the EPIA and EPIA TC boards lack floppy connectors. The 8235 is a natural upgrade of the 8231 - it supports USB 2.0, ATA133, AC97 2.2. The 8231 connects to the north bridge on the PCI bus, whereas the 8235 can use the PCI bus or an advanced proprietary connection which operates four times faster than PCI. In addition to the south bridge integrated peripheral controllers, EPIA boards will include an audio codec (VT1612 or VT1616) and a networking controller (VT6103). EPIA boards may include a TV-OUT interface (VT1621 or VT1622) and a firewire interface (VT6307S). EPIA Families Family north bridge south bridge Comment EPIA PLE133 8231 TV-out, one ethernet, 2xIDE no floppy EPIA V PLE133 8231 similar to EPIA but faster CPUs, TV-out optional, 1 IDE and 1 floppy EPIA M CLE266 8235 faster than EPIA, better chipset, USB2 + firewire, 2 IDE, 1 floppy EPIA CL CLE266 8235 similar to EPIA M but no tv-out, 2 ethernet, 1 LVDS EPIA TC CLE266 8235 EPIA M -tvout + LVDS - ATX + 12vDC, optional cardbus & compactflash, uses SODIMM, 2 IDE, no floppy EPIA MII CLE266 8235 EPIA M + cardbus/compactflash
The EPIA V is a higher speed version of the EPIA with optional TV-out and they replaced one of the IDE ports with a floppy port. The EPIA TC is especially interesting because it does not use an ATX power supply - instead it takes 12v DC in. Special power connectors on the board provide power to the hard drive and DVD drive. The EPIA M is probably the most common model. Users have submitted information about some specific models: EPIA Models Model Number CPU Family 5000 C3 533 MHz EPIA ME6000 C3 600MHz; 1196 bogomips; flags: fpu de tsc msr cx8 mtrr pge mmx 3dnow EPIA M 800 C3 800 MHz; 1596 bogomips; flags: fpu de tsc msr cx8 mtrr pge mmx 3dnow EPIA V8000 C3 800 MHz EPIA V M9000 C3 933 MHz EPIA M M10000 C3 1 GHz; Note that some M10k boards use Ezra and some use Nehemiah CPUs. EPIA M M10000N Nehemiah 1 GHz; 1992 bogomips; flags: fpu de tsc msr mtrr pge cmov mmx fxsr sse EPIA M
Attention: Newbies read this Getting all this to work requires some experience building software from source. If you have installed linux for the first time on your new VIA EPIA and never compiled a tarball, then you might be in for a shock. Prepare for some linux hacking. But if you read through this HowTo and decide that you aren't ready for it yet, don't worry too much. The VIA EPIA features are already in linux 2.4.23-test3 and xfree86 4.3.99-12. So all you have to do is wait until next year when the next stable versions of linux and xfree86 come out. Then the distribution companies like Red Hat and SuSe will package it for you in their next versions and you can install it with less difficulty. Binary packages VIA distributes binary packages for Mandrake, Red Flag, Red Hat, and Suse. These binaries include drivers, kernel modules and utilities. Many of the driver packages are useless. One or two are good: notably the CLE266 and viaexp packages. Just about everything that is available in a VIA binary package can be done from source following the instruction in, or linked from, this HowTo. Distributions The Eden and C3 CPUs implement Cyrix x86 emulation. Most distributions will recognize the CPU as a 586 or 686, and installation should happen smoothly although there are some problems - notably with some SuSe and Red Hat CD-ROMs. VIA officially supports four distros: Mandrake, Red Flag, Red Hat, and SuSe. VIA does not support debian or gentoo, but with some effort you can get everything working even in the unsupported distributions. I will try to collect distribution specific info in the following sub-sections, time permitting. Debian Debian Testing (aka Sarge) works well with the EPIA boards. If you are doing a new install, I recommend using the Sarge netinstall cd. Select the 2.6 kernel. Netinstall should automatically detect and install drivers for LAN, usb, firewire, audio and pcmcia. As of this writing (November 2004), Sarge uses XFree86-4.3.0-1.8-dfsg. Select the via driver during debconfig. This via driver is functional, but does not support accelerated video. See the Video section in the next chapter for instructions on how to install DRI on a debian system. Fedora The default Fedora Core 3 and core 2 kernels are compiled for 686, which means that it will work fine with Nehemiah processors, but older processors will suffer the CMOV bug. For older processors, you can install fedora using the procedure described below, or switch to debian or fedora core 1. If you have a Nehemiah processor, then fc3 will work out of the box with no problems. Fedora will install the VESA Xorg driver. You can download Unichrome rpm packages courtesy of Terry Barnaby. In order to get fc2 and fc3 to work with non-Nehemiah CPUs you must do the following: Download the fedora c3 boot iso burn it on to a CD as a CD image boot off it at the first menu swap in the normal FC2 CD1 and install FC on install completion, where it says to remove the CD and it will reboot, type ctrl-alt-F2 to get to a console chroot /mnt/sysimage stick back in the CD you booted from (replace hdc with your cdrom device if different) mount /dev/hdc /mnt/source -t iso9660 rpm -Uvf /mnt/source/kernel* type ctrl-alt-F1 (for text mode install) or crtl-alt-F7 (graphical wqinstall) and complete the install You should reboot into a working kernel Fedora core 1 works well with EPIA boards - USB, LAN, lm_sensors, sound. A Fedora core 1 install will "just work." But the default install uses the XFree86 VESA driver. If you want accelerated video then you have two choices: install the closed source binary drivers from viaarena or use the open source drivers provided by Alan Cox. The closed source drivers include install instructions. If you decide to use open source drivers then you must recompile the kernel to support VIA DRI, download the XFree86 drivers from Alan Cox's web space, and manually install the XFree86 drivers. You can get the fedora iso images from this bittorrent. Gentoo Gentoo can be installed on EPIA. Tony Murray has created an excellent gentoo howto. Knoppix Knoppix 3.3 works very well with EPIA (sound, USB, XF86 VESA video, etc). Furthermore, knoppix is a debian distribution, so it is possible to get everything working following the debian instructions. There is a short knoppix specific howto at HowTo Install Knoppix on the EPIA M10000. Mandrake Mandrake 10.1 will install fine on the EPIA machines. Unfortunately, it will install an i686 kernel on the EPIA boards. This kernel doesn't work with Ezra and Samuel CPUs (e.g. ME6000, EPIA5000, and some M10000). On these machines you must install the Mandrake i586 kernel. After the install, boot the machine in rescue mode (boot from disc 1, select "More Options" and type "rescue" at the prompt). Use the menu option to change root into the hard drive. Launch the Mandrake Software Installation tool and type "kernel" in the search box. Install kernel-i586-up-1GB-2.6.8.1.12mdk. Reboot the machine. The new kernel should appear in the lilo boot menu. Red Flag The via proprietary drivers support some versions of Red Flag, but I have no other information regarding this distro. Red Hat The old Red Hat branded free distributions are getting pretty old, but they are tested and reliable. Therefore I have kept this section about Red Hat in the HowTo, but it hasn't been updated in a lllooonnnggg time. VIA supports Red Hat Linux versions 7.3, 8.0 and 9. Version 7.3 is ancient and will not be discussed in this howto. Red Hat 8.0 used to be the best supported distro for EPIA - although Red Hat discontinued its support of version 8.0 on 2003-12-31. The Red Hat 9 kernel supports VT82xx sound "out of the box" but some M10000 users have reported installation problems. Red Hat Enterprise Linux suffers the same gcc conditional move problem as Suse 8.2. So Red Hat Enterprise Linux will probably work on the Nehemiah CPUs (I haven't tested it) but not on the C3 processors. Note that the VIA binary drivers are compiled against the original Red Hat kernels. You cannot upgrade your kernel. For instance, if you use Red Hat Network (rhn) or up2date, and rhn upgrades your kernel, then the via binaries will no longer work. However some of the kernel upgrades are necessary to remove potential security problems. You have to make a decision - keep the original kernel and risk being hacked, or upgrade the kernel and lose the binary drivers. If you want to make a more informed decision about exactly what vulnerabilities you might be exposed to, you could check the Red Hat security errata page. SuSe SuSe is very popular amongst EPIA users. VIA supports versions 8.1 and 9.0. If you use a different version then you must use the open source video drivers. Versions 8.2 and 9.0 suffer the gcc conditional move problem, so don't use SUSE with older Ezra or Samuel 2 CPUs. I have heard that Suse 9.1 works ok on both the PD1000 (Nehemiah) and EPIA 5000 (Samuel 2) boards. MiniMyth MiniMyth is designed to boot over a network and run on a diskless EPIA M system. It then automatically starts up X window and runs mythfrontend from MythTV, version 0.15.1. It will run on all EPIA M series systems. It will not run on other EPIA platforms (e.g., V series). In the current release (0.5.1), a few types of receivers are supported out-of-the-box. A homebrew IR receiver, a Pinnacle PCTV Pro external IR receiver, and the ATI RF receiver. See below for how to specify which one. It is also easy to add your own remote configuration. This release provides TV Out (800x600) as well as CRT out. TV Out defaults to NTSC but can be switched to PAL with a simple kernel command line argument. The release runs on Linux 2.4.24 -epia1. A compiled kernel is available in the download section, along with the .config file. It uses XFree86 4.3.99.902-epia7. The image is currently about 66M, but since it runs in a cramfs file system, it really only takes up about 34M. On a system with 256M, this is plenty of headroom. Freepia Freepia is a small GNU/Linux distribution designed to run on Via Epia-M Mainboards. It currently runs on the M-9000 and M-10000 (ezra and nehemiah cpu) but with some modifications like kernel and X11 modules it should run on others too. (if someone has get it running on other Epia\x{00B4}s let me know). The main motivation behind this project is to build a full featured, low noise media box to play movies/mp3s/images etc. For this it uses freevo but in the future there maybe support for others like mythtv or vdr. Ethernet Linux supports the VIA EPIA boards using the via-rhine driver. The mii driver is optional. This module is included with recent distros and should load automatically.. If it doesn't load, then try these commands: bash# /sbin/modprobe via-rhine bash# /sbin/modprobe mii There are several problems to look out for: Test kernels. Some test versions of the kernel, such as some of the 2.4.23-test and 2.4.22-ac versions, include broken versions of the via-rhine driver. If you plan to build a new kernel you should read the bug reports first. Insufficient power. Many users have reported that their on-board ethernet ports do not work using stock kernels from VIA supported distributions. This behaviour is almost always due to insufficient power. If the power supply cannot deliver enough power to the EPIA board, the first thing to fail will be the ethernet chip. If you have ethernet problems try using a more powerful power supply. For instance, if you use a 50W or 60W PSU, full size drives and a PCI graphics card, then you will likely experience ethernet problems. ACPI. Some users report a conflict between the Advanced Configuration and Power Interface (ACPI) driver and the ethernet driver. This problem affects both the on-board ethernet port and any additional ethernet cards used in the PCI slot. There are several ways to avoid this problem. You could boot the kernel with the pci=noacpi, you could booth the kernel with acpi=off, or you could use a kernel with no acpi built in. USB The VIA EPIA boards support USB 1 and 2. Linux supports USB 1. USB 2 is still experimental but many recent distros include USB 2 support. USB should work without any manual configuration. Firewire Same as USB2. Audio The VIA EPIA boards use the VT1612A and VT1616 audio controllers, but you won't see them on the mainboard because they are integrated onto the Southbridge chip. EPIA boards use the 8231 southbridge (which includes the VT1612A) and EPIA M-series use the newer 8235 (which includes the VT1616). The VT1612A is a two channel AC97 codec; the VT1616 supports 6 channels. Both include microphone in and digital in. This section will discuss three audio drivers: the linux 2.4 kernel driver, the viaaudiocombo driver, and the ALSA drivers. I used to recommend the ALSA drivers, but I've been converted to viaaudiocombo. I have found that viaaudiocombo has fewer clicks and pops. The ALSA stuff will stay in this document in case someone needs it. Kernel Audio Support Some of the latest distributions include kernels with working 82xx support provided by the via82cxxx_audio kernel module. For instance, the Red Hat 9 kernel supports EPIA M audio. However earlier distributions such as Red Hat 8 will not. VIA Audio Combo VIA provides a single linux driver which supports the following audio chips: VT82C686A, VT82C686B, VT8231, VT8233, VT8233A, VT8233B, VT8235, and VT8237. The driver is available from the viaarena linux audio page. This is a good driver: in addition to supporting all the via sound chips, it also supports all their special features such as six channel audio and S/PDIF. The driver is distributed as a source rpm, which is great for rpm based distros but not so good for gentoo and slack. I will have a short description of installing for rpm based systems, then a short description of how to install for non-rpm based distros. The viaudiocombo driver creates a /dev/dsp device, so you can tell applications like xmms to use the OSS driver and that will be ok. In order to use the advanced features like six channel sound the application must have support for the viaudiocombo driver. The aumix command line mixer works with viaudiocombo. kmix does not work. VIA Audio Combo RPM Install Download and extract the viaudiocombo package from viaarena. It contains a source rpm. Build the source rpm bash# rpmbuild --rebuild viaudiocombo-2.3-1.src.rpm Now change to the /usr/src/redhat/RPMS/i386 directory. The viaudiocombo-2.3-1.i386.rpm file should be there. If it isn't, then look in the i586 or i686 directories. Once you have found the rpm install it: bash# rpm -ivh viaudiocombo-2.3-1.i386.rpm The rpm package includes install scripts which should modify your /etc/modules.conf file, your /etc/sysconfig files, and your /etc/rc.d files. These scripts should also stop and remove any existing audio drivers. But sometimes these scripts don't work - for instance, if an audio application is running, even if it is just sitting idle in a background process, the install script will fail. In which case you should follow the directions from the non-rpm distribution installation in the following section. VIA Audio Combo non-RPM Install The source rpm contains an rpm spec file and the viaudiocombo source tarball. You need to extract the source tarball from the source rpm. The easiest way is to install the source rpm using the rpm install command (shown below) which will install the source tarball at /usr/src/redhat/SOURCES. Or you can use the rpm2cpio command which will extract it to the current directory. Or you could ask someone at the viaarena linux forum for help. bash# rpm -i viaudiocombo-2.3-1.src.rpm bash$ rpm2cpio viaudiocombo-2.3-1.src.rpm | cpio -i Once you have the source tarball you can extract it and run the install.sh script. You have the source code for the current kernel - look at the install.sh script for source locations. After the compile you should copy the viaudiocombo.o module to /lib/modules/{kernelversion}/kernel/drivers/sound and run depmod. You should copy the viasound script to your /etc/init.d and make a symlink in /etc/rc.d/rc5.d or wherever your init scripts are stored. Finally, add this line to /etc/modules.conf: alias sound-slot-0 viaudiocombo If you had other sound drivers installed, then you should remove their stuff from /etc/modules.conf and the init directories. ALSA The Advanced Linux Sound Architecture (ALSA) version 0.9.6 works well with the 8231, 8233 and 8235 chips. If you use an rpm based distro then you can download ALSA rpms from freshrpms.net; you will need five rpms: alsa-drivers, kernel-module-alsa, alsa-lib, alsa-lib-dev, and alsa-utils. The remainder of this section will discuss installation from source. First, download the alsa 0.9.6 drivers from the ALSA Project. The alsa via82xx driver supports both sound chips so the instructions are the same for both chips. There is a lot of documentation for the alsa 82xx driver: the ALSA sound card matrix, the AlsaOpensrcOrg via8233 wiki, the INSTALL file included in the tarball, and especially alsa-driver-0.9.6/alsa-kernel/Documentation/ALSA-Configuration.txt are good sources. I have tried to synthesize the most relevant information into this HowTo. Before installing the alsa drivers you should uninstall any other sound modules that might be in the kernel. Use the lsmod command to find out what modules are installed and the rmmod command to remove them. Next, download, unzip and extract the tarball. Next, configure the source. When configuring the alsa-driver source, use the command: bash# ./configure --with-cards=via82xx --with-sequencer=yes The --with-cards=via82xx argument ensures that only the via82xx hardware driver gets built and installed. The alsa build process will look for your kernel source at /lib/modules/$KERNELVERSION/build. If you want to compile for a different kernel then use the command below, then the normal make and make install and run the snddevices script. bash# ./configure --with-cards=via82xx --with-sequencer=yes --with-kernel=/my/kernel/path bash# make bash# make install bash# ./snddevices The snddevices script adds the necessary devices files in the /dev directory. ALSA should automatically add some lines to your /etc/modules.conf file, but sometimes it doesn't, so you must check. This is what you should see: # --- BEGIN: Generated by ALSACONF, do not edit. --- # --- ALSACONF verion 0.9.0 --- alias char-major-116 snd alias snd-card-0 snd-via82xx alias char-major-14 soundcore alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss options snd major=116 cards_limit=1 options snd-via82xx index=0 dxs_support=3 Depending on your distro, you might already have some OSS sound devices programmed into /etc/modules.conf. It would be prudent to comment out those lines to eliminate confusion between the originall OSS drivers and the newer ALSA drivers; something like this: #alias sound-slot-0 via82cxxx_audio #post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : # pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || : Now you have to download, build and install the alsa-lib and alsa-utils-0.9.6 tarballs, also from the ALSA Project. Build and install them using the standard build-from-source procedure: bash# ./configure; make; make install Depending on your distribution, you might have to modify your library path. Further instructions regarding the library path are included in the appendix. Now you have built and installed ALSA. So you run your favourite multimedia application and ... you still can't hear anything. At this point many people get extremely annoyed, but you must fix one more thing. When the kernel loads the driver it sets all the channels to zero volume and mutes them. The VIA support file includes a script which, when executed, resets the volume and unmutes each channel. The script is named "audunmute". You have to unmute and set the volume for each channel. You can control the mixer settings using whatever mixer program you like. Or you can copy the following lines into a text file named alsa_set_mixer.sh: #!/bin/sh amixer set PCM 22 unmute amixer set PC\ Speaker 22 unmute amixer set Master 22 unmute amixer set Master\ Mono 22 unmute amixer set Headphone 22 unmute amixer set Phone 22 unmute amixer set Aux 22 unmute amixer set Video 22 unmute amixer set CD 22 unmute amixer set Input\ Gain 22 unmute amixer set Line 22 unmute amixer set MIC 22 unmute and set the file as executable bash# chmod +x alsa_set_mixer.sh Notice that it just runs the amixer utility to set the properties for each channel. You can run this script manually every time you load the snd-via82xx module, but a better way is to modify the /etc/modules.conf file to automatically run the script. After the alsa driver lines, add the following line: post-install snd-card-0 /usr/local/bin/alsa_set_mixer.sh>/dev/null 2>&1 || : Then copy the script file to /usr/local/bin/alsa_set_mixer.sh, like this: bash# cp alsa_set_mixer.sh /usr/local/bin Now the channels should be set automatically each time you load the driver. On some older boards users have reported contention between X and the sound system. You might be able to reduce the problem by adding this line to the Devices section of /etc/X11/XF86Config: option "PciRetry" "true" Six Channel Audio Both the viaudiocombo and ALSA drivers support six channel. raltieri tried both drivers and he suggested that viaudiocombo works better. On the other hand, Bheremans offered a good description of how he got six channel audio to work using ALSA:
From: Bheremans Date: Thursday February 26, 2004 2:37 PM It took some evenings but I have six sound working wohoo , first some specs: # distro : Gentoo # audio Driver : Alsa 1.0.2 # mplayer : 1.0-pre3 # xine : xine-ui 0.9.23 , xine-lib 1-rc2 For playing dvd's I normally use xine, I did choose the alsa driver, and activated 5lfe channel For Divx and others I use gentoo, for 6-channel files I use : -ao oss:/dev/adsp -channels 6 If you play a two channel file with these options you will get sound out front and rear, if you wan't to activate others I did it with this : -af channels=6:6:0:0:1:1:0:2:1:3:0:4:1:5 Finally some noise in the house ;-) The problem why it wasn't working was not the software !! I had a case with front audio connectors, so I removed the jumpers that default are on pin 5&6 and 9&10 on the onbaord audio connector. I'm not using this case anymore and I don't have front audio connectors anymore, but I dind't put the jumpers back, aaaarghhh. So much trouble and it where just the jumpers. After putting them back all speakers worked right away. So it all works nice and I don't have to use the binary viaudiocombo driver :-) Bart
Six channel analog output uses the three mini-phono sockets. See your mainboard user's manual for details. The top socket is Line In, the middle one is Line Out, and the bottom one is MIC. If your manual isn't handy, here's what it says:
VIA EPIA-M USer's Manual November 4th, 2002 Please note when 6-channel applications are used, all three connectors become output connectors. Line-Out becomes Front L/R; Line-In becomes Rear L/R; Mic-In becomes Center/Sub.
Six channel audio must be supported by the application. For instance, to run mplayer with six channel audio you might use the following command: bash$ mplayer -af channels=6:6:0:0:1:1:0:2:1:3:0:4:1:5 -channels 6 mp3file.mp3 I have also read that the -af surround 0 option will play a two channel audio file to the rear speakers. Regardless of whether you decide to use the viaudiocombo or ALSA sound drivers, you must use the ALSA mixer. You should "mute all downmix channels and unmute alternate level to surround out.". Here is the mapping of mixer controls to speakers: Mapping Mixer Control to 5.1 Speakers Mixer Control Speakers Master Front Headphones Rear PCM Master
S/PDIF Sony/Philips Digital Interface (S/PDIF or SPDIF) is a standard digital audio transfer format (see ePanorama.net for more info about the standards). SPDIF allows the audio hardware to transfer the audio information to another digital audio device in digital format. VIA supports six channel SPDIF audio on the RCA jack using the viaudiocombo driver. Of course, if you are using the RCA jack for SPDIF, you cannot use it for TVout. A jumper on the EPIA board determines whether the RCA jack will be used for SPDIF or RCA Video. Consult your User Manual for the location and pin-out of the jumper. If you intend to use S/PDIF then you must use the spdif_out=1 option when you load the viaudiocombo driver e.g. modprobe viaudiocombo spdif_out=1. To use S/PDIF with the ALSA modules, you must first execute the command amixer set 'IEC958 Playback AC97-SPSA' 0. This command does not set the volume - S/PDIF output is always at maximum volume. Instead, it sets the S/PDIF channel. The settings are: 0 - PCM1; 1 - PCM2, PCM1 (rear); 2 - Center and LFE; 3 PCM3, modem dedicated S/PDIF. The application must send its output to the S/PDIF device. For instance, to play PCM with mplayer using spdif, use the mplayer -ao alsa9:iec958 command; or to play AC3 use mplayer -ao alsa9:iec958 -ac hwac3. 48kHz Sampling There is a serious issue regarding the sampling rate of the VIA DSP. I won't claim to understand it, instead I'll copy a message from someone who definitely knows what he is talking about. This message was posted to the alsa-user mailing list by Takashi Iwai. * From: Takashi Iwai * Subject: Noises on via82xx (Re: Fwd: Re: [Alsa-user] Onboard via8233 crackling) * Date: Wed, 02 Jul 2003 10:16:34 -0700 At Wed, 2 Jul 2003 18:11:27 +0200, Gregor Riepl wrote: > Isn't there any documentation on this? > I would really appreciate if someone could finally sort this trouble out > since there are a lot of people who use a VIA8233+. ok, let me explain briefly about this theme. VIA82xx chip has different revisions, and the behavior of the chip depends on the revision. basically, via chip has two different playback modes. one is called DXS (direct sound) mode, and another is multi-channel mode. the former supports only two-channel format but you can play up to 4 streams at the same time. the sample rate of these 4 streams must be identical, though. the another mode, multi-channel mode, supports only one stream but you can play from 2 to 6 (5.1) channels with this. obviously, this is used for playback of AC3 decoding, etc. in the recent ALSA via82xx driver, the DXS mode is used as default (i.e. the first pcm device hw:0,0) on the chip models which support it. the multi-channel mode is assigned to the secondary pcm (hw:0,1), which corresponds to /dev/adsp in the OSS-emulation mode. the chip with the revision 0x40, which is called VIA8233A, has no DXS mode. other revisions, VIA8233, 8233C and 8235, do support it. each DXS channel (from 0 to 3) has an indepedent stereo volume. please make sure that these volumes, "VIA DXS Playback Volume", are set to full (although they are initialized to full as default). unfortuantely, some motherboards have the problems of DXS channels. on some, DXS mode doesn't work at all, and on some, only 48kHz is available (otherwise you'll hear click noises). according to the people of VIA tech, this is because of the BIOS (typically AWARD BIOS). so, one solution is to update the BIOS. but it's not always a preferred solution. in the recent driver version, a workaround is provided instead. there is a module option "dxs_support", which defines how to handle the DXS channels. if you have a problem with the first pcm device, try dxs_support=2 or dxs_support=3. when dxs_support=2 is given, the DXS mode is disabled and you'll have only the multi-channel playback mode. this means, the chip is handled as VIA8233A. of course, you can play only on stream. in this case, dmix plugin would be a workaround. when dxs_support=3 is given, only 48kHz is allowed for the DXS channels. that means, the sample-rate conversion will be done in alsa-lib or OSS-emulation for playing MP3. but it's cheaper than dmix plugin. so, try this once, and if still doesn't work, try the previous one. how to add such an option? if you already have module options for via82xx driver, you should see the line like following in /etc/modules.conf options snd-via82xx index=0 and just add dxs_support=2 (or 3) there. options snd-via82xx index=0 dxs_support=2 then restart the driver. in future, i'll add a black-list of motherboards which don't work well with DXS mode. if your mobo needs the workaround above, please let me know the pci-subsystem vendor/device ids, which can be obtained via "lspci -nv" command. Takashi It seems to help if you force your applications to deliver 48 kHz sampling to the sound driver. Then no cross sampling is required (or at least, the audio application is doing the conversion). Each audio application has a different method to force 48 kHz sampling. Here are some "magic words" which might help. bash# mplayer -aop list=resample:fout=48000 myfile.mp3 bash# mpg123 -r48000 myfile.mp3 bash# mplayer -ao oss -srate48000 myfile.mp3 You might also create a ~/.asoundrc file containing the following lines: pcm.via82xx { type plug slave { pcm "hw:0,0" rate 48000 } } ctl.via82xx { type hw card 0 } XMMS XMMS comes with many distributions, but ALSA support might not be compiled into the distributed version. XMMS is Free Software, and simple to compile. First, download the xmms-1.2.7 source and the alsa-xmms-0.9.12 plug-in. But before you start compiling, remove any existing copies of xmms. For instance, if you use Red Hat, use this command: bash# rpm -ev --nodeps xmms xmms-skins Then compile and install xmms and alsa-xmms. Strangely, I couldn't hear anything even after changing to the ALSA 0.9 plug. Someone suggested using the crossfade plug-in. So download, compile and install the crossfade plug-in. Now you have to configure xmms and crossfade. Launch xmms. Use ctrl-P to get the preferences window. Set the output plugin to crossfade, and click the configure button. Under the Output tab, set the sampling rate to 48000 Hz and set the output plug-in to ALSA 0.9. Now click the Configure button for the ALSA plug-in and set the Mixer Device to PCM1. Click the "Apply" and "OK" buttons, and again "Apply" and "OK". XMMS should work now. Video The VIA EPIA M series use the CLE266 video chip. The VESA generic driver included with Red Hat 8 works with the CLE266 chip but doesn't support any of the CLE266 advanced features such as 2d/3d hardware acceleration, TVOUT, video capture and direct rendering. VIA XFree86 Driver The XFree86 VESA driver will work with the PLE133 and CLE266 graphics processors, but VIA provides an accelerated XFree86 "via" driver from their www.viarena.com downloads area. There are different downloads for the PLE133 and CLE266 chips. I will describe the procedures for the CLE266 chip. The drivers are distributed in binary format. The download site lists different packages for different distributions but those packages just contain distribution-specific documentation. The binary drivers for all distributions are contained in the same file. Go to the viaarena CLE266 driver download page and scroll to the bottom. You will see two sections: Full Binary and Lite Binary. As far as I can tell, the only difference between the Full and Lite versions is that the Full version contains the MPEG2 decoding library but the Lite version does not. The video driver packages prepared by VIA include short scripts that will copy the drivers to the appropriate location. But sometimes it might be important for you to know which files go where. For instance, if you download the fedora binary drivers you must manually copy them to their destinations. Here is a list of the important files contained in the packages and where they go. Filename X or Kernel Install path via_v4l_drv.o Kernel /lib/modules/$KERNELVERSION/kernel/drivers/media/video videodev.o Kernel /lib/modules/$KERNELVERSION/kernel/drivers/media/video via_drv.o X /usr/X11R6/lib/modules/drivers via.o Kernel /lib/modules/$KERNELVERSION/kernel/drivers/char/drm via_dri.so X /usr/X11R6/lib/modules/dri libddmpeg.so X /usr/X11R6/lib Filename X or Kernel Install path libGL.so.1.2 X /usr/X11R6/lib libdri.a X /usr/X11R6/lib/modules/extensions libglut.so.3.7.0 X /usr/lib You should read a little bit of the document, but you will get to a sentence that says "This package contains two files ...". No it didn't, it just contained one file. So go back to the viaarena.com linux CLE266 driver page, scroll to the bottom, and download the file named clexf40030-bin.zip. Make a new directory, and unzip and extract all the files: (in the temp directory) bash# cp ../CLEXF40030-bin.zip . bash# cd CLEXF40030-bin bash# tar -xzvf CLEXF40030.tgz bash# tar -xzvf DRI.tgz bash# cd XLEXF40030 bash# less Installation.txt The pdf file will tell you to read the Installation.txt file. Basically, the installation.txt file tells you to run two shell scripts, as follows: bash# ./vinstall To use the vinstall script the /sbin directory must be in the path. In some distros this may not be true. You can add /sbin to the path using this command: bash# export PATH=$PATH:/sbin Also, the vinstall script expects the kernel version which came on the CD-ROM. If your distro includes a tool, like Red Hat Network, which updated your kernel to a new release, then the vinstall script will fail. Downgrading a kernel package can be tricky. You might have to reinstall from CD. Once you run the vinstall script it will ask which CPU you use - the M10k (Nehemiah) uses the C3-2 CPU, all others use the C3. Then change to the DRI directory and install the DRI libraries bash# cd ../DRI bash# ./minstall Finally, you should edit the /etc/X11/XF86Config file. Here is an example Device section: Section "Device" Identifier "VIA cle266" Driver "via" VendorName "Via" BoardName "cle266" VideoRam 32768 Option "ActiveDevice" "CRT,TV" Option "TVType" "NTSC" Option "TVOutput" "S-Video" Option "PciRetry" "true" EndSection You can use whatever identifier string you want, as long as you use the same string later in the Screen section. Notice that the Driver is "via" - that is important. The VendorName and BoardName properties are purely informational. In theory, the VideoRam property should not be required - X should auto-detect the BIOS value. But sometimes the auto-detection doesn't work, so you should include the command. And be sure to check the BIOS Video RAM value! It should be set to 32768. X should auto-detect whether the TV and/or CRT are working but sometimes the auto-detection doesn't work. And a user has reported that the active device property might be non-volatile. So it is best to explicitly define the ActiveDevice property. The via driver supports four devices: CRT, TV, LCD, and DFP. If you use LDC or DFP then you must read the Installation.txt file included in the CLEXF driver package. The next two options are only required if you use a TV set with your EPIA board. "TVType" option may be either "NTSC" or "PAL". The "TVOutput" option may be "Composite" "S-Video", "RGB", or "YCbCr". The PciRetry value is supposed to prevent some audio problems. By default the CLE266 supports common VESA modes. It also has some "non-standard" modes. These unusual modes are optional - if you really want to use them then add these lines to the "Monitor" section of your /etc/X11/XF86Config file: #Refresh Rate 60Hz ModeLine "720x480" 26.7 720 736 808 896 480 481 484 497 ModeLine "720x576" 32.7 720 744 816 912 576 577 580 597 ModeLine "848x480" 31.5 848 864 952 1056 480 481 484 497 ModeLine "856x480" 31.7 856 872 960 1064 480 481 484 497 ModeLine "1024x512" 41.3 1024 1056 1160 1296 512 513 516 531 ModeLine "1280x768" 80.1 1280 1344 1480 1680 768 769 772 795 ModeLine "1440x1050" 126.2 1440 1536 1688 1936 1050 1051 1054 1087 #Refresh Rate 75Hz ModeLine "720x480" 34.9 720 752 824 928 480 481 484 502 ModeLine "720x576" 42.6 720 760 832 944 576 577 580 602 ModeLine "848x480" 41.0 848 880 968 1088 480 481 484 502 ModeLine "856x480" 41.3 856 888 976 1096 480 481 484 502 ModeLine "1024x512" 53.3 1024 1072 1176 1328 512 513 516 535 ModeLine "1280x768" 103.0 1280 1360 1496 1712 768 769 772 802 ModeLine "1440x1050" 160.0 1440 1536 1696 1952 1050 1051 1054 1096 #Refresh Rate 85Hz ModeLine "1280x768" 118.5 1280 1368 1504 1728 768 769 772 807 ModeLine "1440x1050" 184.5 1440 1544 1704 1968 1050 1051 1054 1103 ModeLine "848x480" 47.4 848 888 976 1104 480 481 484 505 If you want to use your monitor's DPMS features, make sure that you have added the line Option "dpms" To the "Monitor" section. Then create a new "ServerFlags" section, like this: Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "5" Option "SuspendTime" "0" Option "OffTime" "15" EndSection Finally, your screen section should look something like this (of course, Monitor will be your monitor Identifier, and the modes might be different): Section "Screen" Identifier "Screen0" Device "VIA cle266" # Device "VESA driver (generic)" Monitor "ViewSonic PS790" DefaultDepth 16 SubSection "Display" Depth 24 Modes "1280x1024" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection Notice that I have commented out the VESA driver. You can keep the old VESA device section if you want, just comment out the line in the Screen section. You never know, you might want to use the VESA driver some day. To use DRI you must load the dri and glx modules, so your Modules section must include the Load "dri" and Load "glx" commands. And you should include a DRI section, as shown below. Section "Module" Load "dbe" Load "extmod" Load "fbdevhw" Load "dri" Load "glx" Load "record" Load "freetype" Load "type1" EndSection Section "DRI" Mode 0666 EndSection The vinstall script will add some lines to /etc/rc.d/rc.local. These lines should load the agpgart, via and via_v4l_drv kernel modules when you boot your computer. But sometimes it doesn't work right. If you can use DRI in superuser (i.e. root) mode but not as user, then you have a module loading problem. You can try loading the modules manually with these commands: bash# /sbin/modprobe agpgart agp_try_unsupported=1 bash# /sbin/modprobe via_v4l_drv bash# /sbin/modprobe via It might also help to add this line to your /etc/modules.conf file: options agpgart agp_try_unsupported=1 If the binary XFree86 drivers do not work for you then you might have to use the source drivers. See the Building XFree86 from Source section for more details. Frame Buffer There are two frame buffer drivers that work with the EPIA boards: the VESA frame buffer and VIA's CLE266 frame buffer. In addition, the DirectFB Project supports CLE266 hardware acceleration. Remember that the frame buffer drivers are intended for use with the console. If you boot in graphical login mode then you should open an xterm, switch to superuser, and execute the telinit 3 command to shut down X and switch to console mode. VESA Frame Buffer The VESA frame buffer works well with the CLE266 graphics adapter. You can start the workstation in frame buffer mode by booting the linux kernel with the vga=mode_number option. The linux mode numbers are described in the linux kernel source at Documentation/fb/vesafb.txt and are shown in the following table. Notice that the frame buffer numbers are given in hexadecimal notation, so the 0x is important (e.g. vga=0x318). You can use the decimal equivalents, if you wish (e.g. vga=792). Linux Frame Buffer Mode Numbers Color Depth 640x480 800x600 1024x768 1280x1024 8 bpp 0x301 0x303 0x305 0x307 15 bpp 0x310 0x313 0x316 0x319 16 bpp 0x311 0x314 0x317 0x31A 24 bpp 0x312 0x315 0x318 0x31B
Once the frame buffer is running on the console you can start xfree86 using the fbdev X server - but it doesn't make much sense. In most cases the xfree86 VESA server will work faster and will allow screen size changing. The fbdev server is usually slower and you may only use the screen size of the VESA console frame buffer. The VESA frame buffer driver provides a large console (128 columns and 48 lines of text at 1024x768, more at 1280x1024). But the VESA driver has some limitations - namely, you cannot change modes and cle266 specific graphics functions are unsupported. VIA CLE266 Frame Buffer VIA has provided a CLE266 frame buffer driver in source code format. In order to compile and install the driver you must have a recent development environment (gcc >= 2.96) and the kernel headers installed. First, download the source code package from VIA Arena. Extract and unzip the package, then build and install the driver. Before inserting the viafb module you must insert the fbgen module (or you can use the modprobe viafb command). You can confirm that the viafb module is running using the fbset -i command. Then you can change the frame buffer mode using the fbset command. Here is an example of the commands used and typical output: bash# make cc -D__KERNEL__ -DMODULE -O2 -DDEBUG=0 -I/usr/src/linux-2.4/include \ -include /usr/src/linux-2.4/include/linux/modversions.h -c \ -o via_fbobj.o via_fbobj.c cc -D__KERNEL__ -DMODULE -O2 -DDEBUG=0 -I/usr/src/linux-2.4/include \ -include /usr/src/linux-2.4/include/linux/modversions.h -c -o via_i2c.o via_i2c.c ld -r via_fbobj.o via_i2c.o -o viafb.o bash# make install `viafb.o' -> `/lib/modules/2.4.18-14/kernel/drivers/video/viafb.o' bash# modprobe viafb viafb: VIA CLE266 framebuffer 0.8 initializing viafb: framebuffer size = 32 Mb viafb: mode=640 bpp=8 refresh=255 TVon=0 TVtype=1 Console: switching to colour frame buffer device 80x30 viafb: fb0: Via frame buffer device 640x480-8bpp bash# fbset -i mode "640x480-73" # D: 30.720 MHz, H: 36.923 kHz, V: 73.260 Hz geometry 640 480 640 480 8 timings 32552 80 32 16 4 80 4 rgba 6/0,6/0,6/0,0/0 endmode Frame buffer device information: Name : Via Address : 0xe0000000 Size : 33554432 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 0 YPanStep : 1 YWrapStep : 0 LineLength : 640 Accelerator : No bash# fbset "1024x768-75" bash# fbset -depth 24 Notice that the frame buffer mode name is composed of the horizontal resolution, vertical resolution, and refresh rate. The /etc/fb.modes file contains the list of valid frame buffer modes. Of course, your monitor must have high enough bandwidth to support the mode - don't try 1280x1024-74 on a 800x600 monitor. The bandwidth You can change color depths using the fbset -depth number command, where number is 8, 16 ,24 or 32. The viafb module has eight command-line parameters: mode, bpp, refresh, noaccel, TVon, TVtype, TVoverscan, and memsize. Here is an example of installing the driver with all parameters: bash# modprobe viafb mode=1024x768 bpp=16 refresh=75 noaccel=0 \ TVon=1 TVtype=1 TVoverscan=1 memsize=32 You don't need to specify all these parameters. The default mode is 640x480 and the default depth is 8 bpp. The default refresh rate is 60. The noaccel option turns 2d hardware accleration off - typically you wouldn't use this parameter. In the same way, you typically wouldn't use the memsize parameter - the driver will auto-detect the correct memory size. Be default TVout is disable, so if you want to turn on TVout you must specify TVon=1 and the TVtype (NTSC=1, PAL=2). Note that TV-out supports only a limited number of resolutions: 640x480, 720x480 (NTSC only), 720x576 (PAL only), 800x600, 848x480, and 1024x768. mplayer can use the VIA CLE266 FB driver in console mode. Run mplayer with the -vo fbdev option. Note that the frame buffer color depth must be set to the correct value for whatever media is being displayed. The VIA CLE266 frame buffer can be used with xfree86 - if you are careful. You must set xfree86 to the same resolution and bit depth as the frame buffer. For instance, suppose the frame buffer driver is running at 1024x768 and 16 bpp, as was done using the previous modprobe command. Then here is an appropriate configurations from /etc/XF86Config : Section "Device" Identifier "frame buffer" Driver "fbdev" EndSection Section "Screen" Identifier "Screen0" Device "frame buffer" Monitor "ViewSonic PS790" DefaultDepth 16 SubSection "Display" Depth 16 Modes "1024x768" EndSubSection EndSection The VIA frame buffer driver has a few advantages over the VESA driver: mainly that there are more modes and you can control the refresh rate and bit depth. Also, the VIA driver supports video capture - read the VIA documentation for more info on that feature. The VIA driver also has some drawbacks. Console scrolling is very slow in 24 and 32 bpp. Setting a viafb mode in one virtual terminal wipes out the displays in the other virtual terminals. And often the virtual terminal will lose its display if you use fbset to reduce the video resolution. DirectFB The DirectFB Project supports CLE266. Hardware MPEG2 Decoding Most EPIA models include the CLE266 graphics processor. These boards support Hardware MPEG2 decoding. But the first few EPIA models, for instance, the "EPIA 5000", "EPIA V", use the PLE133 graphics processor. These two models do not support hardware MPEG2 decoding. The CLE266 graphics processor includes some specialized commands to assist in the playback of DVD mpeg2 streams. X does not use these commands. Instead, video applications such as mplayer or xine use the commands, but these applications require a shared library which converts high level language function calls to the functions provided by the hardware. VIA provides this shared library (libddmpeg.so) as a binary file for certain supported distributions. The Unichrome Project provides a similar library as source code. So if you want to use the Hardware MPEG2 Decoding feature, then you must first decide whether you will use the VIA HW-MPEG decoding library or the unichrome library. The obvious question is, "Do I need to use hardware decoding at all?" It depends which CPU you have and what video you want to play. In general, if your CPU speed is less that 900 MHz then you will need HW-MPEG decoding to play DVDs. If your CPU is 900 MHz or faster, the it should be powerful enough to decode the DVD in software (realkiwi suggests xine -Vxv). For instance, the M9000 and M10k have been reported OK with DVDs. But boards slower than the M9000 will probably require libddmpeg.so support. For instance, the M6000 plays a DVD under mplayer without libddmpeg at 100% load, with frame skips and a large A-V differential. However using the viaexp application and the VIA libddmpeg library CPU load is only about 40% and playback is near perfect. Of course, if the video stream is less than DVD quality you may not need libddmpeg. For instance the ME6000 can play vcd and svcd at less than 50% load. And you must also consider any other processes running on the machine. If you have a kernel compile running in the background, obviously fewer resources will be available to video decoding. Fedora Core 3 Unichrome HW Decoding jwilde posted these instructions to the via forums in Jan 2005:
So after looking around a bunch and being confused with what I was finding, I decided to write this little howto about getting HW decode in Xine working on Fedora Core FC3. This was done yesterday. Install FC3. I did a clean install with the original release. up2date everything including the kernel. Install apt Use the FC3 ATrpms.net kickstart configuration for apt wget http://ATrpms.net/RPM-GPG-KEY.atrpms rpm --import RPM-GPG-KEY.atrpms Install the kickstart configs by rpm -i on the i386 links (copy link locaton from the following page and paste after rpm -i): http://www.atrpms.net/dist/fc3/atrpms-kickstart/ Change your /etc/apt/sources.list to use at-bleeding for atrpms. And change ayo.freshrpms.net by adding 'freshrpms' after core and update. apt-get update && dist-upgrade (Side note: at some point I ended up with 2 glibc/glibc-common on my system. To fix this, do rpm -qa glibc or rpm-qa glibc-common and remove the older one (rpm -e). Then reinstall glibc-common by apt-get install --reinstall glibc-common. This will fix a locale error that occurs in yum and perl.) Download and install DRI: bash# cvs -z3 -dserver:anonymous@dri.freedesktop.org:/cvs/dri login #(use Enter for the password) bash# cvs -z3 -dserver:anonymous@dri.freedesktop.org:/cvs/dri co drm bash# cd drm/linux-2.6; make bash# cp via.ko /lib/modules/2.6.8-1.724_FC3/kernel/drivers/char/drm/ (substitute kernel version as appropriate) bash# depmod -ae Install xorg-unichrome: Add the following to your yum.conf (or put it in it's own /etc/yum.repos.d/epia-xorg.repo file: [epia] name=RPMs for Via Epia motherboards - Fedora Core $releasever baseurl=http://washington.kelkoo.net/epia/FC$releasever gpgcheck=0 bash# yum install xorg* If you like, install synaptic, apt-get install synaptic (requires at-bleeding). Install the latest xine-lib and xine-ui (version 1.00 release on Jan 4th or newer which includes all necessary stuff), using synaptic or apt-get. You may need/want to install other video/audio libs but should be easy to figure out. libdvdcss would be an obvious one. Create /etc/X11/XvMCConfig and put one line in it: libviaXvMC.so.1 Reboot Use xine -V xxmc (should only need to do it once with the -V xxmc). You can use -verbose=9 to get a lot of debug output and verify that video_outut_xxmc is using hardware decoding. Also, your /var/log/Xorg.0.log should indicate that via XvMC was initalized and dmesg should indicate that drm was loaded (and should be listed in lsmod drm and via). You should not need to make any chages to modprobe.conf or xorg.conf (You can add Option "EnableAGPDMA" "true" to your xorg.conf via section for improved performance). agpgart and via_agp are not in my /sbin/lsmod output so they must be built in. If you are Digital Coax output from Alsa, make sure you unmute the master mixer, PCM (and set levels appropriately), 'IEC 958 0' must be turned all the way down as well. Save the state using '/usr/sbin/alsactl -f /etc/asound.state store'. I added a 'restore' version to my /etc/rc.d/rc.local as the settings didn't seem to be getting restored properly on reboot. I'll update this if I remember anything else, and add to it once I get around to reinstalling MythTV, mplayer-unichrome, ivtv and 3D. The reason I did the upgrade (from RH9) in the first place was because I was using an old version of Xine that didn't like newer xvids and divxs. And I was usng Ivor's(?) original video_out_viahw proof of concept from a year ago. Hope this helps someone out. Jamison
MPlayer MPlayer uses the XFree86 accelerated driver, but not the specialized mpeg decoding commands. Mplayer can play vcd files but has problems with dvds. I tested mplayer with the Star Trek II DVD on an ME6000. It ran ok for the credits, but when the movies started CPU utilization jumped to 83% and a audio/video lag started to grow. The lag grew to about 6 seconds in the first minute of the movie. mplayer works reliably with DVDs on the M10k. Note that mplayer will run better if you run it as root and set the nice level very low. Also, if you install the frame buffer driver then you can run mplayer from a console, avoiding X overhead, i.e. bash# insmod fbgen bash# nice -19 mplayer -vo fbdev dvd:// You can define commonly used mplayer options in your ~/.mplayer/config file, for instance: bash$ cat .mplayer/config # Write your default config options here! vo=xv fs=1 zoom=1 framedrop=1 cache=8192 # this option yields a smoother playback! # I include options for slang and alang, but those won't increase the # performance much. I do almost always use subtitles. viaexp The CLE266 chip includes mpeg hardware acceleration to play DVDs. VIA partnered with Xine to bring these special functions into the Xine video player. However these improvements are only available in a special version of xine called viaexp. First, download the most recent version from the viaexp website. I downloaded version 0.99-1.2.1. The project files page provides a source tarball, a Red Hat source rpm and rh8 and rh9 binary rpms tarballs. This section will describe how to install from the source tarball. If you decide to use the rpm packages, read the README file includes in the tarball. The most recent version of the rpms are available at http://www.bglug.ca/epia. Download and extract the source tarball. Read the readme.txt file and follow the instructions carefully. It will take 30 to 60 minutes to build and install viaexp. Make special note of the following: insert a dvd as root, # viaexp dvdnav:// When the interface comes up click on the "Nav" button WAIT!!!!!!! Wait until it gets all the keys Then when the drive has calmed down a little click on the "play" arrow Note that the viaexp application must be run as root and it only works for dvds. Especially note that you must use the NAV button to watch DVDs. The DVD button does not work. By default xine installs to /usr/local. So the libraries are in /usr/local/lib. You must add /usr/local/lib to /etc/ld.so.conf. If they don't already exist, you must create a symbolic link from /dev/rdvd to /dev/raw/raw1 # ln -s /dev/raw/raw1 /dev/rdvd I am a little bit annoyed that VIA included buttons that don't work on their Xine GUI. Fortunately, these buttons can be safely removed by deleting their plug-ins. Here's how to do it: bash# cd /usr/local/lib/xine/plugins bash# rm -f *inp_dvd.so *inp_dvd.la *inp_cda* *inp_file* *inp_vcd* Hauppage PVR 250 This section is contributed by R.V. Paasen. To use a PVR-250 in Linux, you you'll need to have installed the kernel 2.4.23-pre7-epia1 and the latest alpha version of ivtv: download http://ivtv.sf.net/decoder-alpha.tar.gz gunzip the ivtv package read the docs in the package about installing firmware, you need the latest from hauppage.com: pvr250_17_21226.exe. There is a perl script in the utils directory to extract the firmware from the windows drivers. go into the driver dir copy the videodev2.h from ../utils make and make install edit /etc/modules.conf and add: alias char-major-81 videodev alias char-major-81-0 via_v4l_drv alias char-major-81-1 via_v4l_drv alias char-major-81-2 via_v4l_drv alias char-major-81-3 ivtv options ivtv debug=1 mpg_buffers=90 options tuner type=5 @@ read docs for info on tuners and tv standards@@ options msp3400 once=1 simple=1 add below ivtv msp3400 saa7115 tuner options agpgart agp_try_unsupported=1 modprobe via_v4l_drv (before ivtv!), /dev/video0,1&2 are used now modprobe ivtv, /dev/video3 is used now, see also dmesg for messages go into utils dir and make (if make fails, read docs about compiling videodev2.h in user space) use utilities to setup the pvr-250 (beware, test_ioctl takes 1 argument at the time). I use: ./test_ioctl -d /dev/video3 -u 0xff ./test_ioctl -d /dev/video3 -p 4 ./test_ioctl -d /dev/video3 -f width=720,height=576 ./test_ioctl -d /dev/video3 -r tuner=0,freq=$1 ./test_ioctl -d /dev/video3 -c \ aspect=2,\ audio=0xE9,\ bframes=3,\ bitrate_mode=0,\ bitrate=9000000,\ bitrate_peak=16000000,\ dnr_mode=3,\ dnr_spatial=0,\ dnr_temporal=0,\ dnr_type=0,\ framerate=1,\ framespergop=12,\ gop_closure=1,\ pulldown=0,\ stream_type=10 The -u and -p parameters are country-specific, read the docs about it. cat /dev/video3 > my-first-record To enable timeshifting in Xine, you should compile the latest Xine version (xine-lib1_rc1 and xine-ui 0.9.22) yourself. In inputs/input_pvr.c, change the hard-coded "/dev/video0" to "/dev/video3" because via_v4l_drv takes 0,1&;2. xine -V xv --stdctl pvr:///tmp/livepause You should now be able to play full-screen, 9-16 Mbit PAL streams at 50% CPU usage (measured on Gentoo, kernel 2.4.23-pre7-epia1, XFree 4.3.99-13, no EPIA mpeg decoding). On this machine, mplayer taker 80% CPU, xine performs much better. Marc de Courville has some PVR250 instructions at his wiki. MythTV MythTV is a PVR project which supports the Hauppage cards and the EPIA hardware MPEG acceleration. I don't know much about MythTV yet, so I'll just point you to this howto written by Torsten Schenkel, which explains how to install MythTV on a debian EPIA board with PVR350 and also Marc de Courville has excellent instructions at his wiki. Turn on DMA To achieve maximum performance you may have to manually activate DMA for you hard drive and/or DVD drive. First you must have the VIA82CXXX IDE chipset support built into your kernel. This should be true of all recent distros, but if you built your own kernel make sure that this line: CONFIG_BLK_DEV_VIA82CXXX=y appears in your .config file. Next, some ide-cd drivers require the dma=1 option when they are loaded. So you might need to add this line to /etc/modules.conf: options ide-cd dma=1 This command passes the "dma=1" option to the ide-cd driver module when the module loads. I don't know exactly what this option does, but I know that I must use "dma=1" if I want to use DMA on my DVD drive. After editing modules.conf you must reload the ide-cd module. The easiest way to reload that module is to reboot your machine. Now that you have reloaded the module with the dma=1 option you can activate dma. This command instructs the drive to use DMA: bash# /sbin/hdparm -d1 /dev/dvd This command instructs the drive to use DMA mode 2: bash# /sbin/hdparm -d1 -X34 /dev/dvd This command instructs the drive to use UDMA: bash# /sbin/hdparm -d1 -X66 /dev/dvd You can also restrict the DVD player's speed. Strangely, some DVDs players work better with movies when their speed has been reduced. You might want to experiment with this variable. For instance, to turn UDMA on and set speed to four times, I use this command: bash# /sbin/hdparm -d1 -X66 -E4 /dev/dvd And now the warning: the 8235 (and presumably the 8231) may lock up when more than one DMA burst is active. For instance, if you play a DVD and copy large amounts of data from the network at the same time then the EPIA board may lock up. The Hog reported this problem and I have experienced it also. Fortunately, VIA has released a patch which might fix the DMA problem. TV Out TV out has always worked well for me without tweaking. I just connector the TV and the board automatically detects the TV and outputs a signal. If the auto-detection doesn't work, then configure the BIOS settings. You may also need to tweak the XF86Config file. See the documents distributed from viarena.com for all the details, but these are some of the important lines which might appear in your Device section: Option "ActiveDevice" "CRT,TV" Option "TVType" "NTSC" Option "TVOutput" "S-Video" One EPIA user has reported a weak TV signal. You should test your board with a short S-Video cable, no more than one meter long. Hardware Sensors Kernel 2.4 Many distros include the i2c and lm_sensors packages, but as of this writing (Sep 2003) these distros don't support the vt1211. So you must compile and install it yourself. Problems have been reported using i2c and lm_sensors with kernel version 2.4.22. These instructions do not apply to kernel 2.4.22. Before building anything you must remove any pre-existing lm_sensors libraries and utilities. On Red Hat systems you can remove these binaries using this command: bash# rpm -e --nodeps lm_sensors Next we need to create a symlink in /usr/src. The i2c and lm_sensors packages expect to find the source at /usr/src/linux, so if it doesn't already exist then create the link: bash# cd /usr/src bash# ln -s linux-2.4.18-14 linux If you haven't done so already, fix the shared library list. i2c and lm_sensors require that the linux source be configured. If you built your kernel from source then it will already be done. If you installed your source from a package, such as the red hat kernel-source package, then the source has not be configured and you must configure and the source and make the dependency files. But you don't need to compile the source. Here is what you have to do: bash# cd /usr/src/linux bash# cp /boot/config-2.4.18-14 .config bash# make menuconfig (exit, save configuration) bash# make dep Now download the i2c-2.7.0 and lm_sensors-2.7.0 tarballs. The following commands will extract, make, and install the i2c package. bash# tar -xzvf i2c-2.7.0.tar.gz bash# cd i2c-2.7.0 bash# make all bash# make install bash# cd kernel bash# rm -f /lib/modules/2.4.18-14/kernel/drivers/i2c/* bash# cp *.o /lib/modules/2.4.18-14/kernel/drivers/i2c/ Those last two commands replace the redhat i2c kernel modules with your new modules. Do the same thing for lm_sensors: bash# tar -xzvf lm_sensors-2.7.0.tar.gz bash# cd lm_sensors-2.7.0 bash# make all bash# make install bash# cd kernel/busses bash# cp *.o /lib/modules/2.4.18-14/kernel/drivers/i2c/ bash# cd ../chips bash# rm -f /lib/modules/2.4.18-14/kernel/drivers/sensors/* bash# cp *.o /lib/modules/2.4.18-14/kernel/drivers/sensors/ Before we go any farther, add the following line to your /etc/modules.conf file: alias char-major-89 i2c-dev Now you have built the modules and tools and installed them in the filesystem. But you have to insert the modules in order to use them. The big question: which modules do you use? As far as I can tell, all the VIA mini-itx boards use the i2c-core, i2c-isa and i2c-proc modules: bash# depmod -a bash# modprobe i2c-core bash# modprobe i2c-isa bash# modprobe i2c-proc These modules enable communication on the i2c bus. Now you have to insert the module for the sensor chip. There are two modules: vt8231 and vt1211. All VIA mini-itx boards use the vt1211 sensor. The difference is that EPIA boards have the 1211 chip built into the 8231, while the M series boards have a separate 1211 chip. Look at your board: if you see a 1211 chip, then use the vt1211 module. If you don't them use the vt8231 module: bash# modprobe vt1211 -- or -- bash# modprobe vt8231 You can read the sensors directly from the /proc/sys/dev/sensors/vt1211-isa-6000 directory: # cat /proc/sys/dev/sensors/vt1211-isa-6000/temp1 255.0 0.0 98.0 You can obtain a more user-friendly readout using the sensors command: bash# sensors vt1211-isa-6000 Adapter: ISA adapter Algorithm: ISA algorithm VCore1: +1.98 V (min = +0.00 V, max = +0.00 V) ALARM +5V: +4.78 V (min = +4.73 V, max = +5.24 V) +12V: +12.08 V (min = +10.77 V, max = +13.15 V) +3.3V: +3.35 V (min = +3.13 V, max = +3.45 V) fan1: 0 RPM (min = 3006 RPM, div = 2) ALARM fan2: 0 RPM (min = 3006 RPM, div = 2) MB1 Temp: +190.0C (limit = +60C, hysteresis = +55C) ALARM Proc Temp: +46.5C (limit = +65C, hysteresis = +60C) MB2 Temp: +0.0C (limit = +0C, hysteresis = +0C) ALARM vid: +0.00 V You might notice that MB1 temp is freakishly high. This is common. The proc temperature seems reliable. MB2 temp is not implemented. You need to edit the vt1211 section of /etc/sensors.conf like this: # Sensors configuration file used by 'libsensors' chip "vt1211-*" "vt8231-*" # set uch1-2 to temp mode, uch3-5 to voltage mode # set config 12 ignore in0 ignore in1 ignore temp2 ignore temp4 ignore temp5 ignore temp6 ignore temp7 label in2 "VCore1" label in3 "+5V" label in4 "+12V" label in5 "+3.3V" label temp3 "CPU Temp" # # All voltage calculations have the form # ((@ * 100) - 3) / (K * 95.8), (@ * K * 0.958) + .03 # where K = R2 / (R1 + R2). # Use the following K values based on input voltage. # This of course assumes the mobo has the resistors # recommended by Via in the datasheet. # Voltage K # VCore 1.0 # 2.5 0.8333 # 3.3 (in5 internal) 0.6296 # 3.5 (3.3V ext.) 0.5952 # 5.0 0.4167 # 12.0 0.1754 # compute in2 ((@ * 100) - 3) / (0.5952 * 95.8), (@ * 0.5952 * 0.958) + .03 compute in3 ((@ * 100) - 3) / (0.4167 * 95.8), (@ * 0.4167 * 0.958) + .03 compute in4 ((@ * 100) - 3) / (0.1754 * 95.8), (@ * 0.1754 * 0.958) + .03 compute in5 ((@ * 100) - 3) / (0.6296 * 95.8), (@ * 0.6296 * 0.958) + .03 set vrm 9.1 set in2_min vid * 0.97 set in2_max vid * 1.03 set in3_min 5.0 * 0.95 set in3_max 5.0 * 1.05 set in4_min 12.0 * 0.90 set in4_max 12.0 * 1.10 set in5_min 3.3 * 0.95 set in5_max 3.3 * 1.05 compute temp3 (@*@*0.0046)-(@*0.088)-0.748, (@*0.9686)+65 set temp3_hyst 60 set temp3_over 65 set fan1_min 3000 set fan2_min 3000 You can put the modprobe commands in your /etc/rc.d/rc.local file to ensure that the sensors drivers are loaded when you start your machine. Or on some distros you can edit the sysconfig files. Create a /etc/sysconfig/lm_sensors file containing the following: MODULE_0=i2c-core MODULE_1=i2c-proc MODULE_3=i2c-isa MODULE_4=vt1211 Or substitute vt8231 if you have an EPIA board. Now copy the lm_sensors-2.7.0/prog/init/lm_sensors.init file to /etc/rc.d/init.d/lm_sensors Linux 2.6 As of December 2004, the vt1211 sensor chip has not been ported to the linux 2.6 kernel. However Lars Ekman has ported the driver. You can download the code and a new sensors.conf file from his vt1211 module for 2.6 kernel page. The page includes installation instructions. Notes When you build i2c and lm_sensors the compiler will look at /lib/modules/running_kernel_version/build to find the source tree for the target kernel. So you need to do two things: first, build i2c and lm_sensors while running the target kernel. Second, make sure the build symlink points to the correct directory for your source tree. Hard Drive Temperature Sensor This isn't really an EPIA issue - it's about hard drives. But many EPIA boards are used in silent PCs. Because these silent PCs have no fans, it can get pretty hot inside the case and the hard drive can get very hot. The manufacturer's datasheet specifies the maximum operating temperature of the hard drive. You should never exceed that temperature - in fact, you should keep well under the maximum temperature. But how do you know how hot your hard drive is? You need a hard drive temperature sensor. Many recent hard drives include built-in temperature sensors which can be read using the S.M.A.R.T. data facility. The hddtemp utility can read the SMART temperature information for supported hard drives. To install the hddtemp utility, download both the hddtemp utility and the database file.. Then install as follows: bash$ tar -xjf hddtemp-0.3-beta8.tar.bz2 bash$ cd hddtemp-0.3-beta8 bash$ ./configure bash$ make bash$ su Password: bash# make install bash# mv hddtemp.db /usr/share/misc bash# /usr/local/sbin/hddtemp /dev/hdc /dev/hdc: ST340014A: 52°C hddtemp install to /usr/local/sbin, which might not be in the path, so you may need to specify the full filename to run the utility, as shown above. You could also read the S.M.A.R.T. temperature information using the smartmontools utility from sourceforge. Here is a useful script - run it and every 60 seconds it will print out a time index, the CPU temperature, and the HD temperature. Pipe it to a file and you can import it to a spreadsheet in comma delimited format. #!/bin/bash t=0 echo Time , CPU Temp , HD Temp while [ "true" = "true" ] ; do cputemp=`sensors | grep Proc | sed 's/.*: +\(.\{2,10\}\)C.*/\1/'` hdtemp=`/usr/local/sbin/hddtemp /dev/hdc | sed 's/.*: \(.\{2,10\}\)°.*/\1/'` echo $t","$cputemp","$hdtemp sleep 60 t=`expr $t + 1` done I2C Connector This information was posted to VIA Arena Linux Forum by Helmut Wollmersdorfer. The VIA EPIA ME6000 has a I2C Connector on the motherboard. This is what the User Manual says about the connector: EPIA M I2C Connector Pin-out Pin Signal 1 +3.3 V 2 +3.3 V 3 EL-ON 4 SMBCK 5 SMBDT 6 GND
Maybe pin 3 is for controlling electro luminescent displays, which are back light foils for LCD. So maybe there is an undocumented feature of EPIA boards, which is able to control LCD displays _and_ the backlight over I2C. My trial was to connect a Dallas/Maxim DS1621 temperature sensor. The pins of the DS1621 are as follows: DS1621 Pins Pin Signal Description 1 SDA 2-Wire serial data input/output 2 SCL 2 wire serial clock 3 Tout Thermostat Output Signal 4 GND Ground 5 A2 Chip Address Input 6 A1 Chip Address Input 7 A0 Chip Address Input 8 Vdd Power Supply Voltage
Now connect the DS1621 to the I2C connector according to the chart below. Note that the address pins A0-A2 give zero-bits if connected to GND, and one-bits if connected to Vdd. This feature is for specifying an address of the sensor if more than one is connected to the bus. EPIA I2C/DS1621 Cross connect I2C Connector DS1621 Pin Label Pin Label 1 +3.3 V 8 Vdd 4 SMBCK 2 SCL 5 SMBDT 1 SDA 6 GND 4 GND 5 A2 6 A1 7 A0
Next install lm-sensors, on my Debian Sarge 2.6.8-1-386 I did it with bash# apt-get install lm-sensors bash# sensors -v sensors version 2.8.7 with libsensors version 2.8.7 Now the relevant modules need to inserted (via insmod or modprob), here is the relevant part of bash# lsmod Module Size Used by ds1621 8452 0 i2c_isa 2304 0 vt1211 15876 0 i2c_sensor 2944 2 ds1621,vt1211 i2c_viapro 6924 0 i2c_dev 9984 0 i2c_core 22416 6 ds1621,i2c_isa,vt1211,i2c_sensor,i2c_viapro,i2c_dev Sensors-detect did not detect the DS1621, but it works now: bash# sensors ds1621-i2c-0-48 Adapter: SMBus Via Pro adapter at 0500 temp: +26.00°C (low = +15.0°C, high = +10.0°C) ALARM (LOW,HIGH) CPU Frequency Control The VIA CPUs include the ability to change CPU clock speed during operation. This feature used to be called longhaul but recently Centaur has changed the name to Powersaver. CPU clock speed is determined by two settings: the front side bus (FSB) clock speed and the CPU multiplier. For instance, the EPIA ME6000 includes a 600MHz Eden ESP CPU which has an FSB of 133 MHz and a CPU mult of 4.5. 133 x 4.5 = 598.5, and the manufacturers always round up to 600. The minimum and maximum clock multipliers are different for each CPU core. Between the minimum and maximum values, the clock multipliers increase by increments of .5. The table below summarizes the CPU clock speeds for each CPU core. VIA CPU Core Clock Speeds Core FSB Min CPU Mult Max CPU Mult Samuel 66/100/133 3 8 Samuel 2 66/100/133 fixed 3 12 Ezra 66/100/133 fixed 3 12 Ezra T 66/100/133 3 12 Nehemiah 66(?)/100/133 5 16
The maximum values shown in the preceding table represent the maximum values supported by the longhaul/powersaver feature. In fact, each CPU has a factory default clock multiplier specified in its MSR_EBL_CR_POWERON register. This factory default multiplier should be considered the maximum clock multiplier for the CPU. In fact, some VIA CPUs may be overclocked by setting the longhaul clock multiplier higher than the factory default. Overclocking your CPU is usually a bad idea because the extra heat generated by the higher clock might damage or destroy the CPU. So if you can't make the CPU go faster, why bother? Well, lower clock speed means less power dissipation, which means cooler and quieter. For instance, many people leave their computers on all the time. Consider a screensaver that will automatically reduce the CPU speed when the computer is not being used. It also means that batteries will last longer. Consider a daemon running in the background that saves battery life by automatically reducing the clock speed when the CPU is running at less than full load. That's the idea. But how do you actually use the feature? You need two tools to control the CPU frequency: a longhaul driver and a governor. The longhaul driver directly accesses the CPU, changing the clock speed. The governor monitors some system parameter (for instance cpu usage) and instructs the kernel module to increase or decrease the CPU speed when the system parameter changes. Linux 2.6 CPU Frequency Control The linux 2.6 kernel includes a CPU Frequency Control system called cpufreq. cpufreq includes a longhaul driver. The cpufreq longhaul driver supports Samuel, Samuel 2, Ezra and Ezra-T microprocessors, but not Nehemiah processors. If your EPIA runs at 1 GHz or more, odds are it has a Nehemiah processor. In order to implement the powersaver function on the Nehemiah under linux you will need to patch the kernel. Here are two methods, first the newer and better method, and second the older buggy method. Ken Staton has fixed the longhaul driver and submitted a patch to the cpufreq tree. Unfortunately it might take a while for the patch to reach the official linux kernel. In the meantime, we will have to patch the kernel and recompile. Here is the patch. This patch should apply cleanly to the 2.6.10 and 2.6.11 kernels, and maybe even 2.4.27. Here is the older, buggy method. First read the Building Linux 2.6-epia section and download and patch the source tree. But after you apply the 2.6.6-epia1 patch download the 2.6.6-epia1-longhaul patch and apply it also. bash# gzip -dc ../patch-2.6.6-epia1-longhaul.gz | patch -p1 Now you can go continue with the Building Linux 2.6-epia instructions, but when you configure the kernel be sure to enable frequency scaling. You will find it in the Power Management section under CPU Frequency Scaling. Enable CPU Frequency Scaling. Go into the Default CPUFreq Governor menu and select the userspace governor as the default. Go back to the previous menu and build the performance and powersave governors as modules. Build the CPU Frequency Table Helpers and build the VIA Cyrix III Longhaul support as a module. Once the kernel is built and installed you must load the module into the kernel: bash# modprobe longhaul Userspace Governor The userspace governor gives you direct control of the cpu speed using simple cat and echo commands. If you didn't set the userspace governor as the default governor then you must load the module. The 2.6 CPU Frequency Scaling code uses the new sysfs interface, so you must create a /sys directory and mount the sysfs filesystem there. Now change into the cpufreq directory and you can control the cpu speed as illustrated below: bash# modprobe userspace bash# mount -t sysfs sysfs /sys bash# cd /sys/devices/system/cpu/cpu0/cpufreq bash# cat scaling_governor userspace bash# cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 1 cpu MHz : 999.914 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr mtrr pge cmov mmx fxsr sse rng bogomips : 1974.27 bash# cat scaling_available_frequencies 731000 798000 931000 665000 864000 997000 bash# echo 731000 > scaling_setspeed bash# cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 1 cpu MHz : 733.136 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr mtrr pge cmov mmx fxsr sse rng bogomips : 1447.53 Hardware Random Number Generation The Nehemiah CPU includes hardware random number generation. This feature is very useful for security purposes. It is well supported under linux but requires a kernel compile - which means that you won't be able to use the pre-compiled accelerated graphics drivers. For more information about the Nehemiah's random number generator you should read the article at peertech.org. Cardbus/PCMCIA & CF The MII boards feature a cardbus/PCMCIA slot and a CompactFlash slot. (The CF slot is connected to the cardbus controller.) These resources are supported by the linux PCMCIA system, which should be installed with any major linux distribution, such as Red Hat or SuSe. If your distribution does not automatically detect and load the drivers you can do it manually: bash# modprobe yenta_socket bash# modprobe ide-cs bash# cardmgr Unfortunately the EPIA MII cannot boot from CompactFlash - it is connected to the cardbus controller and there is not PCMCIA boot option in the BIOS. If you want to boot from flash you must buy and install an IDE/CF converter and install the compactflash card as an IDE device. Consumer Infra Red Header (CIR) Alastair M. Robinson has posted a complete description of how to interface the CIR header on the EPIA-M model board. Just in case Alastair's page goes down, I have made local copies here and here. Building linux and XFree86 from Source Building Linux 2.6.6-epia1 The 2.6.6 kernel works well on the EPIA boards using Tony Murray's patch. First, start with a recent distribution - I used Knoppix 3.4. Download the 2.6.6 kernel from kernel.org. Next, download the 2.6.6-epia1 kernel patch. Next, extract and patch the kernel: bash$ tar -xjf linux-2.6.6.tar.bz2 bash$ mv linux-2.6.6 linux-2.6.6-epia1 bash$ cd linux-2.6.6-epia1 bash$ bz2cat ../patch-2.6.6-epia1.bz | patch -p1 Next we have to configure the kernel. If you want, you can download this stripped down config file. Copy it to linux-2.6.6-epia1/.config and execute the make oldconfig. The example .config file is designed for a Nehemiah processor. If you are using an earlier processor then you must change the CPU type to C3. Also you might want to configure the CPU Frequency Scaling feature. If you want to change the configuration, then use the make menuconfig or make xconfig commands. Then save the new configuration and build the kernel. bash$ make oldconfig ... deletia ... bash$ make bash$ su Password: bash# make modules_install bash# make install You should know how to modify your boot configuration to boot from the new kernel. The sample config file builds a kernel with console framebuffer support, so you can boot with framebuffer using vga=791 or whatever. I haven't had time to look at the new modprobe.conf system, so I load the modules using an init script, as shown below. #!/bin/bash # Script to load the modules for the 2.6.2 kernel KERNEL_VERSION=`uname -r` echo $KERNEL_VERSION if [ "$KERNEL_VERSION" = "2.6.6-epia" ]; then /sbin/modprobe via-rhine /sbin/modprobe uhci-hcd /sbin/modprobe via82cxxx_audio /sbin/modprobe usbhid /sbin/modprobe agpgart /sbin/modprobe via_agp /sbin/modprobe via_v4l_drv /sbin/modprobe via /etc/init.d/networking restart fi Also, you may need to edit your /etc/modules.conf file. The usb modules have changed names, so you should have something like this: alias usb-controller uhci-hcd alias usb-controller1 uhci-hcd Building Linux 2.4-epia DANGER. This section describes builds using test kernels and experimental patches. You should never use a test kernel on a production system. You could lose all the information on your harddrive. Backup all important data before building and running a new EPIA kernel. I do not recommend using the procedures described in this section - I provide them for information purposes only. If you decide to try the techniques described here then you are responsible for any damage to your system. You should also consider what you expect to achieve by building from source. At this time mpeg2 hardware acceleration doesn't work with kernels built from source. So fewer features will be available with a kernel built from source. You should ask yourself "Why do I want to build a kernel?" And if you have a good answer, then read on. First, we must decide which kernel version to use. We need a version that supports CLE266 DRM. Well, none of the stable kernels support CLE266 DRM. Linux 2.6.0-test5 doesn't even support CLE266. So we must use either a 2.4.22-ac (Alan Cox) kernel or a 2.4.23-pre kernel and add patches for additional features. But some of the ac kernels have broken via-rhine drivers. So we will use the patchset that Tony Murray put together (see the viaarena discussion for more details. The patchset adds the following features to the 2.4.23-pre4 test kernel: CLE266 AGP support Savage DRM CLE266 DRM CLE266 V4L Intel/AMD/VIA HW_RANDOM - http://sourceforge.net/projects/gkernel/ CPUFREQ (Longhaul) BootSplash - http://www.bootsplash.org We need the stable linux 2.4.22 kernel and the 2.4.23-pre4 patch. We also need the 2.4.23-pre4-epia1 patch from Tony Murray's website. Then extract and patch the kernel: bash$ tar -xjf linux-2.4.22.tar.bz2 bash$ zcat patch-2.4.23-pre4.gz | patch -p0 bash$ mv linux-2.4.22 linux-2.4.23-pre4 bash$ zcat patch-2.4.23-pre4-epia1 | patch -p0 bash$ mv linux-2.4.23-pre4 linux-2.4.23-pre4-epia1 Kernel configuration.. You need to configure the kernel. To make it a bit easier, you can download a bare-bones red hat config file. Copy the config file to .config in the linux directory: bash$ cp redhat_config linux-2.4.23-pre4-epia1/.config otherwise use the redhat_config file: bash$ cp redhat_config .config These config files specify a bare-bones EPIA system using a C3 processor. You should have a look at the configuration using make menuconfig. Make sure that the processor is set correctly. If you have a board in your PCI slot you will need to configure the kernel to support the board. When you are satisfied with your kernel save it and do the normal kernel build procedure: bash$ make dep bash$ make bzImage bash$ make modules bash$ su Password: bash# make modules_install bash# make install Make install will build a new initrd and add a new boot entry to /boot/grub/grub.conf. So now reboot your system and remember that this kernel tree is experimental. Did you make those backups? Building XFree86 from Source Read Thomas Hellstr”m's excellent instructions. Frequently Asked Questions How do I add shared library files? Linux makes extensive use of shared library files. These files are typically stored in /lib, but additional libraries might be stored in other directories. The file /etc/ld.so.conf lists the directories that contain shared library files. When you compile and install from source, the install program often copies the new shared library files to /usr/local/lib. However some distributions do not include this directory in /etc/ld.so.conf. So you must add the directory. Just use a text editor and add /usr/local/lib to the end of the file. Save and close the file then use the ldconfig command to register your changes. You do not need to reboot the computer. Is the C3 Pentium compatible? Yes. But Samuel 2, Ezra, Ezra T C3 processors have a problem with the cmpxchg8b (i.e. CMOV) opcode. Nehemiah and Antaur processors are not affected.
The identification issue is that the C3 is identifying itself as 686. According to the Intel IA32 documentation, this is correct: C3 does not implement conditional moves*, and do not pretend to implement conditional moves. The Intel documentation states that you should check before doing conditional moves, and that cmov implementation in the processor is optional. The GNU compiler people have assumed that all 686's implement cmov's, so code compiled for the i686 architecture may not execute on the C3. Code generated by GCC does not check for these optional features as the intel documentation says you should. When downloading binaries for the C3, don't go higher than the i586 level. When building, you may want to target the 586 or even the 486, because of the way the C3 is built internally: It's not an athlon, more like a 486-586 cross.
This opcode problem affects certain distributions, such as Suse 8.2 and the first generation of Red Hat 9 CD-ROMs (download ISOs of red hat should be ok). You should avoid SuSe 8.2 and only use downloaded ISO images of Red Hat Linux. If you compile your own kernel notice that under processor type there are two C3 options. If you select the original C3, then the kernel will compile using option, which avoids the CMOV problem. See the gcc manual for more x86 options. How do I install SuSe 8.2? There are some problems running gcc generated i686 code on the C3 CPU. Most distributions are compiled for i386 or i586, so this isn't a problem, but there appear to be some issues with SuSe 8.2, whose 586 kernel sometimes won't run on the C3 processor. If you have problems with SuSe 8.2, then this procedure might work: 1) put your via harddisk in a supported computer 2) install SuSE on this computer / harddisk combination 3) go to /usr/src/linux and make make cloneconfig 4) make (x)config and change the cpu flag from pentium to 486 5) make dep, make bzImage, make modules, make modules_install 6) Install the new kernel, sometimes you must run mr_initrd 7) make a "test boot" if it works fine change the harddisk EPIA Links Here are some useful links which have been submitted to the HowTo: EPIA 5000 & M10K Answers @ Stargate Courville.org wiki Linitx.org Linitx.com Epiacenter.com mini-itx.com The M10k is too noisy. How can I make it quieter? The EPIA M10000 board uses a Nehemiah 1GHz CPU. The CPU features a small heatsink and a 40mm fan (in my case a BiSonic 4010 fan). Many M10k owners believe that the BiSonic fan is too noisy. There are several ways to reduce the noise from this fan. Which technique you should use depends on your sensitivity to noise, your budget and your abilities. I will start with the easiest methods and progress to the most difficult. Note that some of these methods may be combined. Hush, Tranquil & Scythe Hush Technologies and Tranquil PC silent EPIA M10k based PCs. Hush and Tranquil implement large, external heatsinks to move the heat away from the northbridge and CPU to the outside environment without the use of fans. The result is silent computing. The problem with Hush and Tranquil is that they come with a pre-installed EPIA M10k board, so if you already have an M10k the Hush and Tranquil aren't much help. Scythe USA sells a silent case for the EPIA M series boards. The case is called the e-OTONASHI-1000 and costs about $200US. It uses a specially designed heat pipe to move heat to a large heatsink on the bottom of the case. Fan Undervoltage The BiSonic fan connects to a 12v power socket on the EPIA board. If you reduce the voltage across the fan the fan runs slower and makes less noise. However if you reduce the voltage too much the fan won't move at all. Posts on viaarena forums suggest that the voltage across the fan can be safely reduced to 9 volts. To do this, simply snip the red lead on the fan and solder a 50 ohm resister in series with the red lead. Some people (i.e. me) still find it too noisy even at 9 volts. If you are not comfortable soldering a resistor, you might purchase a Zalman Fan Mate Fan Replacement Many fans are quieter than the BiSonic 4010. For instance, Papst makes very quiet fans. I installed a very quiet Papst 8412NGL 80mm fan in my computer. Note that this fan is twice the size of the Bisonic 4010, so I mount it to the case above the CPU. Papst also sells a 40mm fan. Heat Sink Replacement The EPIA M10k board features a puny heatsink on top of the CPU. VIA secured the heatsink to the board using hole spacing typically used by northbridge heat sinks. Therefore it is possible to replace the small M10k heat sink with a more substantial heatsink such as the Zalman NB47J. Even so, the NB47J is not designed to dissipate the heat from a VIA CPU so you are definitely taking some chances using it without a fan. Some people have experimented with large P3 heatsinks, heat sinks from old hi-fi amplifiers, and even large home made heat sinks. These experiments can be found by searching silentpcreview.com, the viaarena.com C3 forum, and epiacenter.com. Typically they require some metalwork which is beyond the scope of this howto. DRI Only Works as root This is a complicated problem because there are at least three different configuration errors that result in this behaviour. Missing DRI section in /etc/X11/XF86Config. There must be a DRI section in the XF86Config file: Section "DRI" Mode 0666 EndSection If you change the DRI section then you should remove the /dev/dri/card0 device file before restarting X Incorrect permissions on /dev/agpgart. Change the permission on this file to 666, e.g.: bash# chmod 666 /dev/agpgart Incorrect permissions on /usr/X11R6/lib/modules/dri/via_dri.so. Change the permissions on this file to 666, e.g.: bash# chmod 666 /usr/X11R6/lib/modules/dri/via_dri.so Not enough video RAM. Go to the BIOS setup menus and make sure that at least 32MB is reserved for video RAM. You must insert the agpgart module before via_v4l_drv. Edit /etc/modules.conf or /etc/modprobe.conf and reboot. From Thomas Hellstrom:
If the X server crashes for some reason it may fail to give back reserved AGP memory to the system. After some crashes the AGP memory space may be exhausted. Best way to remedy is to reboot.
DRI or GLX Crashing The module must be installed before the module. DMA Lockup Problem Before talking about the VIA 686a DMA lockup problem, you should know that some distros, including fedora core (3?) ship a broken longhaul driver which will lock up your system under some circumstances. So before looking into the DMA lockup problem you should disable longhaul and retest your system. The 8231 and 8235 southbridge chip tends to lock up when too much DMA activity is going on. Many people report lockups when trying to record video using the Haupage card. I have experienced the lock up when concurrently ripping a CD and copying large amounts of data between hard drives. This is a serious issue, as described in this viaarena thread. VIA staff offer BIOS patches to address this issue. These patches are consider beta software (as of 16 June 2005) and are only offered for certain boards. Here are some links to patches for EPIA M, EPIA MII, EPIA CL. All reports suggest that the EPIA M patch works. Some people report continuing lock ups with the MII and CL patches. Here is some background information about the problem:
The Hog, 2003-11-04 Ivor: I'm asking about DMA because I believe that the 8235 chipset on the EPIA-M may have severe problems with DMA bursts. Using DMA to transfer MPEG to the chip may lockup up the system when other DMA transfers are active, such as harddisk dma data transfers and data transfers to/from the network card. At least this problem occurs when transfering data over the network (100Mb/s) _and_ grabbing video (1 Mb/s) from a Hauppage PVR card simultaneously. I tested with both the built-in kernel via_rhine module and the module provided by Via. So please test this. Simply ensure that DMA on the disk is on (hdparm -d 1 /dev/hdx), then start playing an mpeg and simultaneously transfer (ftp) some gigabytes from another computer to the same disk. With the Hauppage PVR the system locks up: sometimes in 10 seconds, sometimes after 2 minutes. It's kind of roulette when the system will freeze silently. Since the Nehemiah has no APIC (!!) it's impossible to use nmi to catch the problem. The only work-arounds I found thus far are disabling dma on the disks (you don't want that) and setting the network card in 10 Mbps mode.
The_Smurph, 2005-05-30 Hmm. I think I found something related to my IDE-Lockups: http://www.directron.com/faqviaas.html When the 686b southbridge was first released, motherboard manufacturers and VIA discovered a problem when trying to transfer files between the primary and the secondary IDE channels on motherboards using ultra-DMA, when a Sound Blaster Live was plugged in and drivers activated. This issue was caused because too much noise is transferred across the PCI bus by the Sound Blaster Live driver set. In an attempt to fix this issue, some motherboard manufacturers modified their BIOS. In some instances, these modifications to the BIOS caused a data corruption error even when not using a Sound Blaster Live. VIA released a patch which resolves this issue, which is incoroporated in the 4in1 drivers from the 4.31 version onwards. Motherboard manufacturers were advised to change the modifications made to thier BIOS to elimate the data corruption issue. If you are experiencing data corruption or lock up when transferring files between two IDE drives: 1) Make sure you have the latest BIOS from your motherboard manufacturer. 2) Make sure you have the latest 4in1 drivers 3) Make sure when you set up your system that you install the 4in1 drivers both before and after you install the SBL to make sure that the drivers see your SBL and install the correct patch. The patch will only install if the SBL is installed. Hmmm... However - I have no disk connected to IDE-Bus 0 - everything is on IDE-Bus 1... Damn - looks like the 2.6.11 kernel series is too performant - the VIA Hardware does not cope the load on crashes the IDE subsystem... Via-Foolks - anything to say about that?
About this HowTo Credits The participants at VIA's linux forum and linitx.org wrote this HowTo. I'm just the editor and test engineer. The principal contributors, in no particular order, are as follows: _DEAD_, Tony Murray, Sjaak-de-Draak, Master Ki-Adi-Mundi, jonthorpe, Bragon, Huub Reuver, Sean MacLennan, Grigori Goronzy, realkiwi, witch, _totte_ and others. I don't update this sub-section very often. So if you have contributed to linux on the EPIA boards and want to be mentioned here, please send me a message. Contact The contact person for this How To is Andrew Howlett <andrew at howlett dot net>. If I don't answer my email, then go to the viaarena linux forum and PM radagast. Change Log 2005-06-16 Updated DMA Lockup Problem. 2005-01-31 Added CIR section. Updated DRI as root subsection. Added hardware sensors 2.6. 2005-01-14 Added jwilde's instructions for hw mpeg decoding on FC3. Updated the hw mpeg section 2005-01-13 Updated CPU table with submission by M. Ketterl. Updated the fedora section. Updated the hddtemp and smartmontools references. 2004-12-15 Added minimyth to distributions list. Copied verbatim from linpvr.org home page. 2004-11-10 Added comment on Mandrake 10.1, copied from delboy711 comments at linitx.org. 2004-10-18 Added the section on I2C Connector, contributed by Helmut Wollmersdorfer. 2004-09-24 Edited the hardware sensors section, included the code snippet for /etc/lmsensors.conf. 2004-04-24 Added the DRI crashing FAQ. 2004-04-19 Added Cardbus/PCMCIA & CompactFlash section. Updated the longhaul page to 1.3. Updated and added lots of links to Marc de Courville's wiki. Added Freepia to distributions. Updated the CPU table, added a few CPU comments. 2004-04-18 Added DRI only as root to FAQ, add Knoppix to distributions. 2004-02-26 Added Beheremans' findings to Six Channel Audio section. 2004-02-24 Added Scythe in silencing the M10k. 2004-02-21 Added Silencing the M10k section. Mostly taken from this thread. 2004-02-19 Updated the Fedora section to point to Alan Cox XFree86 drivers. Added the Building linux 2.6.2 section. 2004-02-07 Changed the link to the Gentoo HowTo. Updated the CPU table. Distributions: updated the Red Hat section and added Fedora. Added the links section. Added the Hardware Random Number Generator section. Added TC and MII to the models section. 2003-12-07 Additions to the ethernet section. 2003-12-03 Started MythTV section. 2003-11-24 Lots of changes. Minor changes to the ALSA and viaudiocombo sections. Added the six channel sound and spdif sections. Changed the 48khz sampling section to the message by Takashi Iwai. Added the frame buffer sections (still more work to do on frame buffer). Added links to witch's debian howto. 2003-11-19 Added the hard drive temperature section. Added the comments regarding ethernet failure due to insufficient power. 2003-11-15 Improved instructions for installing the via X drivers. Added About this Howto section. 2003-09 Started Epia HowTo in Sep 2003. In-line References Web pages come and go. I have copied some of the more important references to this section in case their on-line references disappear.