Este artículo se centra en la creación de una imagen arm utilizando el kernel principal Linux linux 5.2.0-rc3, y en la configuración del popular software de domótica, Home Assistant. En este ejercicio trataremos especificamente el popular ordenador de placa reducida (SBC) ODROID-C1.
Pasos de instalación
Primero, instala una imagen armbian que funciona con un kernel 5.x. Estos son los pasos para compilar e instalar el kernel estandar:
$ 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}
Tenga en cuenta que odroidc1_defconfig no existe en el kernel estándar. En su lugar, tienes el multi_v7_defconFigure. Sin embargo, cuando yo utilizo éste, el ODROID-C1 no arranca. Creo que se debe al tamaño del kernel de aproximadamente unos 10Mb. Odroidc1_defconfig está basado en la configuración de @aplu, pero hay algunos valores de configuración que no se han ajustados. Puedes descargar odroidc1_defconFigurezip desde https://bit.ly/2Y9JtQS. Además, tenemos que editar el boot.ini para que el ODROID-C1 arranque el nuevo 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.dtbTras reiniciar debería verse algo similar a la siguiente imagen:
Tuve que modificar el kernel para lograr ejecutar wiringPi. En el kernel estándar, faltan algunos valores en /proc/cpuinfo:
... Hardware : Amlogic Meson platform Revision : 0000 Serial : 0000000000000000Tras aplicar un parche, lo que creé se ve así:
... Hardware : ODROIDC Revision : 000a Serial : 1b00000000000001El parche cpuinfo se ve así:
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);
No sé si es una buena idea poner el número de serie en el árbol del dispositivo. No obstante, se puede hacer así, con el comando fdtput:
$ sudo fdtput -t s /boot/mainline/meson8b-odroidc1.dtb / serial-number 1b00000000000002Tengo algunos dispositivos I2C que se ejecutan con wiringPi y Home Assistant. Sin embargo, cuando lo intenté, me sorprendió que I2C aún no estuviera habilitado. Me llevó un tiempo encontrar los valores correctos para el dispositivo. Aun así, había un problema sin resolver. Después de aplicar el siguiente parche al dispositivo, noté que /dev/i2c-0 atiende a los pines 3 y 5 y que /dev/i2c-1 atiende a los pines 27 y 28. Con el kernel 3.10.107 esto es diferente, la numeración del dispositivo del I2C empieza con 1, de modo que wiringPi busca el dispositivo i2c-1. Todavía no he encontrado una solución. Una posible solución sería modificar wiringPi solo para el ODROID-C1 usando el kernel estándar, para usar el dispositivo i2c-0.
La ruta i2c es así:
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;
+ };
+ };
};
};
Con todo este operativo, instalé la última versión de Home Assistant 0.94.3 en un entorno venv. También probé Docker, pero no logre hacerlo funcionar
En las próximas semanas, comprobaré si las lecturas y escrituras de I2C tienen errores. El tema es que en mi ODROID-C1 configurado con el kernel 3.10.107, el I2C se cuelga de vez en cuando y tengo que reiniciar (cada 3 ... 4 meses).
El miembro del foro @mad_ady pudo instalar Hass.io a través de Docker en Armbian. Use esta información para conseguir que Home Assistant funcionase en Docker. Para tener mi propia ruta de datos para los archivos de configuración, tuve que utilizar este comando:
$ docker run --init -d --name="homeassistant" -v /home/joerg/hassio:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/raspberrypi3-homeassistantLuego observé lo siguiente con el comando:
$ 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"
}
],
Con esto, me di cuenta de por qué Home Assistant siempre daba error con el archivo de certificación mqtt. Con la versión venv, se incluye ruta completa al archivo, en Docker esto se monta en /ssl. Veo que tengo que aprender más sobre Docker.
Mi sección mqtt ahora tiene este aspecto:
mqtt: # this settings for mosquitto: broker: 192.168.1.71 port: 8883 client_id: home-assistant-test certificate: /ssl/ca.crt tls_insecure: trueUtilizo el broker mosquitto que generalmente está instalado, ya que no logré que el complemento Dockerized para mosquitto se ejecutara. Cuando uso mis archivos de certificación, aparece un error de protocolo. Así que decidí volver a la instalación normal de mosquitto. Ahora la diferencia es que hay una sección que ofrece la posibilidad de instalar complementos.
Ten en cuenta que no existe ningun apparmor, tal como se muestra a continuación. Tuve que aprender cómo habilitarlo y, en el proceso, también aprendí Docker.
$ sudo aa-status apparmor module is not loadedHasta ahora utilicé el ODROID-C1 en una configuración sin monitor con el kernel estandar. Puedo decir que I2C funciona. Probé mi adaptador Bluetooth USB, pero no tuve suerte. Lo hice funcionar solo por un momento después de habilitar el soporte de bluetooth con armbian-config, pero después de reiniciar, sin importar si el ciclo está encendido, no aparece un adaptador visible con lsusb. Mi instalación se ejecuta en una tarjeta SD. Además, aún no he probado IR y eMMC.
Docker se llegó a ejecutar con Home Assistant, pero ayer aparecieron muchos errores de la tarjeta SD. El LED parpadeaba, pero ya no podía acceder. Después de reiniciar, llevé a cabo una comprobación con fsck y me devolvió muchos errores, aunque cuando hice el chequeo con mi PC host no aparecieron errores. Una vez que arranco con normalidad, tuve que desinstalar y reiniciar Home Assistant en Docker. De momento puedo decir que no se está ejecutando de forma estable.
Referencias 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