Olimex A20-OLinuXino-LIME2 – 8 years in service, 2 PSUs and 1 SD-card down

4 years ago I posted a 4 year review of the Olimex LIME2. It seems that the lifetime of power supplies is approximately 4 years as now another power supply died, and this time also the SD-card was expiring. The LIME2 lives on however!

It was a bit hard to notice, because the battery pack of the LIME2 kept it running pretty well even with the poor power supply. So, better monitoring of the battery pack is also on the todo list.

Recovering the bad SD-card

Recovering the SD-card was relatively easy with minimal dataloss, when out of the LIME2:

$ sudo ddrescue /dev/mmcblk0 backup.img
# Put in a new SD-card
$ sudo dd if=backup.img of=/dev/mmcblk0 bs=16M

I have done this a couple of times with other SD-cards from Raspberry PIs, and though there is the potential for dataloss it is usually minimal. This time a few blocks were lost.

Upgrading Debian from Stretch to Bullseye

I took the opportunity to upgrade the Debian install while the system was offline anyway. Upgrading was generally painless, following the usual Debian method. I went through the Buster release just to be sure:

$ vim /etc/apt/sources.list
# replace all "stretch" with "buster" :%s/stretch/buster
$ apt update && apt upgrade && apt full-upgrade
$ reboot

$ vim /etc/apt/sources.list
# replace all "buster" with "bullseye" :%s/buster/bullseye
$ apt update && apt upgrade && apt full-upgrade
$ reboot

The only tricky part is booting the new kernel. Since that always fails for me on the first try, I always hookup the serial console. For future reference, this is how to hookup the serial console (which is TTL 3.3V):

Now, of course the boot failed. I tried getting the flash-kernel package to work for my setup, but for historical reasons I have a separate boot partition. In the end I derived a simple bootscript from that package, that boots from p1 but loads the kernel, fdt and initrd from p2:

setenv bootargs  ${bootargs} console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10

#setenv fk_kvers '4.19.0-21-armmp-lpae'
setenv fk_kvers '5.10.0-18-armmp-lpae'
setenv fdtpath dtb-${fk_kvers}

load mmc 0:2 ${kernel_addr_r} /boot/vmlinuz-${fk_kvers}
load mmc 0:2 ${fdt_addr_r} /boot/${fdtpath}
load mmc 0:2 ${ramdisk_addr_r} /boot/initrd.img-${fk_kvers}
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

The script can be manually input over the serial terminal, and thereby tested out.

The only downside is it needs to be manually updated after each kernel upgrade. To activate the uboot bootscript:

$ mount /dev/mmcblk0p1 /mnt/
$ cd /mnt
# ensure boot.cmd is as above
$ mkimage -C none -A arm -T script -d boot.cmd boot.scr

Monitoring the LIME2 battery pack

After upgrading to a recent 5.X mainline Linux kernel the battery pack is exposed in the sysfs filesystem:

$ cat /sys/class/power_supply/axp20x-battery/voltage_now 
4070000 # 4.07 V
$ cat /sys/class/power_supply/axp20x-ac/voltage_now 
4933000 # 4.93 V

I setup a couple of alerting rules for these in my home monitoring setup, so hopefully the next time the LIME2 defeats a power supply I’ll get notified.

Conclusion

I can still warmly recommend the LIME2. It is still available, and even a bit cheaper nowadays at 40 EUR + VAT, and still a little workhorse that just keeps on going.

Olimex A20-OLinuXino-LIME2 – A review after 4 years in service

Last week my A20-OLinuXino-LIME2 one board Linux computer quit working, with a power supply issue. I looked up when it was purchased, and realised it had been in 24/7 service for almost 4 years. I guess that is a good excuse to do a little review. It even turned out that it the board was fine, but the AC-DC power supply brick could not supply enough current anymore.

The relevant specifications of the board, for my uses, are basically:

• Dual core 1 GHz ARM Cortex-A7
• 1 GB memory, 1 Gbit ethernet, SATA connector
• LiPo battery connector/charger for UPS functionality

The Lime2 has been tasked with running my home monitoring system, consisting of a Debian installation with a Graphite backend, a Grafana frontend, and a ZoneMinder installation. The Graphite database is running on a software RAID0 of two disks (one on SATA, one on USB): in the beginning it was two spinning disks, but after a few years the random 2.5″ laptop disk I was using crapped out, so it was upgraded to a Samsung SSD. The power budget is strained more or less to the max with two spinning harddrives: The system was only able to boot if the battery was connected, presumably because the voltage would otherwise drop for the startup torque. This problem went away after switching to a SSD.

Software wise the system started out with the Debian supplied by Olimex on a SD-card, a Debian pre-Jessie with a custom SunXi kernel. This system was reasonable, but did experience random hangs after some time of use (I belive I found a bugreport back in the day, but am unable to refind it now). The system was later upgraded to a Debian Stretch with a 4.9 kernel from stretch-backports, that supports the SunXi chipset enough for my uses. The upgrade was rather involved,  requiring the correct kernel image, a custom U-boot script and the correct device tree file. Something did of course go wrong, at which point I got to be familiar with the serial console of the Lime2: there is a convenient 3 pin header, that gives access to a TTL serial. Using the serial console, I was able to identify the mistake and correct it. After the upgrade the system has been rock-stable.

The system has been handling the load reasonably: The 1GB of memory is constraining, there is not really any more free memory. The processor is only really strained by the motion detection in ZoneMinder, which uses more or less one core per camera. This will hopefully be optimized a bit, as ZoneMinder is being optimized for the ARM instruction set. Handling only the Graphite/Grafana load would be a breeze, even though the system is receiving ~650 metrics per minute.

All in all, I can recommend the Lime2 board for applications that need a little more umph than a Raspberry Pi, notably on the SATA and Ethernet side, and/or applications that need to be continuously available even after the power cuts out. For applications that need more than one SATA port, or more than one Ethernet port, or on-board Wifi, there are better — and more expensive — options. The price point of 45 EUR + VAT (which did not change from 4 years ago) puts the Lime2 slightly above the price of a RaspberryPi or BananaPi, but below boards like the Apu2. In addition, Olimex has announced that the Lime2 will be available “forever”, making any system designed using the Lime2 future proof — for the foreseeable future.

I ordered a new Lime2, before realising the problem was the power supply. I opted for the industrial variant that is now available. The only change, as far as I’m aware, is that the Allwinner A20 chip is rated for a larger temperature range, and it is 5 EUR more expensive.