Experiments with Armbian, mainline kernel, wiringPi, i2c and Homeassistant

[joerg]

First I like to thank the user @aplu for his thread viewtopic.php?f=111&p=255093#p255083 that has inspired me to try this. With his information I was able to compile and install the mainline kernel 5.2.0-rc3.
And second the user @mad_ady for his very detailed thread of setting up Home-Assistant.
Not to forget the user @igorpec for his work to bring Armbian to Odroid C1.

First I installed a working Armbian image that comes with a 5.x kernel.

Here I repeat the steps to compile and install the mainline kernel:

Code: Select all

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 the odroidc1_defconfig does not exist in mainline kernel. Instead there is this the multi_v7_defconfig. But when I use this, the C1 doesn't boot. I think it is because the size of about 10Mb of the kernel. The odroidc1_defconfig is based on the config of @aplu, but there are some more config values that have not been there before.

odroidc1_defconfig.zip

(37.47 KiB) Downloaded 32 times

Also the boot.ini must be edited to make the C1 booting the new kernel:

Code: Select all

# 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 this:

Bildschirmfoto vom 2019-06-23 17-20-57.png (35.95 KiB) Viewed 676 times

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

Code: Select all

...
Hardware	: Amlogic Meson platform
Revision	: 0000
Serial		: 0000000000000000

After apply a patch I created it is looking like this:

Code: Select all

...
Hardware	: ODROIDC
Revision	: 000a
Serial		: 1b00000000000001

cpuinfo-patch:

Code: Select all

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);

But I don't know if it is a good idea, to put the serialnumber into the devicetree. But who like can edit this with the fdtput command:

Code: Select all

sudo fdtput -t s /boot/mainline/meson8b-odroidc1.dtb / serial-number 1b00000000000002

Then I have some i2c devices running with wiringPi and Homeassistant. But when I tried I was surprised that that i2c is not enabled yet.
It took while to find the right values for the devicetree. And there is still a unsolved problem. After apply of following patch to the devicetree I have 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 haven't 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.

i2c-patch:

Code: Select all

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 Homeassistant 0.94.3 in venv environment. I tried also docker, but I wasn't able to make it run.
For some days or even weeks I will test if the i2c reads and writes are without errors. The background is that on my installed C1 with kernel 3.10.107 the i2c from time to time hangs and I have to reboot (every 3 ...4 months).

Bildschirmfoto vom 2019-06-23 18-13-39.png (48.51 KiB) Viewed 676 times

[mad_ady]

Congrats on your setup. I was able to setup hassio in a docker environment on the C1 and gifted it to a friend. I have some notes on the forum, but I was using kernel 3.10.

[joerg]

Thank you @mad_ady, I will search and try again some day when I have time... May long weekend now ends.

[mad_ady]

Here it is: https://www.google.com/url?sa=t&source= ... 0LWIYh_PW-
It should work for you on armbian as well once you get docker working.

[odroid]

Looks great.
Glad to hear Kernel 5.2 works for your project.

[joerg]

@mad_ady, I was able now to install hass.io in docker.
But 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 this with the command docker inspect homeassistant

Code: Select all

        "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 became the idea, why homeassistant always gave 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 as this:

Code: Select all

mqtt:
# this settings for mosquitto:
  broker: 192.168.1.71
  port: 8883
  client_id: home-assistant-test
  certificate: /ssl/ca.crt
  tls_insecure: true

Note that I use the normally installed mosquitto broker. I was not able to make the dockerized addon for mosquitto run. When I point to my certification files it reports a protocol error. So I switched back to normal mosquitto installation.

Now the difference is that there is a hassio section, that give the possibility to install addons.

Bildschirmfoto vom 2019-07-02 12-01-28.png (71.03 KiB) Viewed 539 times

And note that there is no apparmor:

Code: Select all

sudo aa-status
apparmor module is not loaded.

I have to learn, how to enable.

[mad_ady]

Sounds great. You get to learn docker in the process

[Nuems]

@joerg
Could you please tell us a bit more about your mainline kernel? You've mentioned @aplu and his kernel thread. Over there, @aplu mentioned that he hasn't looked into some areas:

This kernel is booting on my board, I didn't try all functionality (such as HDMI, IR, eMMC, ...) but network and USB are working (for the network there are issues with gigabit but it works fine at 100M).

So does your kernel support HDMI, eMMC or IR?

[joerg]

Hello Nuems, until now I used the C1 with mainline kernel headless. I can say that I2C is working. I tried my usb bluetooth adapter, but since now no luck. I got it only for a moment after enabling bluetooth support with armbian-config, but after reboot, doesn't matter if power cycle, there is no adapter visible with lsusb. My installation runs on sdcard. Also not yet tried IR and eMMC. I got docker running and also home assistant in docker, but yesterday I got a lot of sdcard errors. The heatbeat LED was running, but I couldn't 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 weren't errors. After it booted normally but I had to rm and to initialize again the home assistant in docker.
As now I can say that it is not running stable.

[Nuems]

Thanks for answering. I'm thinking about a new role for my C1 as I don't need it any longer for Kodi and apparently, a headless setup seems to make most sense. Maybe I should put Armbian Buster on the µSD card and use the emmc for Xenial