This sounded interesting, so I googled for some benchmark test to measure differences. I found nbench, which measures performance by executing some typical algorithms and compares them to a Pentium 90 based system. So I installed it and run on the i586 CHOST system, then rebuild it completely to i486 CHOST and run it again. The differences are not that huge, but on some algorithms they’re measurable:

The first 13 bars are the different algorithms. The main difference is on the string sort, which is heavily memory dependent. That last 3 rows are a index based on the algorithms. Here is main difference on memory index, as the normalized version shows very clear (positive values mean that i486 is faster):

As there is no significant disadvantage of the i486 CHOST, this seems to be the choice.

If anybody has other (free) benchmarks to suggest, please let me know.

Installating is very easy: Download the patch (GPIO drivers for AMD CS5535/CS5536 (Kernel 2.6.30-rc6)), patch it and compile the kernel:

wget http://www.twam.info/wp-content/uploads/2009/05/gpio.patch -O /root/gpio.patch
cd /usr/src/linux
patch -p1 < /root/gpio.patch

Now run kernel configuration and select

Device Drivers  --->
   [*] GPIO Support  --->
   [*]   /sys/class/gpio/... (sysfs interface)
   <*>   AMD CS5535/CS5536 (Geode Companion Device)

Compile the kernel and reboot. If you go to /sys/class/gpio there should be a file name gpiochip0. Now we can enable some pins and test them. By

echo 6 > /sys/class/gpio/export

we tell the kernel, that we want to use pin 6 from userspace. Pin 6 is connected to led. Now we configure pin 6 as an output by

echo out > /sys/class/gpio/GPIO6/direction

Now we can toggle the values by

echo 1 > /sys/class/gpio/GPIO6/value
sleep 1
echo 0 > /sys/class/gpio/GPIO6/value

ALIX.3D3: modeswitch pins

Notice, that the LED is connected to 3.3V, so setting value to 0 it will be lit. The other LEDs are connected to pin 25 & pin 27. On pin 24 is a switch connected. We can read the value by enabling the pin, setting it as an input and reading the value:

echo 24 > /sys/class/gpio/export
echo in > /sys/class/gpio/GPIO24/direction
cat /sys/class/gpio/GPIO24/value

As the pin has an internal pull up, it will show 1 if the switch isn’t pressed or installed. If you press the switch or connect to the metal pins, it will result in 0.

Don’t forget to unexport all pins after when you’re done:

echo 6 > /sys/class/gpio/unexport
echo 24 > /sys/class/gpio/unexport

Any feedback on the driver is welcome!

• Storing files
• Communication over network (IPSEC, OpenVPN, WPA2, …)

I’ll focus on the first point in this article using LUKS (Linux Unified Key Setup).

To use LUKS and the crypto block, some kernel adjustments have to be made:

Device Drivers  --->
   [*] Multiple devices driver support (RAID and LVM)  --->
   <*>   Device mapper support
   <*>     Crypt target support

-*- Cryptographic API  --->
   -*- Cryptographic algorithm manager
   -*- CBC support
   {*} ECB support
   {*} AES cipher algorithms
   <*> AES cipher algorithms (i586)
   -*-   MD5 digest algorithm
   <*> SHA224 and SHA256 digest algorithm
   [*] Hardware crypto devices  --->
   <*>   Support for the Geode LX AES engine

If you want to test with and without crypto acceleration, I recommend compiling the last one as a module. After compiling and rebooting we have to install LUKE userspace tools:

emerge -v cryptsetup

That’s all. Now we’re ready to test. As we want to bandwidth limitation from a slow CF card or USB stick, we create a memory loopback device for testing purposes with a size of 128 MB:

mkdir /tmp/tmpfs
mount -t tmpfs none /tmp/tmpfs -o size=130m
dd if=/dev/zero of=/tmp/tmpfs/test.img count=131072 bs=1024
losetup /dev/loop1 /tmp/tmpfs/test.img

The tmpfs ramdisk is with intent 130MB large, as the maximum default value is 50% of RAM and with that 128 MB wouldn’t fit in.

At first, we want to measure software AES performance. For this, we have to assure, that the driver for the crypto block is not loaded. You can get a list of all loaded modules with

lsmod

If there’s geode_aes listed, remove it by

rmmod geode_aes

Now we can create a LUKS device by

cryptsetup -y --cipher aes --key-size 128 luksFormat /dev/loop1

Mind the key size of 128 bit as the Geode crypto block is only capable of 128 bit keys. You have to confirm this command with a uppercase YES and entering the passphrase twice:

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Now we can open the container. Run

cryptsetup luksOpen /dev/loop1 test

and enter the previous set passphrase:

Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

The container is now under /dev/mapper/test and we can do some write test by running dd:

dd if=/dev/zero of=/dev/mapper/test bs=16384

After a few seconds, dd will terminate, complaining no space left:

dd: writing `/dev/mapper/test': No space left on device
8160+0 records in
8159+0 records out
133689344 bytes (134 MB) copied, 18.574 s, 7.2 MB/s

That’s OK. We can read here there 7.2 MB/s throughput with crypto block. After closing the container with

cryptsetup luksClose test

we can load the crypto block driver by

modprobe geode_aes

and can run the same commands as above. We’ll get a

dd: writing `/dev/mapper/test': No space left on device
8160+0 records in
8159+0 records out
133689344 bytes (134 MB) copied, 4.88397 s, 27.4 MB/s

noticing that we’ve got a 27.4 MB/s throughput now! This also works with ESSIV as well. It’s a bit slower, but more secure. You can to alter the luksFormat to use it:

cryptsetup -y --cipher aes-cbc-essiv:sha256 --key-size 128 luksFormat /dev/loop1

I measured 7.0 MB/s without and 24.0 MB/s with crypto block. After all testing don’t forget to remove the loopback device and umount the ramdisk:

losetup  -d /dev/loop1
umount /tmp/tmpfs/
rmdir /tmp/tmpfs

Now you can setup your real crypto disk. You might want to initialize your partition with random data before creating the luksContainter. dd is once again your friend:

dd if=/dev/urandom of=/dev/XXX bs=1M

Concerning the use of the crypto block for network encryption: By chance it noticed that if I use WPA2 with AES the geode_aes has a 2 in the used row of lsmod:

Module                  Size  Used by
lib80211_crypt_ccmp     4808  2
ipw2200               115904  0
libipw                 22792  1 ipw2200
geode_aes               5464  2
lib80211                4568  3 lib80211_crypt_ccmp,ipw2200,libipw

So it seems, like WPA2 is using this as well. If you know a method to confirm this, let me know.

M/B Temp:    +59 C  (low  =    +0 C, high =   +70 C)
CPU Temp:  +71.1 C  (low  =  +0.0 C, high = +70.0 C)   ALARM

Alix.3D3 with heat sink

I downloaded the datasheet of the AMD Geode LX800 CPU to check which temperatures are OK. On page 598 I found that my model (ALXD800EEXJ2VD) is fine for temperatures from 0 °C to 85 °C. Anyway I looked in my spare part box if I could find a suitable heat sink and fortunately I found a 40mm x 40mm x 9mm one. So I ordered some thermal adhesive and installed it.

To see the advantage of it, I did some measurements. I compiled cpuburn and let it ran with and without heat sink. I tried with and without the case. All measurements were made with a Intel 2915AGB WiFi card and a SanDisk 4 GB Extreme III Compact Flash card installed. Room temperature was between 23.8 °C and 24.5 °C.

After some start time it’s possible to see that temperature differences between the with heat sink and without heat sink curves is about 4 °C. After running the board for about an hour with 100% CPU load with the case, temperature was about 66.6 °C. That’s about 4 °C less than the measured 71.1 °C in the screenshot above.

So installing the heat sink results in only about 4 °C temperature difference, but installation was very simple and cheap.

LEDs on ALIX.3D3

As most of the ALIX boards, the ALIX.3D3 has 3 general purpose LEDs. There is kernel support for them, but there are problems when the board has a Award BUIS as the ALIX.3D3. After reading the datasheet of the AMD CS5536 Geode companion about initialisation and use of the general purpose pins I got it finally running!

There are 2 problems with Award BIOS. On the one hand it contains no parseable string referring to the board, so the auto detection of the board in driver doesn’t work and the initialisation of at least 1 LEDs is wrong. The first problem is easy to solve, by forcing the kernel to load the driver. For the second problem I wrote a small kernel patch (see Update at the end of the post): leds-alix2 kernel patch for 2.6.29

So how to get them running? First of all we need to patch the Linux kernel and then active support. Download the patch to your box and run

wget http://www.twam.info/wp-content/uploads/2009/05/led.patch -O /root/leds-alix2.patch
cd /usr/src/linux
patch -p1 < /root/leds-alix2.patch

Now run kernel configuration and select

Device Drivers  --->
   [*] LED Support  --->
      <*>   LED Class Support
            *** LED drivers ***
      <*>   LED Support for ALIX.2 and ALIX.3 series
            *** LED Triggers ***
      [*]   LED Trigger support
      <*>     LED Timer Trigger
      <*>     LED Heartbeat Trigger
      <*>     LED Default ON Trigger

compile the kernel and adjust the kernel boot line by adding leds-alix2.force=1 to force the kernel to load the driver. If you use GRUB append it to the kernel line in /boot/grub.menu.lst:

kernel /boot/vmlinuz root=/dev/sda2 lxfb.mode_option=1280x1024@60 leds-alix2.force=1

After rebooting, dmesg should show something like

[    2.819802] leds_alix2: forced to skip BIOS test, assume system has ALIX.2 style LEDs
[    2.833003] Registered led device: alix:1
[    2.845860] Registered led device: alix:2
[    2.858804] Registered led device: alix:3

and you should be able to able to switch on/off the LEDs for example by

echo 1 > /sys/class/leds/alix\:3/brightness
sleep 5
echo 0 > /sys/class/leds/alix\:3/brightness

LED 3 should lit up for 5 seconds. If it’s working it’s time to test some triggers. Try

echo heartbeat > /sys/class/leds/alix\:2/trigger

LED 2 should blink like:   pulse – short pause – pulse – long pause – pulse – short pause – …

Another trigger is timer:

echo timer  > /sys/class/leds/alix\:1/trigger
echo 1000 > /sys/class/leds/alix\:1/delay_on
echo 100 > /sys/class/leds/alix\:1/delay_on

should activate the LED for 1000ms and then switch it off for 100ms and start again. I enabled this 2 triggers and made a simple demo video:

Update: In kernel 2.6.31 the patch isn’t required anymore, as it was accepted in the mainline.

J8: SMBus

The manual of the ALIX.3D3 board mentions a lot of pin descriptions of all pin headers on the board. J8 interfaces the SMBus of the AMD CS5536 Geode companion (which is compatible to I²C if bus speed is below 100kHz, see Maxim’s Appnote for detailed comparison). So why not add additional I²C sensors. As an example I connected an LM75 temperature sensor.

First of all we need to add some pin headers to J8 found on board next to the USB port. The pin assignment can be found on page 18 of the manual:

We have to connect these four lines with the power (pin 8), SDA (pin 1), SCL (pin 2) and ground (pin 4) of the LM75 chip. A0, A1 and A2 have to be connected either to GND or power. The level on these pins configure the slave address of the device. I connected all of them with GND. The typical application example found in the datasheet advises an 100 nF capacitor between pin 4 and pin 8 close to the chip:

If soldered the LM75 (a smd chip) to an adapter and connected everything on a bread board:

If everything is connected it’s time to add software support. I assume you already installed the onboard temperature sensors descriped in my previous article. So, only support for the LM75 is need in the kernel:

Device Drivers  --->
   <*> Hardware Monitoring support  --->
      <*>   National Semiconductor LM75 and compatibles

After compiling and rebooting you can run sensors again. It should show up the new device:

lm75-i2c-0-48
Adapter: CS5536 ACB0
temp:      +30.0 C  (high = +80.0 C, hyst = +75.0 C)

So connecting additional sensors is very easy (when they’re support in the kernel).

Sadly there is no ebuild for flashrom in portage, so Gentoo users (and maybe some other) have to build it on there own, but it’s quite easy. You need to install subversion, an open-source revision control system, first:

emerge -va subversion

As there is no portage package for flashrom, we need to install it somewhere. I installed it in /root/flashrom so it can be removed easily. You can achieve this by

cd root
svn co svn://coreboot.org/flashrom/trunk flashrom
cd flashrom
make

You can do an optional

make install

to install the binaries in /usr/local/sbin and install the man page. Now we should save our old BIOS. Running

flashrom -r /root/bios_save.bin

should display some info on the found chipset and flash chip:

Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "AMIC A49LF040A" (512 KB) at physical address 0xfff80000.
Reading flash... done.

If you have an image of the old installed BIOS you can check, if everything went right, by

diff /root/bios_save.bin /root/bios_old.bin

where /root/bios_old.bin is the old BIOS version, preferable found on the manufacturer’s website. Now we can update the BIOS. Download the new BIOS version (ALIX.3D3 can be found here) and run:

flashrom -wv /root/bios_new.bin

flashrom should print some information, a process status and after all a VERIFIED, if everything went right:

Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "AMIC A49LF040A" (512 KB) at physical address 0xfff80000.
Flash image seems to be a legacy BIOS. Disabling checks.
Programming page: 0007 at address: 0x00070000
Verifying flash... VERIFIED.

Now your BIOS should be updated. It’s time to plug (power) and pray.

Update: After writing a Gentoo Bug report, there is now an ebuild in portage. You can install it by

emerge -va flashrom

00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)

ALSA (Advanced Linux Sound Architecture) supports this chip. To use audio on the board, some adjustments to kernel are needed:

Device Drivers  --->
   <*> Sound card support  --->
      <*>   Advanced Linux Sound Architecture  --->
         [*]   Dynamic device file minor numbers
         [*]   PCI sound devices  --->
            <*>   CS5535/CS5536 Audio

After compiling and installing the kernel, we need to install ALSA userspace tools:

emerge -va alsa-headers alsa-lib alsa-utils

After rebooting the kernel should recognize the sound device:

[    2.830979] cs5535audio 0000:00:0f.3: PCI INT B -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
[    2.842814] cs5535audio 0000:00:0f.3: setting latency timer to 64
[    2.850457] ALSA device list:
[    2.863735]   #0: CS5535 Audio cs5535audio at 0xfe00, irq 11

Now it’s time to setup the audio channels. Run

alsamixer

unmute and pull up the Headphone and PCM faders. Unmute “Mic Boost” and change to the Capture View and pull up Capture there. It should look like

You can navigate with the left/right keys, change the volume with the up/down keys, mute/unmute with M, change between Playback/Capture/All with TAB and quit with ESC.

J12/J13 on ALIX.3D3

Now connect a headphone oder speakers to J12 (headphone output) and run

speaker-test -twav -c2

You should hear a female voice saying “front left” and “front right” on the corresponding channel. Cancel the test with Control+C. Now connect a microphone to J13 (microphone input) and run

arecord -d 5 -f cd -t wav /tmp/mic-test.wav

You have 5 seconds to make some noise. Afterwards run

aplay /tmp/mic-test.wav

and you should hear the previous made noise. Finally do

rc-update add alsasound boot

so that ALSA can save/restore your settings on reboot.

ALIX.3D3 booting

In contrary to most ALIX devices, the ALIX.3D3 has an integrated VGA controller and an Award BIOS (tinyBIOS doesn’t support VGA), so why not attach a monitor.

Standard text mode is supported by default (and faster than graphical mode), but if you wish to change resolution, add a boot logo or even want to use a graphical boot screen like splashutils a framebuffer device is needed.

lspci lists the integrated VGA controller of the AMD Geode LX800 CPU as the video device:

00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video

Luckily the linux kernel supports this device directly and so no VESA framebuffer is needed. To support it, you have to select some options in the kernel config:

Device Drivers  --->
   Graphics support  --->
      <*> Support for frame buffer devices  --->
         [*]   AMD Geode family framebuffer support (EXPERIMENTAL)
         <*>     AMD Geode LX framebuffer support (EXPERIMENTAL)
      Console display driver support  --->
         -*- VGA text console
         [*]   Enable Scrollback Buffer in System RAM
         (64)    Scrollback Buffer Size (in KB)
         <*> Framebuffer Console support

If you like to have to linux boot logo as well, you should add some points in addition:

Device Drivers  --->
   Graphics support  --->
      [*] Bootup logo  --->
         --- Bootup logo
         [*]   Standard 224-color Linux logo

After compiling and installing the kernel, we have to tell him with resolution we prefer. You have to add something like

lxfb.mode_option=1280x1024@60

to you kernel boot line. If you use GRUB as your bootloader just append it to the kernel line in /boot/grub/menu.lst.

Before rebooting you should install framebuffer userspace tools. There’s a ebuild for them, so just try

emerge -va fbset

Now you can reboot. After rebooting resolution should have changed. You can controll settings with fbset tool. It should printout something like

mode "1280x1024-60"
    # D: 107.968 MHz, H: 63.962 kHz, V: 60.002 Hz
    geometry 1280 1024 1280 1024 16
    timings 9262 248 48 38 1 112 3
    rgba 5/11,6/5,5/0,0/0
endmode

You can change modes with this tool if you added your mode to /etc/fb.modes. This file is empty on default, but there are examples in /usr/share/doc/fbset-2.1/. I copied fb.modes.ATI to /etc/fb.modes and tested some modes, which were running fine.

If you want to make some screenshots from your framebuffer, I recommend installing fbgrab by

emerge -va fbgrab

Now you scan make some nice shots with

fbgrab /tmp/cute_tux.png

First of all, I recommend installing Gentoo on a normal desktop to get to know the installing process, which is a bit different from graphical installers of mainstream distros. The Gentoo Handbook is a great documentation how this done.

To install gentoo, you have to boot a minimal or “rescue” linux usually from cd/dvd. I tried to convice the bios to boot from a usb cd-rom drive, but I hadn’t any success.

So I had to prepare a USB stick to boot from. There’s a nice tool UNetbootin which automatically copies ISO images to a usbstick and makes it bootable. I tried a lot with the Linux version of it but didn’t had any success regardless of which ISO image or USB stick I took. So I booted windows and tried it with this version. I had success on the first attempt, using the install-x86-minimal.iso from Gentoo and a 3 EUR SD-card Reader with a 4 GB SDHC card in it, formatted as FAT32 as the only partition (not in superfloppy mode).

If you’ve got a booting usb stick, insert it into a USB plug of the board, attach a USB keyboard and a monitor to the VGA port. Power on and press escape to select the boot menu. There should be an option for the usb stick if everything went fine.

Now the gentoo minimal system should boot and you can proceed with the usual installing (look into Gentoo Handbook for details). The AMD Geode LX800 cpu is a i586 cpu, so you have to install a i386, i486 oder i586 stage (i686 or amd64 won’t work!). I installed a i486 stage 3 and updated later to i586.

Partitioning should follow your preferences but don’t a forget a swap partition. 256 MB of RAM is not that much and gcc will not compile without!

I took

CFLAGS="-O2 -march=i486 -pipe"

for installation as the gcc version on the stage3 archive don’t support the geode march.

The rest of the installation is business as usual. I installed gentoo-sources for a optimized kernel and took this configuration here: ALIX.3D3 kernel-2.6.29-r2 config

After finishing installation and booting with the new kernel, it’s time to update the systems to i586. For this, at first update all packages to actual version, especially gcc to version 4.3. Afterwards it’s save to change

CFLAGS="-march=geode -Os -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer"

and proceed with changing of the CHOST variable. There’s a nice tutorial here: Changing CHOST.

Now you should have a nice and optimized gentoo on your ALIX.3D3

LM86 on ALIX.3D3

The schematics of the ALIX.3D3 mention a temperature sensors LM86 on page 2 which external sensors pins are connected to the TDP/TDN pins of the Geode LX800 CPU. So this sensor should be able to measure CPU and mainboard temperature.

The LM86 ist connected by the SMBus (which is compatible to I²C if bus speed is below 100kHz, see Maxim’s Appnote for detailed comparison) via the AMD CS5536 Geode companion.

To support the temperature sensor by the linux kernel, several options must be set:

Device Drivers  --->
<*> I2C support  --->
<*>   I2C device interface
      I2C Hardware Bus support  --->
      <*> Geode ACCESS.bus support
<*> Hardware Monitoring support  --->
<*>   National Semiconductor LM90 and compatibles

After compiling and booting the kernel, we need some userspace tools to read information by the temperatur sensor. Usually this is done by Lm_sensors. Gentoo provides ebuilds so you should be fine with

emerge -va lm_sensors

After emerging, you should run

sensors-detect

to search for sensors. The program will ask you some question on which devices it should scan for sensors and which modules should be loaded. If you compiled everything into kernel (not into modules) you should be fine with

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no): YES
Probing for PCI bus adapters...
Use driver `scx200_acb' for device 0000:00:0f.0: CS5536 [Geode companion] ISA

We will now try to load each adapter module in turn.
Load `scx200_acb' (say NO if built into your kernel)? (YES/no): no
If you have undetectable or unsupported I2C/SMBus adapters, you can have
them scanned by manually loading the modules before running this script.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.

Next adapter: CS5536 ACB0 (i2c-0)
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x4c
Handled by driver `lm90' (already loaded), chip type `lm86'

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): no

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): no

Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): no

After answering all questions, sensor-detect should be able to find your sensor

Driver `lm90' (should be inserted):
  Detects correctly:
  * Bus `CS5536 ACB0'
    Busdriver `UNKNOWN', I2C address 0x4c
    Chip `lm86' (confidence: 6)

sensors-detect will ask to save config (say YES) and propose some to commands to be executed, but we don’t care, because we compiled everything direct into kernel.

Now sould be able to run sensors and get temperatures:

lm86-i2c-0-4c
Adapter: CS5536 ACB0
M/B Temp:    +47 C  (low  =    +0 C, high =   +70 C)
CPU Temp:  +56.8 C  (low  =  +0.0 C, high = +70.0 C)
M/B Crit:    +85 C  (hyst =   +75 C)
CPU Crit:    +85 C  (hyst =   +75 C)

If everthing’s fine, you can add lm_sensors to default runlevel with

rc-update add lm_sensors default

  Device Drivers  --->
    [*] Watchdog Timer Support  --->
      [*]   Disable watchdog shutdown on close
      <*>   AMD Geode CS5535/CS5536 Watchdog

for beeing able to use the watchdog timer. The Disable watchdog shutdown on close is optional. Usually if the watchdog program terminates it tell’s the kernel to disable the watchdog and the kernel does. With this option you can prevent the kernel from disabling the watchdog.

After compiling the kernel and rebooting you have to install a software to tell the watchdog everything’s fine. You can install it by

emerge -va watchdog

Afterwards you have to enable the hardware watchdog and enable realtime priority in the config file /etc/watchdog.conf

watchdog-device = /dev/watchdog
realtime        = yes
priority        = 1

Now you can start the program by

/etc/init.d/watchdog start

It now sends about every 10 seconds a ping to the watchdog device, claiming everything’s fine. You can configure the program to watch files, network, system load as well, but that’s optional.

Finally do a

rc-update add watchdog boot

to start the program on each boot.

ALIX.3D3 upside

It’s a small (100 x 160 mm) board, with

• AMD Geode LX800 CPU with 800 MHz
• 256 MB DDR DRAM
• Via VT6105M 10/100 Mbit Ethernet
• 2 miniPCI slots
• AMD CS5536 Geode companion providing 2 USB 2.0 ports, 1 serial port (RS232), 1 Compact-Flash slot and integrated VGA and audio

More information, datasheets and manual can be found in the Alix Wiki.

I ordered the board from Varia Store for about 130€ including an aluminium chassis and a suitable power supply.

ALIX.3D3 downside

Challenges are now to install an optimized Gentoo on a Compact-Flash card with support for all hardware included, installing a 802.11b/g/n WLAN card and doing some tests with my Logitech QuickCam Pro 9000.