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.
Even though usually the Dockstar is accessible via ssh or web interface with OpenWRT, sometimes the onboard pin header comes handy either for using the serial console or for resurrecting a bricked device with JTAG. Therefore it is useful to have the pin header accessible even when the casing is closed. This is not an easy task to make in a nice way due to the clean and elegant look of the device. Previously this has been done by others with connecting only the serial port pins above one USB port, but I managed with all of the 10 pins as shown below. Be sure to have some 2 row 2.0 mm pitch receptors and headers before beginning this hack!
First, I soldered a 10-wire ribbon cable between a 2x5 and a 2x7 receptor (both 2 mm pitch). The latter is important to be 2x7, as it will hold itself mechanically with the first and last unoccupied row (see picture on the right). The wire should not be longer than 8 cm, and should be connected in 90 degree to the 2x5 receptor. The point is that by connecting all the corresponding pins, all pins will be accessible from outside with the same wiring scheme as on the onboard header! It is also a good idea to have pin#1 marked with some paint (I used silver marker here). 
As there are some openings on the upper casing, one of them has to be made a little bit bigger, so that the connector will fit in. In my opinion, these holes are merely for design and are not necessary for proper ventilation. Therefore it is appropriate to have them used for our purposes, as this will make virtually no damage on the elegant look of the device. 
