cabsandy Posted August 31, 2016 Posted August 31, 2016 Hi there Have purchased a Lime 2 device, as it offered GigE-which my Pi's dont :-) Loaded up both the vanilla and the normal distro's but both have this annoying habit of the device just goes to sleep-sometimes after a few hours. When I say sleep, I can still see the Ethernet LED's blinking away-but it wont respond to PING's, and it wont respond to SSH. Plugging in a monitor and keyboard doesn't bring it back to life either. If I power recycle it (2.5A unit being used-have tried the OTG and the 5vdc but no difference), up she comes. Fully updated in terms of packages. I have even set up a continuous ping to my home router from the Lime 2 (its on my internal LAN) to see of this would keep it up, but no luck. I've searched up on this, but nothing I find seems to make any difference. Before I send it back (UK reseller), anyone have any ideas on what I could try? Desperate for the thing to work, but as it would be in a remote location, no way can I use it if it decides to give up the ghost on a random basis! :-) cheers cabs
cabsandy Posted August 31, 2016 Author Posted August 31, 2016 Thanks for the reply-its the newest one as far as know Linux Lime02-01 3.4.112-sun7i #3 SMP PREEMPT Wed Aug 10 19:54:12 CEST 2016 armv7l GNU/Linux No eMMC on board cheers cabs
Igor Posted August 31, 2016 Posted August 31, 2016 There were some problems with some revisions of Lime 2 but I lost track of this problem - there were some debate on the forum, so search a little and/or try experimenting with changing u-boot - build it for Lime2 and Lime2-emmc. Both has different settings than downloadable image.
cabsandy Posted August 31, 2016 Author Posted August 31, 2016 Thanks for that-building images is a bit beyond me at the moment :-) so might be one for later I saw another thread where the CPU is changed from on-demand to performance-I have tried that, and put the device on monitor. I will see how it goes. cheers cabs
tricolery Posted September 3, 2016 Posted September 3, 2016 I have this same exact problem with cubieboard 2. The HDD that it's connected on its usb still spinning, the lan port leds are blinking and the red led from pmu is lit up, but the other two leds are turned off and I have no response from it. Tried to connect a monitor and a keybord but it did not work. This error occurs once/twice a week.
Igor Posted September 3, 2016 Posted September 3, 2016 I have this same exact problem with cubieboard 2. The HDD that it's connected on its usb still spinning, the lan port leds are blinking and the red led from pmu is lit up, but the other two leds are turned off and I have no response from it. Tried to connect a monitor and a keybord but it did not work. This error occurs once/twice a week. I suspect that this is due too setting memory frequency too high. Testing this takes some time ... It would help if you can setup a build environment and try different - lower speed values. Settings is defined in u-boot config.
cabsandy Posted September 5, 2016 Author Posted September 5, 2016 I bought an Odroid C2-its been rock solid since I bought it. No going to sleep, not having to mess about with other images, it.just.works. As do my Pi's, up for 30 days and more. So not sure if this is a hardware problem, or a software problem-but its getting the heave into Ebay. I've not got the time, nor the energy, to try and make someone else's experiment work. cheers cabs 1
neomanic Posted September 13, 2016 Posted September 13, 2016 There were some problems with some revisions of Lime 2 but I lost track of this problem - there were some debate on the forum, so search a little and/or try experimenting with changing u-boot - build it for Lime2 and Lime2-emmc. Both has different settings than downloadable image. Hi Igor, I have looked around at the u-boot differences. As far as I can tell, our boards are running at 384MHz DRAM speed. Are there other parameters in u-boot which may have an impact?
cabsandy Posted September 13, 2016 Author Posted September 13, 2016 So I found a spare bit of time, and dropped on the (basic?) Olimex Jessie image-guess what-its stable! https://www.olimex.com/wiki/A20-OLinuXino-LIME2#Linux So the Armbian image must be doing something the board doesn't like I guess cabs
tkaiser Posted September 13, 2016 Posted September 13, 2016 So the Armbian image must be doing something the board doesn't like I guess Armbian uses mainline u-boot (DRAM clockspeed set to 480 MHz for no apparent reason other than claims by the vendor's CEO that Lime2 can use even 532 MHz) and I would assume Olimex' OS image clocks with just 384 MHz? Can you provide a boot log with serial console attached to see which u-boot version is used? And provide the contents of the fex file also? Some background information: http://forum.armbian.com/index.php/topic/1853-rfc-images-for-new-boards/?p=14246
cabsandy Posted September 13, 2016 Author Posted September 13, 2016 Hi Sorry-dont have a serial console-can do SSH if you tell me the command/log/statement you want
tkaiser Posted September 13, 2016 Posted September 13, 2016 Sorry-dont have a serial console-can do SSH if you tell me the command/log/statement you want U-Boot version can be read out by dumping the first 48KB of the SD card: dd if=/dev/mmcblk0 bs=48K count=1 | strings | grep -i "U-Boot" And if it's an old u-boot then DRAM clockspeed defined in the fex file will be used. No idea where on Olimex' images script.bin is located and whether they've already bin2fex available (might need an 'apt-get install sunxi-tools'). But then it's a bin2fex /boot/script.bin | grep dram_clk
cabsandy Posted September 13, 2016 Author Posted September 13, 2016 This make sense? root@A20-OLinuXino:~# dd if=/dev/mmcblk0 bs=48K count=1 | strings | grep -i "U-Boot"1+0 records in1+0 records out49152 bytes (49 kB) copied, 0.00223254 s, 22.0 MB/sU-BootU-Boot SPL 2015.10-dirty (Jun 14 2016 - 16:28:35)U-Boot 2015.10-dirty for sunxi broot@A20-OLinuXino:~#
tkaiser Posted September 13, 2016 Posted September 13, 2016 U-Boot SPL 2015.10-dirty (Jun 14 2016 - 16:28:35) That would mean an older mainline u-boot is used and AFAIK there also 480 MHz are used. Maybe it's worth a try to test also with 15.10 u-boot instead.
zador.blood.stained Posted September 13, 2016 Posted September 13, 2016 That would mean an older mainline u-boot is used and AFAIK there also 480 MHz are used. Maybe it's worth a try to test also with 15.10 u-boot instead. IMO the only thing worth a try is bisecting u-boot to find out what change affects stability (if this wasn't done before, I can't remember), but for it we need a Lime2 board, a quick reliable way to reproduce the problem (like lima-memtester or linpack) and some experience in working with git and compilation.
neomanic Posted September 22, 2016 Posted September 22, 2016 Hey everyone, I am VERY keen to solve this. (Originally I thought it was because the external SSD was pulling too much power on occasion, but that's definitely been ruled out now.) I can reliably make the system hang within 20 minutes by running the following: sysbench --test=cpu --cpu-max-prime=2000000000000000000 --num-threads=2 run # file i/o test on a mounted USB flash drive sysbench --test=fileio --file-test-mode=rndrw --max-time=86400 --max-requests=0 run I've gone back from my custom build to the stock Armbian 5.20, and tried with both Xenial and Jessie, mainline and legacy. Same result regardless. So, I just now moved on to checking u-boot version and DRAM speed. root@lime2:~# dd if=/dev/mmcblk0 bs=48K count=1 | strings | grep -i "U-Boot" 1+0 records in 1+0 records out 49152 bytes (49 kB) copied, 0.00686708 s, 7.2 MB/s U-Boot U-Boot SPL 2016.09-armbian (Sep 15 2016 - 03:51:47) U-Boot 2016.09-armbian for sunxi root@lime2:~# bin2fex /boot/script.bin | grep dram_clk fexc-bin: /boot/script.bin: version: 0.1.2 fexc-bin: /boot/script.bin: size: 53480 (89 sections) dram_clk = 384 I'm pretty stumped, only think I can think of is reducing the DRAM further. I can certainly build a custom version to test things, but wondering if there are other suggestions. I will try the Olimex image right now.
cabsandy Posted September 22, 2016 Author Posted September 22, 2016 Moved over to the "offical" Olimex release-A20 has been rock solid for nearly 10 days. Make your own mind up on what you want your box to run on!! root@A20-OLinuXino:~# uptime 19:57:54 up 9 days, 18:41, 2 users, load average: 1.00, 1.01, 1.05 root@A20-OLinuXino:~# uname -a Linux A20-OLinuXino 3.4.103-00033-g9a1cd03-dirty #29 SMP PREEMPT Tue Apr 5 08:21:20 EEST 2016 armv7l GNU/Linux root@A20-OLinuXino:~#
neomanic Posted September 22, 2016 Posted September 22, 2016 Olimex image is looking promising, it's been running for 2 hours now with no crash. I'll be leaving it running over the weekend to verify.
tkaiser Posted September 22, 2016 Posted September 22, 2016 I'm pretty stumped, only think I can think of is reducing the DRAM further. I can certainly build a custom version to test things, but wondering if there are other suggestions. With mainline u-boot on A20 DRAM clockspeed is only defined there and fex settings are ignored. I've no idea why Armbian still uses the 'default' 480 MHz. We asked one professional user to test through different DRAM clockspeeds, I even prepared different u-boot .debs to test. This was 5 weeks ago and we never heard anything since then: http://forum.armbian.com/index.php/topic/1853-rfc-images-for-new-boards/?p=14275 Still I don't understand why we allow to let any A20 board run with these moronic 480 MHz. But that's obviously just me. In case you want to give Olimex' u-boot version a try use our build system and set in userpatches/lib.config BOOTBRANCH="tag:v2015.10" I will stop now looking into Lime2 at all. 1
tkaiser Posted September 22, 2016 Posted September 22, 2016 FYI: root@lime2:~# dd if=/dev/mmcblk0 bs=48K count=1 | strings | grep -i "U-Boot" 1+0 records in 1+0 records out 49152 bytes (49 kB, 48 KiB) copied, 0.00118619 s, 41.4 MB/s U-Boot U-Boot SPL 2016.05-armbian (Jul 14 2016 - 17:48:17) U-Boot 2016.05-armbian for sunxi root@lime2:~# uptime 08:12:55 up 63 days, 13:43, 1 user, load average: 0.34, 0.17, 0.11 The date looks like it's a build I did myself, no idea whether I lowered DRAM clockspeeds or not. I did an 48 hours burn-in test back then and moved it to a hosting location. Up and running as usual. In other words: yes, there's something wrong with current settings Armbian uses. Yes, it's easy to adjust settings if we would be able to get a clue what's going on. Yes, with Olimex own image there seems to be no problem since they use different settings and don't update their images ever again (3.4.103 -- good luck folks!) Yes, everything will remain the same since no progress can be made. 1
cabsandy Posted September 22, 2016 Author Posted September 22, 2016 My A20 is just sitting here, stable but not doing much. The work I envisaged for it, I got a Odroid64 instead. I keep on seeing clock speed mentioned, I am not a Linux expert by any manner of means and the only thing I can reference this to, is where I change the speed of my Raspberry Pi's in raspi-config. It is pretty easy to do. If there is something different I can change, to see if it helps in troublshooting, I am happy to do-as long as its simple and not time consuming. cheers cabs
neomanic Posted September 27, 2016 Posted September 27, 2016 tkaiser! Thank you for your patience. I had the Olimex image running for 5 days with a full CPU and file IO workout, so I'm satisfied that this is an issue that can be solved, as obviously you have done with your own build. I am now trying for my own build of u-boot. Yes, everything will remain the same since no progress can be made. I will solve this even if it kills me...
neomanic Posted September 28, 2016 Posted September 28, 2016 U-boot with DRAM at 384 MHz has been running stable under full load for 2 hours now, which means it's looking pretty good. Will report again in a few days. Do you like flowers, tkaiser?
neomanic Posted September 30, 2016 Posted September 30, 2016 Okay, running for 48 hours now without a glitch. I'm considering this solved. I've submitted a pull request to Igor on github Armbian to patch both Lime2 and Lime2-emmc boards to 384 MHz.
tricolery Posted September 30, 2016 Posted September 30, 2016 What file do I change the DRAM speed? I will test 384MHz on my cubieboard 2 too. I know how to compile U-Boot.
neomanic Posted September 30, 2016 Posted September 30, 2016 Igor's merged my pull request, that will show you the files if you want to edit manually. https://github.com/igorpecovnik/lib/commit/9803e802f00782e433f78e72ad8de9d531a54c84 https://github.com/igorpecovnik/lib/pull/481
neomanic Posted September 30, 2016 Posted September 30, 2016 I did a little more research too, because I'm going to try to get these patches pushed to u-boot upstream. In the process, I found that Olimex recommends in their documentation to change it too, see https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-2/BUILD_DESCRIPTION_A20_Olimex_kernel_3.4.103%2B_Jessie_rel_2.txtline 96. So how the hell did it ever get set to 480 in upstream?
tricolery Posted September 30, 2016 Posted September 30, 2016 I'm cloning the u-boot-source from https://github.com/linux-sunxi/u-boot-sunxi(sunxi branch) and I have no Idea where I need to change the clock value. Tried to read the documentation, but without success. Could anyone help me? Thank you!
tkaiser Posted September 30, 2016 Posted September 30, 2016 So how the hell did it ever get set to 480 in upstream? Well, there was the claim Lime2 would be capable of 532 MHz, then someone at Olimex realized that the max value is 480 MHz, so they submitted that upstream while their own OS images all the time used 384 MHz (the old ones relies on BSP u-boot where DRAM clockspeed was read from fex file where it remained 384 MHz all the time and when they switched to mainline u-boot a while ago they chose u-boot 2015.10 where default is 480 MHz but chose to adjust that on the fly and write this now also in their instructions). So the whole issue is a value provided by the hardware vendor upstream that is known to not work reliably and being avoided by the same hardware vendor. Not that great... In case anyone wants to give this a try please read through the PR's comments and start to use the approriate tools (lima-memtester). @tricolery: please forget about u-boot-sunxi, you need mainline u-boot and a patch in userpatches dir like the one @neomatic used for Lime2. This explains everything but is outdated (don't use 14.04 as build host any more!): http://docs.armbian.com/Developer-Guide_Build-Preparation/
Recommended Posts