ODROID
Related articles
There are several supported ODROID ARM boards available to consumers. This wiki page offers general configuration that should be applicable to them all. At this point, the content has been verified to work on the ODROID-C2 and ODROID-U3.
Contents
Installation
See the installation instructions at the Arch ARM project page.
Kernel updates
It should be noted that unlike the Raspberry Pi kernels that boot without an initramfs, the AArch64 kernels (kirkwood and linux-odroid-c2 for example) do require an initramfs which is generated by mkinitcpio just like Arch x86_64 or i686. Upon updates, it is known that mkinitcpio does not detect ARM kernel modules and as such, will display following warnings which are harmless:
-> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [autodetect] find: ‘/sys/devices/platform/’: No such file or directory -> Running build hook: [modconf] ... -> Running build hook: [fsck] ==> WARNING: No modules were added to the image. This is probably not what you want.
General quirkiness
Bridge interfaces do not work as expected
Is is known that both the ODROID-C1+ and ODROID-C2 (perhaps others) have a limitation with network bridges hypothesized to be due to the currently supported, but old 3.14.x series of kernels. The limitation is that established network tools such as netctl and systemd-networkd cannot create and bring up a usable network bridge needed for linux containers among other things.
One solution is to use odroid-auto-bridgeAUR which will setup the bridge automatically using a discrete systemd service. This bridge can then be managed by systemd-netword or netctl (others too). See the upsteam readme for more.
DHCP assignments to LXCs do not work as expected
Running linux containers on an ODROID host is quirky. In addition to the difficulties with network bridging described above, users will need to change the default forwarding policy on the host OS to allow for DHCP requests to the containers to work properly. Alternatively, users can use implement a static IP setup for containers.
Users wishing to retain the DHCP functionality need to install ufw and configure it (see Uncomplicated Firewall#Basic configuration) on the host OS, Beyond the standard configuration, modify /etc/default/ufw
as follows:
/etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"
Failure to do so will result in an non-function DHCP assignment within the container even if users create a ufw rule or profile that specifically allows ports 67 and 68.
CPU scaling and temperature management
Headless mode for the C2
For servers (ie no need for a display), one can uncomment the following in /boot/boot.ini
to free up approx 300 M of memory at the cost of disabling the video subsystem:
setenv nographics "1"
CPU frequency scaling
The cpupower package can be used to select alternative CPU governors for power savings. Edit /etc/default/cpupower
and set the governor= line followed by start cpupower.service.
Show online/offline cores
If using the hotplug governor, idle cores are switched off to reduce power consumption and heat generation.
lscpu |grep line
Onboard hardware sensors
CPU temperature
awk '{printf "%3.1f°C\n", $1/1000}' /sys/class/thermal/thermal_zone0/temp
CPU frequency
awk '{printf "%3.1f MHz\n", $1/1000}' /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Lightweight monitoring suite
monitorixAUR has specific support for the the ODROID since v3.8.2 through the gensens = y
setting in /etc/monitorix/monitorix.conf
. Core temperature and CPU frequency are logged; screenshots available here.
Hardware tweaks
CPU Fan
The optional CPU fan can be controlled via the /sys/devices/platform/odroidu2-fan
interface.
Fan Mode
# echo auto > /sys/devices/platform/odroidu2-fan/fan_mode
# echo manual > /sys/devices/platform/odroidu2-fan/fan_mode
Fan Speed (Manual Only)
Values range from 0 (0%) to 255 (100%)
# echo 0 > /sys/devices/platform/odroidu2-fan/pwm_duty
# echo 255 > /sys/devices/platform/odroidu2-fan/pwm_duty
LEDs
Several ODROID models have dual LEDs: a red power LED which is always on if power is supplied, and a blue LED which can be configured.
Blue LED
By default, the blue LED is a heartbeat LED, which flashes when the kernel is running. Depending on the model, this can be changed through the following..
- ODROID-C2:
/sys/class/leds/blue:heartbeat/trigger
- ODROID-U3:
/sys/class/leds/led1/trigger
List available triggers
# cat /sys/class/leds/blue:heartbeat/trigger
none rc-feedback nand-disk timer oneshot [heartbeat] backlight gpio cpu0 cpu1 cpu2 cpu3 default-on transient flash torch sd emmc battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid ac-online
Temporary configuration
Replace TRIGGER
with one of the available triggers. This setting will apply instantly, but be lost upon reboot.
# echo TRIGGER > /sys/class/leds/blue:heartbeat/trigger
Permanent configuration
Replace TRIGGER
with one of the available triggers. This setting will apply upon reboot.
/etc/tmpfiles.d/leds.conf
w /sys/class/leds/blue:heartbeat/trigger - - - - TRIGGER