ODROID

From ArchWiki
Jump to: navigation, search

Gnome-colors-add-files-to-archive.pngThis article is being considered for archiving.Gnome-colors-add-files-to-archive.png

Reason: Merged to [1].[2][3][4] Redirect to Category:ARM architecture. (Discuss in Talk: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.

Note: Support for the ARM architecture is provided on http://archlinuxarm.org not through posts to the official Arch Linux Forum. Any posts related to ARM specific issues will be promptly closed per the Code of conduct#Arch Linux distribution support *only* policy.

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

See also