Olinuxino A20 Lime 2 problems

[chradev]

If interested for monitoring tool take a look on my post:
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-3#entry7804

In my experience Armbian is the most stable and flexible as customization solution in given case.

You can use latest Linux kernel 4.5.1, Debian 8 (Jessie) with bunch of packets for them for your Lime2 board without NAND.

[ealex]

a quick test, board open air, nothing connected:

uptime
17:40:46 up  2:32,  1 user,  load average: 23.96, 22.11, 17.74


sudo echo temp &&  sudo i2cget -y 0 0x34 0x5E && sudo i2cget -y 0 0x34 0x5F && echo "vbat"  && sudo i2cget -y 0 0x34 0x78 && sudo i2cget -y 0 0x34 0x79 && echo "Iin" && sudo i2cget -y 0 0x34 0x58 && sudo i2cget -y 0 0x34 0x59
temp
0x70
0x0a
vbat
0xea
0x0e
Iin
0x26
0x07

uname -a
Linux testBoard 4.6.0-rc3 #2 SMP Sat Apr 16 14:45:13 UTC 2016 armv7l GNU/Linux
-- built on the board, used to test stability, pmic@34 node removed from the dtb file to leave the i2c bus accessible

=>
AXP209 temp: 35.5 deg
BAT voltage: 4.1338 ( got the charge stop point at 4.1V to extend battery life )
AC current: 384mA at 5V -> 1.921W dissipated on the board 

can not test GMAC as my router is only capable of 10/100MB

the board is in open air, i've been keeping it like this for more than 1 hour.

it seems it's able to survive a short overvoltage and the freeze problems are design related.

a thing to change - the resistor limiting the current to the green led is too large - it's barely visible in daylight.

another thing - bring out the RTC power supply so you can connect an ultracap:
- referring to schematic "A20-OLinuXino-Lime2_Rev_E.pdf"
- bring out pin 30 on APX209 - BACKUP
- add a 1F/5V to that pin
- configure AXP to charge the back-up cap in REG 35H to an appropriate voltage ( http://linux-sunxi.org/AXP209#REG_35H:_Spare_battery_charging_control )
- connect the VDD_RTC signal, ball K8 to the ultracap, use C118 or C119 as connection points

If A20's RTC section is designed as the other ARM chips i'm used to, it will not try to charge the RTC battery via that pin - this needs to be tested

@olimex consider leaving the BACK-up and VDD_RTC pins accessible on future boards, at least as some test-points - like you have for the power supply lines, it's a pain accessing them and for isolated systems they can be useful