Hi Igor and all,

 

after running armbian on my A20 lime2 for a long time, I decided to switch to armbian on my A10 lime, too (from jessie with a eewiki-based self-compiled kernel). So far it works as perfect as the A20, but there are two small and funny things with the

 

Armbian_5.00_Lime-a10_Debian_jessie_3.4.110.zip

 

image I used:

 

After login the nice armbian banner stated that my A10 lime is a cubieboard . I have a cubieboard, too. So I double checked...

 

The problem is located in /etc/init.d/armhwinfo, There all "sun4i" boards are simply "Cubieboard". I had to adapt the LED check which is

used to detect Lime and Lime2 a bit and added the Lime A10. I checked the LEDs path on my cubian based cubieboard 1 and it

was different, so hopefully the LED check correctly detects the Lime A10.

 

During test (restarting service armhwinfo) I saw that the detected ID is appended to /var/run/machine.id. I had a funny banner with Cubieboard and 2 times Lime A10 .

 

Here is what I changed finally:

--- armhwinfo.org	2016-02-11 23:58:47.000000000 +0100
+++ armhwinfo	2016-04-07 12:17:16.848138250 +0200
@@ -17,6 +17,8 @@
 HARDWARE=$(cat /proc/cpuinfo | grep Hardware | awk '{print $3}')
 GMAC=$(dmesg | grep "sun6i_gmac")
 LEDS=$(dmesg |grep "green:ph02:led1")
+# a10 lime
+LEDS2=$(dmesg |grep "green:ph2:led1")
 TERMINUS=$(lsusb  | grep "1a40:0101")
 SWITCH=$(dmesg | grep "BCM53125")
 INTERUPT=$(cat /proc/interrupts | grep "eth0")
@@ -55,8 +57,12 @@
 		ID="Orange H3"
     fi
     if [ $HARDWARE = "sun4i" ] || [ $HARDWARE = "Allwinner" ]; then
+	if [ "$LEDS2" != "" ]; then
+		ID="Lime A10"
+	else
 		ID="Cubieboard"
 	fi
+    fi
     if [ $HARDWARE = "sun7i" ] || [ $HARDWARE = "Allwinner" ]; then
         # redistribute irq to dedicated core
 		if [ "$INTERUPT" != "" ] && [ "$CORES" -gt 1 ]; then
@@ -115,7 +121,7 @@
 if [[ $MACHINE == *M2* ]]; then ID="Banana M2"; fi
 
 echo -e "[\e[0;32m ok \x1B[0m] Starting ARM hardware info: $ID"
-echo $ID  >> /var/run/machine.id
+echo $ID  > /var/run/machine.id
 ;;
 stop|reload|restart|force-reload|status)
 echo -e "[\e[0;32m ok \x1B[0m] Stopping ARM hardware info ..."

The second issue was an (compared to the A20) incredibly high temperature: 72,2.

I checked /etc/update-motd.d/30-sysinfo and found out that although it is commented as "only on A20", the a20-tp-hwmon reading

is available at the A10 lime, too. Whatever this value is, the correct temperature seems to be at i2c. I got a 37,8 there.

 

So I commented out the A20 temp reading, but this is surely just a quick hack...

--- 30-sysinfo.org	2016-02-11 23:58:47.000000000 +0100
+++ 30-sysinfo	2016-04-06 23:06:55.713259579 +0200
@@ -106,9 +106,9 @@
 fi
 
 # if we are reading from A20
-if [ -d "/sys/devices/platform/a20-tp-hwmon/" ]; then
-	board_temp=$(cat /sys/devices/platform/a20-tp-hwmon/temp1_input | awk '{printf("%d",$1/1000)}')
-fi
+#if [ -d "/sys/devices/platform/a20-tp-hwmon/" ]; then
+#	board_temp=$(cat /sys/devices/platform/a20-tp-hwmon/temp1_input | awk '{printf("%d",$1/1000)}')
+#fi
 
 # where it should be
 if [ -d "/sys/devices/virtual/thermal/thermal_zone0/" ]; then

Finally I want to send you a big thank you for providing armbian!

 

Bye,

wahlm

 

This auto detection is giving us headaches lately It's a dirty approach and gives incorrect results sometime. Since boards and board clones, which are almost impossible to distinguish, are piling up, we need to completely redesign this feature.

 

Thanks, twice 

Hello,

 

I also have a Lime-A10, but reading from the I2C is also exactly 37,8 from my board, what ever I do. But the a20-tp-hwmon gives me a range between 63~66 depending if I press my thumb on the A10 CPU. Actualy it goes from 66 to 62 when it gets warmer .

 

I don't know if Igor can answer this, but the temperature problem is a A10/A20 problem in general isn't it?

 

regards

I also have a Lime-A10, but reading from the I2C is also exactly 37,8 from my board, what ever I do. But the a20-tp-hwmon gives me a range between 63~66 depending if I press my thumb on the A10 CPU. Actualy it goes from 66 to 62 when it gets warmer .

 

With I2C you might be able to readout the thermal sensor inside the AXP209 PMU (better choice). Regarding A10/A13/A20 SoCs the thermal sensor inside is there more by accident than by design, needs different calculations/curves/calibration, is known to be off and should not be trusted at all.

 

http://forum.armbian.com/index.php/topic/155-testers-wanted-sunxi-adjustments-for-rpi-monitor/?p=967  (see post #13 there)

 

These thermal readouts are for people that love staring at numbers without meaning