Using Kernel 5.2 With Armbian: Run WiringPi, HomeAssistant, and More With the Latest Kernel Support

This article addresses the creation of an Armbian image using the mainline linux kernel 5.2.0-rc3, and the setup of the popular home automation software, Home Assistant. This exercise was performed targeting the popular Single Board Computer (SBC) ODROID-C1.

Installation Steps

First, I installed a working Armbian image that comes with a 5.x kernel. Here are the steps to compile and install the mainline kernel:

$ export ARCH=arm
$ export CROSS_COMPILE=arm-linux-gnueabihf-
$ export \
$ make odroidc1_defconfig
$ make -j 4 LOADADDR=0x00208000 uImage dtbs modules
$ kver=`make kernelrelease`
$ sudo echo ${kver} > ../kernel.release

#put the sdcard to your host computer
#and copy the needed files to it

$ sudo mkdir /path/to/sdcard/boot/mainline
$ sudo cp arch/arm/boot/uImage arch/arm/boot/dts/meson8b-odroidc1.dtb \
$ sudo make modules_install ARCH=arm INSTALL_MOD_PATH=/path/to/sdcard/boot/mainline
$ sudo cp .config /path/to/sdcard/boot/mainline/config-${kver}
$ sudo cp ../kernel.release  /path/to/sdcard/boot/mainline

#this copies all relevant files
#then put the sdcard to the C1 and boot
#on the C1:
$ cd /boot/mainline
$ VERSION=$(cat kernel.release)
$ sudo update-initramfs -c -k ${VERSION}
$ sudo mkimage -A arm -O linux -T ramdisk -a 0x0 -e 0x0 -n ../initrd.img-${VERSION} \
  -d ../initrd.img-${VERSION} ../uInitrd-${VERSION}
Note that odroidc1_defconfig does not exist in the mainline kernel. Instead there is the multi_v7_defconFigure However, when I use this, the ODROID-C1 does not boot. I think it is due to the kernel size of about 10Mb. The odroidc1_defconfig is based on the config of @aplu, but there are some more config values that have not been set there before. You can download odroidc1_defconFigurezip from Also, the boot.ini must be edited to make the ODROID-C1 boot the new kernel:
# Booting
ext4load mmc 0:1 0x21000000 /boot/mainline/uImage
ext4load mmc 0:1 0x22000000 /boot/uInitrd-5.2.0-rc6
ext4load mmc 0:1 0x21800000 /boot/mainline/meson8b-odroidc1.dtb
#mainline kernel
#ext4load mmc 0:1 0x21800000 /boot/dtb/meson8b-odroidc1.dtb
After a reboot it should look like Figure 1:

Figure 01

I had to modify the kernel to make wiringPi run. In the mainline kernel, reasonable values are missing in /proc/cpuinfo:

Hardware  : Amlogic Meson platform
Revision  : 0000
Serial  : 0000000000000000
After applying a patch, what I created looks like this:
Hardware  : ODROIDC
Revision  : 000a
Serial  : 1b00000000000001
The cpuinfo-patch looks like so:
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts b/arch/arm/boot/dts/meson8b-odroidc1.dts
index f3ad939..8892151 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -52,6 +52,10 @@
   model = "Hardkernel ODROID-C1";
   compatible = "hardkernel,odroid-c1", "amlogic,meson8b";
+  hardware = "ODROIDC";
+  serial-number = "1b00000000000001";
+  revision = <0x000a>;
   aliases {
     serial0 = &uart_AO;
     mmc0 = &sd_card_slot;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d0a464e..b54a855 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -99,6 +99,9 @@ EXPORT_SYMBOL(system_serial);
 unsigned int system_serial_low;
+const char *system_hardware;
 unsigned int system_serial_high;
@@ -959,6 +962,23 @@ static int __init init_machine_late(void)
+    if (root) {
+      ret = of_property_read_u32(root, "revision",
+                &system_rev);
+      if (ret)
+        system_rev = 0x0000;
+    }
+    if (root) {
+      ret = of_property_read_string(root, "hardware",
+                &system_hardware);
+      if (ret)
+        system_hardware = NULL;
+    }
+    if (!system_hardware)
+      system_hardware = machine_name;
   return 0;
@@ -1295,7 +1315,7 @@ static int c_show(struct seq_file *m, void *v)
     seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
-    seq_printf(m, "Hardware\t: %s\n", machine_name);
+  seq_printf(m, "Hardware\t: %s\n", system_hardware);
   seq_printf(m, "Revision\t: %04x\n", system_rev);
   seq_printf(m, "Serial\t\t: %s\n", system_serial);
I do not know if it is a good idea to put the serialnumber into the devicetree. However, it can be done like so, with the fdtput command:
$ sudo fdtput -t s /boot/mainline/meson8b-odroidc1.dtb / serial-number 1b00000000000002
Then I have some I2C devices running with wiringPi and Home Assistant. However, when I tried, I was surprised that I2C is not yet enabled. It took a while to find the right values for the devicetree. There was still an unsolved problem. After applying the following patch to the devicetree I noticed the /dev/i2c-0 that serve the pins 3 and 5 and the /dev/i2c-1 that serve the pins 27 and 28. With the kernel 3.10.107 this is different, the device numbering of the I2C start with 1 and so the wiringPi is searching the i2c-1 device. I have not found a solution yet. One possible solution would be to modify wiringPi only for ODROID-C1 using mainline kernel, to use the i2c-0 device.

The i2c-path is like so:

diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts b/arch/arm/boot/dts/meson8b-odroidc1.dts
index 8892151..c1d6e40 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -313,6 +313,25 @@
+&i2c_A {
+    status = "okay";
+    clock-frequency = <100000>;
+    pinctrl-0 = <&i2c_a_pins>;
+    pinctrl-names = "default";
+&i2c_B {
+    status = "okay";
+    clock-frequency = <100000>;
+    pinctrl-0 = <&i2c_b0_pins>;
+    pinctrl-names = "default";
+    ds3231@68 {
+      compatible = "dallas,ds1307";
+      reg = <0x68>;
+      status = "okay";
+    };
 &ir_receiver {
   status = "okay";
   pinctrl-0 = <&ir_recv_pins>;
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 800cd65..5831437 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -397,6 +397,14 @@
+      i2c_b0_pins: i2c-b {
+        mux {
+          groups = "i2c_sda_b0", "i2c_sck_b0";
+          function = "i2c_b";
+          bias-disable;
+        };
+      };
With this working, I installed the latest version of Home Assistant 0.94.3 in a venv environment. I tried Docker also, but I was not able to make it run.

In the upcoming weeks, I will test if the I2C reads and writes are without errors. The background is that on my installed ODROID-C1 with kernel 3.10.107 the I2C from time to time hangs and I have to reboot (every 3 ...4 months).

Figure 02

Forum member @mad_ady was able to install through Docker on Armbian. Information there was used to get Home Assistant working in docker. To have my own data path for configuration files I had to give this command:

$ docker run --init -d --name="homeassistant" -v /home/joerg/hassio:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/raspberrypi3-homeassistant
Then I saw the following with the command:
$ docker inspect homeassistant

      "Mounts": [
              "Type": "bind",
              "Source": "/home/joerg/hassio/share",
              "Destination": "/share",
              "Mode": "rw",
              "RW": true,
              "Propagation": "rprivate"
              "Type": "bind",
              "Source": "/home/joerg/hassio/homeassistant",
              "Destination": "/config",
              "Mode": "rw",
              "RW": true,
              "Propagation": "rprivate"
              "Type": "bind",
              "Source": "/home/joerg/hassio/ssl",
              "Destination": "/ssl",
              "Mode": "ro",
              "RW": false,
              "Propagation": "rprivate"
With this, I realized why Home Assistant always gave an error for the mqtt certification file. With the venv version you give full path to the file, in Docker this is mounted to /ssl. I see that I have to learn more about Docker.

My mqtt section now looks like this:

# this settings for mosquitto:
  port: 8883
  client_id: home-assistant-test
  certificate: /ssl/ca.crt
  tls_insecure: true
I use the normally installed mosquitto broker, since I was not able to make the Dockerized addon for mosquitto run. When I use my certification files it reports a protocol error. So I switched back to the normal mosquitto installation. Now the difference is that there is a hassio section, which gives the possibility to install addons.

Figure 03

Note that there is no apparmor, as shown below. I had to learn how to enable it and, in the process, I got to learn Docker, too.

$ sudo aa-status
apparmor module is not loaded
Until now I used the ODROID-C1 in a headless configuration with mainline kernel. I can say that I2C is working. I tried my USB Bluetooth adapter, but had no luck. I got it to work only for a moment after enabling bluetooth support with armbian-config, but after reboot, does not matter if power cycle, there is no adapter visible with lsusb. My installation runs on an SD card. Also, I have not yet tried IR and eMMC.

I got Docker running with Home Assistant, but yesterday I got a lot of SD card errors. The heartbeat LED was flashing, but I could not get access anymore. After reboot I checked with fsck and got a lot of errors, but when I made the check with my host pc there were no errors. After that booted normally, I had to uninstall and reinitialize the Home Assistant in Docker. As of now I can say that it is not running stable.


Be the first to comment

Leave a Reply