neomanic

Apologies for posting an almost content-free post, but watching this progress along has me rather excited. The ESPRESSOBin board looks pretty much perfect for building a home gateway router with VPN, and it would be very tempting to replace my current Mac mini server for all media and file serving having had a look at OMV.

Yes, I have done the same and for similar reasons. I only use it for connecting my debug Ethernet adapter (main GBit one is to the network), as an attempt to test the OTG port using a flash drive caused a board lockup.

I've now made this change (set 'otg' to 'host' and removed the pinctrl lines) to my lime2 dts so I can have the extra USB port available, and am doing it as part of my custom image build. But given it's been a little while and a few kernel versions later, I was wondering whether there was any news on whether OTG mode works?

There was recently a discussion on an issue over on github dealing with an issue that popped up when building Armbian within a Docker container. Following on from there, it was decided that it would be a good idea to document the build process using Docker, and adding a howto, best practices, and FAQ to the main Armbian documentation. (I've put my hand up to coordinate this.) Using Docker is a good alternative to a VM, and particularly for anyone on macOS or Windows. So to kick off the thread, it'll be good just to discuss what should go into the docs. Also to see if anyone is interested in building with Docker and hasn't done so yet.

I've ordered 4 of the Zeros (2 for a friend). If the POE works well, they'll make great little access points.

Sorry, I missed this over the weekend when I was answering from home not work and across the forum and pull-request. Not sure if it's still of use to you, but here are the 384 MHz numbers:

I am using mainline, currently with 4.7.5 and latest Armbian 5.20. We have no need for the hardware support in legacy 3.4, so thought it best to go with mainline. I only have one NAND board here, and haven't even touched the NAND, just use SD for booting. The eMMC boards were released a few days after ordering it to start , which is why I don't just have all eMMC boards.

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?

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

All our Lime2-emmc boards are out in the field (and I'm about to deploy a fix to solve crashing due to DRAM settings too high), so I've been testing on a stock Lime2 (nand) board. We are ordering in more Lime2-emmc boards shortly and I will help test/solve this as well.

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.

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?

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. I will solve this even if it kills me...

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.

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.