Headless-only Virtualbox

Virtualbox is a versatile virtualization solution. That is, many virtual machines can be hosted on a single physical computer. This software is well supported under Linux, download and installation instructions for the binary package can be found here. Interestingly, although virtualization comes especially handy in server environments, Virtualbox demands most of the X-Windows system to be installed as a package dependency, even though command line operation and Remote Display (VRDP) as output device is supported in headless mode meaning that the graphic output of the guest operating system can be viewed with a RDP software such as Windows' built-in Remote Desktop Connection.

Luckily enough, such package dependencies can be circumvented, saving the system several hundreds of MBs of unnecessary packages at the expense of loosing all local graphic capabilities. But if you do not plan to install and use X anyways, then this will not be a problem.
The steps below are based on forum posts here and here. I however had to update those instructions to be useful for the current version 3.2. As usual, a Debian-based distribution is assumed, yet the adaption should be straightforward to other distributions as well.

Download the appropiate package from here and save it to ~/virtualbox/virtualbox.deb. Then:

#: cd virtualbox

#: dpkg --extract virtualbox.deb original

#: dpkg --control virtualbox.deb original/DEBIAN

Now we have the extracted package along with the dependency information in original/DEBIAN/control.

First we delete unnecessary files and dirs from the package:

#: rm -rf usr/lib/virtualbox/sdk usr/lib/virtualbox/VirtualBox usr/lib/virtualbox/VirtualBox.so usr/lib/virtualbox/VBoxSDL usr/lib/virtualbox/VBoxSDL.so usr/bin/VirtualBox usr/bin/VirtualBox.so usr/bin/VBoxSDL usr/lib/virtualbox/libQtGuiVBox.so.4

Now, resolving the dependency issue, the content of the original/DEBIAN/control has to be altered. The important part here is the part starting with "Depends:" where plenty of packages reside. For command line operation, only the following are necessary:

Depends: libc6 (>= 2.6), libcurl3-gnutls (>= 7.16.2-1), libgcc1 (>= 1:4.1.1), libssl0.9.8 (>= 0.9.8m-1), libstdc++6 (>= 4.4.0), libxml2 (>= 2.7.4), psmisc, adduser

Save the file, and the package is ready to be repacked and installed:

#: dpkg --build ~/virtualbox/original ~/virtualbox/repacked.deb

#: dpkg --install ~/virtualbox/repacked.deb

Note that after such a reconfiguration only VBoxHeadless can be used to start the virtual machines, and they can be configured using the VBoxManage command line tool.

Lm-sensors in net-snmp

Readout of integrated motherboard sensors was already a topic here, for VIA Epia boards and for WD Mybook World Edition as well. Such data is good to have visualized, so plotting it using MRTG was discussed too. This tool and its fundamental, net-snmp was designed to visualize network traffic data, so for sensor readings, an external script had to be constructed, which was quite inconvenient.

There is however a better way, briefly mentioned by lm-sensors.org, for which net-snmp has to be installed from source (download here, install instructions here) and has to be configured with the following options:

~$: cd net-snmp

~$: ./configure --with-mib-modules="ucd-snmp/lmsensorsMib" --with-ldflags="-lsensors" 

~$: make

~$: sudo make install

If installation was successful, lm-sensor readouts can be accessed via snmp, the same way as if they were polled by the command-line sensors tool:

~#: sensors

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +33.0 °C  (high = +78.0 °C, crit = +100.0 °C) 

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +32.0 °C  (high = +78.0 °C, crit = +100.0 °C) 

~#: snmpwalk -v 2c -c public localhost Sensors

LM-SENSORS-MIB::lmTempSensorsIndex.1 = INTEGER: 1
LM-SENSORS-MIB::lmTempSensorsIndex.2 = INTEGER: 2
LM-SENSORS-MIB::lmTempSensorsDevice.1 = STRING: Core 0
LM-SENSORS-MIB::lmTempSensorsDevice.2 = STRING: Core 1
LM-SENSORS-MIB::lmTempSensorsValue.1 = Gauge32: 33000
LM-SENSORS-MIB::lmTempSensorsValue.2 = Gauge32: 32000

Sadly, only CPU core temperatures can be read out for ICH8/ICH9 chipsets at the moment, still it is now way easier to integrate lm-sensor readings to net-snmp based logging and plotting tools such as MRTG.

Chocolate Fondue: Emergency Edition

Well, winter has come, and so has the cold weather, therefore a nice hot chocolate fondue could save life. This fondue set consists of three small glasses, one small ceramic bowl, one top of cookie box, and two candles (one for support and one for melting the chocolate chips).

Just a short note from Rome

Apparently the ticket vending machines of Trenitalia (Italian railway company) still run on OS/2 Warp 4. I just saw one of them rebooting :cool:

HP 5036A Microprocessor Lab

I just got this machine possessed. It is a microprocessor demonstration board based on the Intel 8085 CPU meaning that it was built for educational use and to demonstrate the capabilities of Intel's early 8 bit CPUs. According to a very few information on the web it was produced from 1978 through the early 80's by Hewlett-Packard.

First impressions:

The nice leather briefcase makes the appearance really elegant, something that is missed from new and modern equipment. Also, push buttons are built for eternity, no lifetime by design.

Technical data:

Manufacturer: Hewlett-Packard;

CPU: NEC D8085AC (Intel 8085 compatible);

CPU clock: 2 MHz using external 4 MHz crystal;

ROM: 2 KB external  SY2316 (mapped from 0x0000 to 0x07FF);

RAM: 1 KB external 2xSY2114 (mapped from 0x0800 to 0x0BFF);

Keyboard: built-in hexadecimal keyboard plus additional function keys;

Display: 6 digit LED display;

I/O: one 8 bit port with LED indicators and DIP switches;

On-board speaker;

Additional jumpers are provided to simulate circuit failures.

Note: Regarding to the ROM and RAM chips, I could only recover the manufacturer called Synertek, which was founded in 1973, bought by Honeywell in 1979, and finally closed off in 1985. Some photo on their products can be found here.

Operation:

Upon a successful boot, the message "uLAb UP" is visible on the LED displays. Storing new programs in the RAM is possible using the push button interface. These among built-in code can be run by simply pressing "Fetch Address", setting the appropriate memory address and pressing "Run". Single line execution is also possible. This is a notable example for a compact yet powerful user interface from times before LCD/TFT displays.

In order to ease learning, several built-in demos are accessible. Notable examples are:

the Rocket Launcher demo on address 0x05F9;

Display test with moving pattern on address 0x055A;

Random Tone Generator on address 0x053E;

Stopwatch on address 0x0662.

The documentation is in fact fascinating: a 450 page book entitled Practical Microprocessor is included in the briefcase. This is not only a tutorial but a complete documentation including ROM listing, schematics and some brief datasheets as well. 

VIA Epia Homeserver Project - HDD Power Saving

The power consumption of a hard disk cannot be neglected in a system designed to be of low consumption. For the operating system, a flash based drive (SSD or CF disk) is a good solution, yet for high volume storage this is usually not affordable. Recently, hard disk drives in the terrabyte range especially designed to be power efficient have been announced such as Western Digital's Greenpower series or the Ecogreen drives of Samsung. Their offer is  a substantial decrease of power consumption (up to 40% claimed) at the expense of somewhat slower operation. This is achieved for instance by spinning only at 5400rpm instead of 7200rpm, which is still reasonable for media storage or backup and even for office applications.

This tutorial is on setting up a Samsung Ecogreen HD154UI drive in my Via Epia homeserver. The goal was to make use of the power saving features that the drive has to offer using the native linux tool hdparm.

This is a very powerful (and therefore dangerous!) program that can read or set many parameters of PATA or SATA drives in order to tune performance, power consumption, or even hot swap disks. As of the writing of this tutorial, I use hdparm v8.9, note that syntax might change later on. It is also important that the proper driver for the PATA and SATA chipset is either compiled in the kernel or loaded as a module.

All functionality of hdparm is available through command line, yet it is better to use /etc/hdparm.conf to adjust parameters, as it will make those effective after each system boot. Mine looks like this:

/dev/sda {
    dma = on
    interrupt_unmask = on
    mult_sect_io = 16
    write_cache = on
    transfer_mode = 70
    io32_support = 1
    apm = 1
    spindown_time = 60
}

with dma = on meaning DMA instead of PIO (this is the default anyway). Interrupt_unmask = on allowing the system to process multiple IRQs at the same time. mult_sect_io = 16 determines the number of simultaneously transferred blocks (safe to set it to its maximum value). Write_cache = on tells the system to cache write operations. This might be dangerous if a power-cut occurs, yet usually is a good idea to set. Transfer_mode = 70 sets UDMA6. Other UDMA, DMA, PIO settings can be found here. io32_support = 1 is quite straightforward and should be set as well. 

The rest are the power saving parameters: apm = X sets how aggressively the drive would enter power saving modes with 1 equals the lowest consumption and 255 means no power saving and maximum performance. Note that X being equal to 128 or above, no spindown is allowed. As I use my disk mostly for storage, I chose the lowest power setting, X=1. Spindown_time sets the length of inactivity before the drive spins down in 5 sec units, so that 60 means 5 minutes timeout. If you experience that you have to wait often to the drive to spin up, consider setting this parameter higher. 

It is very important to note that not only disk I/O but any disk operation including checking drive health status using smartmontools will cause the drive to spin up. This means that periodic checking of drive health or temperature will render this setting essentially useless.

If hdparm.conf is set up correctly, the new parameters will be effective upon the next boot and can be checked:

~#: hdparm -i /dev/sda

/dev/sda:

 Model=SAMSUNG HD154UI                         , FwRev=1AG01118, SerialNo=S1XWJ1KZ300133     
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=32767kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

VIA Epia Homeserver Project - CPU Frequency Scaling

Even though the VIA Epia platform is designed to be very power efficient out of the box, it can be made even better. One tool to do this is the CPU frequency scaling that is supported by both recent linux kernels and the Eden CPU. Specifically, the processor of the EN12000EG board runs at 1200MHz by default, but can go down to as low as 400MHz, resulting not only in reduced power consumption, but decreased heating as well. This especially comes handy for fanless systems, eventually resulting in lower die temperature and longer life span.

System setup

In order to utilize this feature the following kernel modules have to compiled (=Y), or installed as module (=M):

X86 CPU: CONFIG_X86_CPU=y 

VIA C7 CPU: CONFIG_MVIAC7=y

ACPI: (not sure if these are necessary, yet they won't hurt...)

CONFIG_ACPI=y 

CONFIG_ACPI_PROCESSOR=y

CONFIG_X86_PCC_CPUFREQ=y

CONFIG_X86_ACPI_CPUFREQ=y

(Note: # CONFIG_X86_E_POWERSAVER is not set because it is considered to be dangerous as no hardware limits are taken into account while tuning the CPU clock. However, I did not find any remarks nor observations on this driver).

CONFIG_CPU_FREQ=y

CONFIG_CPU_FREQ_TABLE=y

CONFIG_CPU_FREQ_STAT=y

CONFIG_CPU_FREQ_STAT_DETAILS=y

CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y

CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

CONFIG_CPU_FREQ_GOV_POWERSAVE=y

CONFIG_CPU_FREQ_GOV_USERSPACE=y

CONFIG_CPU_FREQ_GOV_ONDEMAND=y

CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

The options above sets the Governors that can be used later on. As you can see, there are five alternatives, Performance, Powersave, Userspace, Ondemand and Conservative.

The character of each governors  are the following:

•  Performance: simply sets the highest available CPU frequency. Usually this is the default in stock kernels.
• Powersave: sets the lowest available frequency no matter what the system load is.
• Userspace: the CPU clock can be set manually thorugh the /sys interface
• Ondemand: switches between the highest and lowest frequency according to the system load. The corresponding thresholds can be set via the the /sys interface. 
• Conservative: such as above, although it can set intermediate frequency values as well. The trade-off is higher latency.

The default governor is quite straightforward to set, here I chose Conservative. In this tutorial, only this governor is discussed in detail, however, most of the arguments are straightforward to use for the others as well.

Test results

Upon booting with the new kernel and/or loading the corresponding modules, the influence of the governor is already visible (remember, Conservative governor is set):

#:  cat /proc/cpuinfo

processor    : 0

vendor_id    : CentaurHauls

cpu family    : 6

model        : 10

model name    : VIA Esther processor 1200MHz

stepping    : 9

cpu MHz        : 400.000

cache size    : 128 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 vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en

bogomips    : 797.99

clflush size    : 64

cache_alignment    : 64

address sizes    : 36 bits physical, 32 bits virtual

power management:

showing that the CPU clock is set to 400MHz. If, however, some CPU intensive process is started (compiling kernel or some application is a good check :)) then increased demand results in increased clock frequency:

#:  cat /proc/cpuinfo

processor    : 0

vendor_id    : CentaurHauls

cpu family    : 6

model        : 10

model name    : VIA Esther processor 1200MHz

stepping    : 9

cpu MHz        : 1200.000

cache size    : 128 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 vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en

bogomips    : 2393.89

clflush size    : 64

cache_alignment    : 64

address sizes    : 36 bits physical, 32 bits virtual

power management:

Detailed statistics is available via the /sys interface:

#: cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

1200000 38445

400000 42604408

which tells us both the available frequency values (in kHz) and the corresponding time that the CPU spent in that state in 10ms.

#: cat /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table

   From  :    To

         :   1200000    400000

  1200000:         0        51

   400000:        50         0 

This command provides a nice matrix in which the starting and end frequency for each transition is observed. Note that as the system boots up using the higher value, the difference of one means that now the clock is equal to the lower value.

The current frequency can be obtained as above by interrogating /proc/cpuinfo, however /sys tells it as well:

#: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

400000

The operation of this governor can be tuned via the nodes in /sys/devices/system/cpu/cpu0/cpufreq/conservative (followed by their default values):

down_threshold (20)

freq_step (5)

ignore_nice_load (0)

sampling_down_factor (1)

sampling_rate (200000)

sampling_rate_max (4294967295)

sampling_rate_min (200000)

up_threshold (80)

I however advise to be careful tampering with them. As each clock transition takes time the penalty can be serious performance degrade if the system is set to change frequency too often. On the other hand, increasing power consumption and heating is the result of too soft settings.

Conclusions

Using the Conservative governor is a reasonable improvement for my VIA Epia box, as the system now spends most of its time (over 99%!) in 400MHz instead of 1200MHz. In theory, however, some degradation of performance is associated with tuning the CPU frequency (as the clock transition takes time to occur), this was not observable for my system. 

Sadly enough, the governor was not able to tune the CPU clock continuously, it rather switched between the highest and lowest available values. Because of this, the Conservative and Ondemand governors essentially equivalent on this system. I am not sure if using CONFIG_X86_E_POWERSAVER instead of the default ACPI cpufreq driver solve this problem, this is to be tested.

VIA Epia Homeserver Project - On-board Sensor Readings

The scope of this post is to make use of the onboard voltage and temperature sensors that can be useful to avoid dangerous operating conditions such as overheating.

In order to make them work, compiling a recent kernel was necessary so I first obtained the latest version from kernel.org (2.6.34 as of today).

On EN12000EG, the following hardware supports built-in sensors:

• Temperature sensor in VIA Eden CPU;
• Winbond W83697 SuperIO chip featuring power supply voltage and temperature readings. Link to datasheet is here.

The following kernel options have to be set (followed by the actual name of the option in the .config file):

• ISA support: CONFIG_ISA=y
• hardware monitoring support: CONFIG_HWMON=y
• VID support: CONFIG_HWMON_VID=y
• VIA CPU temp sensor support: CONFIG_SENSORS_VIA_CPUTEMP=y
• Winbond driver: CONFIG_SENSORS_W83627HF=y
• the ACPI drivers: CONFIG_THERMAL=y and CONFIG_THERMAL_HWMON=y

Note: these can be compiled as modules as well, in which case OPTION=m will be in the at the corresponding line.

Next, obtain latest lm-sensors (as of today, it is 3.1.2). Manual for compiling and installing is together with the source, it worked without any problem. Then the sensors can be detected with the sensors-detect tool.

If the options above were compiled as modules, then the following two lines should be add to /etc/modules.conf:

w83627hf

via_cputemp

which will cause the kernel to load these modules on startup.

We are almost ready, however because of recent changes in the kernel architecture (specific version is 2.6.31), some sensors cannot be read because the ACPI code claims the corresponding resources. More information and discussion on the topic is here. The point is, that if we try to load the module for the Winbond chip:

# modprobe w83627hf

we get a "FATAL: [...] Device or resource busy" error message.

The solution is considered to be dangerous, however, I did not notice any problem (yet :)): The option "acpi_enforce_resources=lax" has to be add to the kernel command line upon boot. For grub, this means that the default item in /boot/grub/menu.lst will look something like:

title        Debian GNU/Linux, kernel 2.6.34 for VIA C7 and lm-sensors root        (hd0,0) kernel       /boot/vmlinuz-2.6.34 root=/dev/sdb1  ro acpi_enforce_resources=lax

Now the modules should be able to load, and raw sensor values should read using

$ sensors

Yet, the actual voltage readings need to be calculated using the scheme provided in /etc/sensors3.conf and running sensors -s (as root!) to get the proper readings afterwards.

It is interesting, that for older versions of lm-sensors, the Winbond chip was included in the config file, but it is removed from the latest one. No problem, one can just copy it back:

chip "w83697hf-*"

# no in1 on this chip.

    label in0 "VCore"    

    label in2 "+3.3V"

    label in3 "+5V"

    label in4 "+12V"

    label in5 "-12V"

    label in6 "-5V"

    label in7 "V5SB"

    label in8 "VBat"

    compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)

    compute in4 ((28/10)+1)*@  ,  @/((28/10)+1)

    compute in5 (5.14 * @) - 14.91  ,  (@ + 14.91) / 5.14

    compute in6 (3.14 * @) -  7.71  ,  (@ +  7.71) / 3.14

    compute in7 ((6.8/10)+1)*@ ,  @/((6.8/10)+1) 

# 697HF does not have VID inputs so you MUST set your core

# voltage limits below. Currently set for 1.8V core.

#               vvv

   set in0_min 0.6

   set in0_max 1.2

   set in2_min 3.3 * 0.95

   set in2_max 3.3 * 1.05

   set in3_min 5.0 * 0.95

   set in3_max 5.0 * 1.05

   set in4_min 12 * 0.90

   set in4_max 12 * 1.10

   set in5_max -12 * 0.90

   set in5_min -12 * 1.10

   set in6_max -5 * 0.95

   set in6_min -5 * 1.05

   set in7_min 5 * 0.90

   set in7_max 5 * 1.10

   set in8_min 3.0 * 0.80

   set in8_max 3.0 * 1.20

#   ignore temp2

The rest of the sample config file can even be removed, it makes no use. I also modified the limits of the line in7 as the standby 5V (5VSB) reading is known to scatter more than the others, so +/- 10% is more appropriate.

Note: I am aware that now the lm-sensor policy is that platform-specific configuration is supposed to be in /etc/sensors.d, yet I believe that this way is easier. Moreover, I am not aware of any database that could be used for this purpose, and I have no idea what triggered this change of functionality.

Another issue is that I cannot set the limits nor the type of temperature sensors, so lines in the config file like:

set temp1 1 

set set temp1_over 80

set temp1_hyst 75

will result in something like:

# sensors -s

Error: File /etc/sensors3.conf, line 95: Unknown feature name w83697hf-isa-0290: No such subfeature known

Not only the limits but the sensor type cannot be set as well, therefore the second temperature sensor (temp2) always reads false values below even room temperature. I am not aware of the resolution of this issue, but I will update the post as soon as I find the proper solution.

Omitting the invalid lines, now we get the actual readings:

# sensors -s

$ sensors

acpitz-virtual-0

Adapter: Virtual device

temp1:       +15.5°C  (crit = +120.0°C)                 

w83697hf-isa-0290

Adapter: ISA adapter

VCore:       +0.83 V  (min =  +0.59 V, max =  +1.20 V)  

+3.3V:       +3.31 V  (min =  +3.14 V, max =  +3.47 V)  

+5V:         +5.11 V  (min =  +4.76 V, max =  +5.24 V)  

+12V:       +12.34 V  (min = +10.82 V, max = +13.19 V)  

-12V:       -14.83 V  (min = -13.18 V, max = -10.80 V)   ALARM

-5V:         -7.66 V  (min =  -5.25 V, max =  -4.75 V)   ALARM

V5SB:        +5.46 V  (min =  +4.49 V, max =  +5.51 V)

VBat:        +3.22 V  (min =  +2.40 V, max =  +3.60 V)  

fan1:          0 RPM  (min =   -1 RPM, div = 4)  ALARM

fan2:          0 RPM  (min = 2109 RPM, div = 4)  ALARM

temp1:       +55.0°C  (high = +12.0°C, hyst =  +2.0°C)  ALARM  sensor = transistor

temp2:       +15.5°C  (high = +120.0°C, hyst = +115.0°C)  sensor = diode

beep_enable:enabled

via_cputemp-isa-0000

Adapter: ISA adapter

Core 0:      +50.0°C                                   

Note that temp2 and the ACPI virtual device has the same reading, both wrong. For temp2 the quick and dirty solution is to simply ignore it by uncommenting the following line in sensors3.conf:

ignore temp2

The rest however works now, so the only thing to do is to make sure that sensors -s is run on every boot of the system. A simple shell script shall do the trick:

#! /bin/sh

SENSORS=/usr/local/bin/sensors #just initializing lm-sensors $SENSORS --version $SENSORS -s $SENSORS

Save it as Sensors.sh in /etc/init.d then chmod it to be executable and link it /etc/rc2.d/S40sensors:

# chmod a+x Sensors.sh

# ln -s /etc/init.d/Sensors.sh /etc/rc2.d/S40sensors

Still, there are remaining issues with the lm-sensors that need to be resolved. For instance, the temp2 and acpitz-virtual-0 readings are both wrong, and you cannot even get rid of the second one! At least there is not option to disable it through /etc/sensors3.conf most likely, the corresponding kernel module needs to be unloaded. Also, the spurious readings of the -12V, -5V lines might not be the real things as most likely they not even used by the motherboard. It also worth mentioning that the new kernel policy of claiming all ACPI related resources resulting in the device drivers not to work anymore might need to be reconsidered, as this is a definite loss of functionality as well, resulting in additional hacking being necessary.

VIA Epia Homeserver Project - Installing Linux

Upgrading the BIOS 

This is optional: I however believe that it is better be safe than sorry :) The latest BIOS for EN12000EG is V1.09 available for download in the Downloads tab. The bad news is that the BIOS flash tool demands DOS. Because of this, I briefly plugged a CD drive to the system and installed FreeDOS on the CF drive. I burned the flash tool and BIOS binary after this, and copied it to CF disk. Note that the latter is necessary as the flash tool does not run from read-only media such as a CD. It is also important to make sure that the motherboard would not be unplugged from the mains during the flashing process!

Preparing the install

If the BIOS update is not necessary, one can install the system without using a CD/DVD drive, only a usb stick is to be used.

As we anyhow build a server, we shall use Debian :)

There is a good howto on debian.org on installing from usb sticks. The main points are the following:

• You need to download two disk images: One for making the usb stick bootable (using syslinux). This can be obtained here (only boot.img.gz is needed). The second one will be the actual installer, for which we use the netinst image meaning that most of the packages will be downloaded from the internet during install. Iso image is available here (choose i386). 
•  The boot image needs to be extracted and written to the flash drive. The device needs to be at least 256MB in size. No matter if it is larger, because the resulting partition will be of this size. The operation can be done via dd, which is available for windows as well by simply issuing in the command line:
       dd if=boot.img of=flash_drive
  with flash_drive being /dev/sdX on linux and \\?\Device\HarddiskY\Partition0 on windows. Note that X=[a,b,c...] or Y=[1,2,3...] for the flash drive that needs to be written. It is important to double-check the actual path before destroying data on another device by mistake! For the windows version this can be done via dd --list which lists all available devices with description. If boot.img is in another directory, then its path needs to be changed as well.
  
• Replug the flash drive and copy the netinst iso image to flash drive, preferably to the root directory. Note that the iso file should not be extracted, but simply copied, as the installer will mount the image itself.

The bootable flash drive is now ready, the only thing to do is to make sure that a wired internet connection is available so additional packages can be downloaded during install. The preferred way is to use an empty LAN port on a router and to use DHCP.

Booting from the flash drive

In principle this should be simple, yet I found it quite hard to make the motherboard boot from USB flash drive even after reading some earlier manuals on the topic. For me, the following steps worked with V1.09 BIOS:

• Set the first boot device to be USB-ZIP in BIOS. 
• Switch off the computer and unplug its mains. 
• Remove all IDE or SATA hard disks, and USB keyboard and mice so that only the USB stick remains.
• Replug the computer and switch it on.
• At this point it will boot from the flash drive (most likely), but obviously there is nothing to install to :)
• Switch off the computer and replug everything that is necessary.
• Start install :)

So,  in a nutshell, it is necessary to have one power cycle with only the flash drive plugged in. The funny thing is that a mere reboot is not enough, one has to unplug and replug the power supply.

And finally, install

Mostly, one can go with the default options. As I used a 4GB CF card as /dev/hda, I formatted 3.75 GB to be the root filesystem (using ext3), and the rest to be swap. Note that it is indeed not recommended to use any flash drive for swapping, yet my experience is that for the intended kind of operation it is rather seldom used, but sometimes it can be useful. As CF contains internal wear leveling algorithm, mainline filesystems, such as ext3 can be used for the system. The only thing that has to be taken care of  is to switch off the atime attribute using noatime mount option (this can be done during partitioning). The default atime causes write to the hard drive for each read operation as it updates the last access time for the files. This is useful for certain applications such as backup and mailing tools, but causes a great deal of unnecessary writing operation.

The rest goes quite straightforward, I chose to install only the option Standard System in order to customize packages later on.

Good-to-have packages

Apart from the default packages that come with the default install, the following ones might be useful as well:

• bzip2, less, mc, ssh-server for convenient use :)
•  make, gcc, libncurses5-dev,  automake, psmisc to make kernel compiling and installing source packages possible;
• ddclient to make the box accessible via its domain name with a dyndns.com account;
• iptables for firewalling and/or routing: this is installed by default, although I prefer to have the latest stable version from http://www.netfilter.org/
• lm-sensors to read on-board temperature and voltage sensor outputs. It was not straightforward to make it work, so I will write about the details in a separate post.
•  samba server from samba.org. Here again make sense to compile from source and setup separately as the version in the debian stable repository is quite old.
• Enhanced ctorrent a nice command-line based torrent client, might be useful as well. Obtained from here. 

Packages in the first three bulletpoints can simply be optained by apt-get install, the rest however are downloaded from other sources and might need some hacking to make them work.

VIA Epia Homeserver Project - Ingredients

I recently decided to put together a small linux box to be a media- and fileserver and router and to be a good playground as well :) My goal is to have a box which is small, quiet and has a low power consumption and not to be forgotten, cheap. From now on, I will write about how to put it together from the bare scratch.

Let's see the ingredients for this project:

Motherboard:

I chose VIA Epia series because of its good availability and because of having a very good power consumption figure. Note that if you plan to play HD movies directly then this is most likely not your platform (better pick something based on Intel's Atom), yet for a router / file server box it is a good trade-off. For a router we need two physical ethernet interface and for high capacity storage SATA connectors. This is what one has to bear in mind when picking the actual device.

I chose EN12000EG because..., well it was a good deal on ebay :) Yet, it has two onboard SATA connectors, and one can add an additional ethernet interface via its PCI slot which is what I exactly did by putting a RTL8169-based gigabit ethernet card in. The motherboard is based on a VIA Eden processor meaning that it is completely fanless which is an important point as well.

Regarding to the memory: One 256MB 533MHz DDR2 one would do it, as we will not need anything that consumes a great deal of system memory. It has to be noted however that the onboard VGA takes 64MB out of the value above.

It is a good thing that the motherboard is well documented, all documentation is available at VIA.

System hard disk:

For this purpose, I will use a 4GB CF card, which is enough for the bare system. To hook this up to the main board, a CF to IDE converter is necessary, which is in the 1 USD range on ebay. Note that it is a good idea to buy a dual CF converter (so that one will be the master and one will be the slave device) for optional temporary storage for for instance torrent, as the main hard disk can be still turned off and does not consume any power. 

Main hard disk:

This will be a Samsung EcoGreen drive as we do not need really fast random seek, rather a low power and reasonable sized storage. Anyhow, the box should be designed so that it turns off the hard drive whenever possible.

Case:

For some reason, cases designed for mini-ITX motherboards are rather expensive. Because of this, I choose a mini-ATX /ITX case, Codegen's MX-31-A2. The only drawback is that the built-in power supply is designed to be capable of 300W output so that it is expected to have very low efficiency for low power systems. This is to be measured later so that I can decide whether it is necessary to replace it.

USB Isolator by Analog Devices

This is something that I was long awaited for. Analog Devices introduced the first digital isolator for USB ports, ADuM4160, meaning that now complete decoupling is possible between USB host and device, including the ground common being separated. Why is it useful?

• The possibility for removing ground loops thus achieving lower noise levels which is handy for low noise instrumentation or high end audio electronics (in fact, it is especially useful for external sound cards plugged on USB);
• Decoupling the device from the computer host might protect the computer if anything goes wrong in the device, i. e. high voltage level appears in the digital parts due to malfunction.

The principle of operation is discussed here, the main point is that a CMOS-integrated transformer couples the output to the input. This is not that simple for USB however, as data flow has to be ensured in both directions, so additional logic circuit is necessary. 

There is one additional goal: to ensure power supply for bus-powered USB devices. For this purpose, I used ADuM5000, which shares the same transformer coupling technique for transferring power to the decoupled part. Sadly enough, the efficiency is quite low, only around 33%. The maximum output is 100mA at 5V but this can be improved by hooking up these circuits in parallel as suggested by the datasheet. I used two devices in the scheme to make use the entire 500mA available on each port which leads to around 200mA maximum output which is still enough for a plenty of kinds of devices.

The schematics is quite straightforward, the most important thing is to decouple power supply pins with 100nF capacitors near the integrated circuit. The PCB is easy as well, a small two sided board is enough. The only guideline is to make sure that there are no nearby copper lines from the parts which could endanger the isolation for high voltages.

I tested the circuit and it worked pretty well with my 1GB flash drive, and it made use of the 12Mb/s Full Speed bandwidth. There were other devices, including USB mice that ended up with a "USB device not recognized" error message upon plug-in. The reason I suspect is the power supply: USB devices can allocate up to 500mA on each port, which should prevent overloading the port. I assume if much more is used just after plugging in the device, the USB controller might inhibit the device in question. Here this could easily happen, as the power supply efficiency is only around 30% (factor of three!).

To check this, I used a self-powered USB hub between the isolator the device (i.e. mouse), and in this fashion, everything worked out for all devices I could test.

There is, however another side effect of the low efficiency of the ADuM5000: if operated on the edge, they can heat up quite easily. I think this can be addressed by gluing some sort of heat sink on the top of the IC.Yet, the heat sink has to be isolated from everything as well!

Update: I tested the board with a small piece of heat sink glued on the two ADuM5000s. I put some thermally conductive adhesive on the top of the ICs, installed the heat sink and glued it together with some two component epoxy which is also useful against accidental shorts and other problems with an unprotected PCB. I tested the device afterward and not it is stable no matter what the load is.

In conclusion, the circuit worked pretty well for me, the only improvement could be a better power supply, or a USB2.0 high speed device... But still, this kind of portfolio is quite unique on the market.

HP Notebook slow while plugged in

I recently encountered a quite strange behavior of my HP 6910p computer. It became extraordinary slow if hooked on the charger. By slow I mean that Windows booting up took more than half an hour (I tested this only once :) ) and afterwards Task Manager showed 100% CPU usage for both cores all the time, no matter if no userspace program was running. This itself could have been a simple Windows issue, but essentially the same happened for a Linux Live CD, and even worse: the BIOS menu was definitely slow to respond. However if I removed the charger (so that it ran on battery), everything went back to normal. 

Realizing that this is a hardware problem I had it repaired under warranty (they replaced the motherboard), after which everything went normal for some days and then the issue reappeared. This happened during the weekend (obviously) so I had to do something. What I noticed was that by moving the cable of the charger sometimes it can be healed. So the resolution was simple: the wire is broken somewhere. But which wire? I have never noticed a power failure, meaning that only the third one in the middle can be the source of the problem. Yes, recent notebooks demand a charger with an additional line which might tell if the charger is a proper one or not. If this connection is not present then the power management of the notebook must fall back to some extra low profile rendering the CPUs slow and the computer essentially useless.

So apart from saying a big thanks to HP I only could cut the wiring open and resolder this inner wire after which I applied a plenty of thin teflon tape to prevent it from either breaking or shorting to the other ones.

Now everything is back to normal, the long-term solution however is buying a new power supply.