Jump to content

Lime 2 goes to sleep/offline


cabsandy

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

This make sense?

 

root@A20-OLinuXino:~# 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.00223254 s, 22.0 MB/s
U-Boot
U-Boot SPL 2015.10-dirty (Jun 14 2016 - 16:28:35)
U-Boot 2015.10-dirty for sunxi b
root@A20-OLinuXino:~#

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:~#
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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... ;)

Link to comment
Share on other sites

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?  :angry:

Link to comment
Share on other sites

So how the hell did it ever get set to 480 in upstream?  :angry:

 

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/

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines