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 \
PATH=/path/to/jour/toolchain/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf/bin:$PATH
$ 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 \
/path/to/sdcard/boot/mainline
$ 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 https://bit.ly/2Y9JtQS. 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.dtbAfter a reboot it should look like Figure 1:
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 : 0000000000000000After applying a patch, what I created looks like this:
... Hardware : ODROIDC Revision : 000a Serial : 1b00000000000001The 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;
EXPORT_SYMBOL(system_serial_low);
+const char *system_hardware;
+EXPORT_SYMBOL(system_hardware);
+
unsigned int system_serial_high;
EXPORT_SYMBOL(system_serial_high);
@@ -959,6 +962,23 @@ static int __init init_machine_late(void)
system_serial_high,
system_serial_low);
+ 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;
}
late_initcall(init_machine_late);
@@ -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 1b00000000000002Then 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 @@
bias-disable;
};
};
+
+ 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).
Forum member @mad_ady was able to install Hass.io 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-homeassistantThen 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:
mqtt: # this settings for mosquitto: broker: 192.168.1.71 port: 8883 client_id: home-assistant-test certificate: /ssl/ca.crt tls_insecure: trueI 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.
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 loadedUntil 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.
References https://forum.odroid.com/viewtopic.php?f=114&t=35474 https://forum.odroid.com/viewtopic.php?f=111&p=255093#p255083 https://forum.odroid.com/viewtopic.php?t=34570 https://www.home-assistant.io
Be the first to comment