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.

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?

Okay, so we are now are having the same issues with 5 separate Lime2-eMMC rev E boards, which are running SSDs, batteries (to allow for clean shutdown), 2x USB devices and Ethernet. Running recent Armbian, mainline kernel. Changing the CPU governor via cpufrequtils really reduced the number of hangs (from daily), but we are still getting them sporadically, perhaps once a week. We have set the watchdog timer on, so when the board does hang then it reinitialises itself and is back online within 60 seconds. But obviously this is an issue we would like to address. Our next step, assuming that no-one has other suggestions, is to try a legacy kernel.

I have 5 Lime2-emmc boards sitting on my desk (for future installs), and I can run DRAM tests on them next week. I'm running mainline, and was pretty sure that the RAM speed was set to 384 MHz, but will double-check my u-boot compile. Having a varying cpufreq definitely caused crashes, so I've locked it at 960 MHz. I will do what @chradev suggests; stress, iperf and RPi monitor, but if anyone has a preferred option, I'm all ears.

We have 2x lime2-emmc boards in production now. We were having random hangs on both, and fortunately I remembered this thread. Changing the cpufreq settings such that it was locked at 960 MHz has solved the issue. We're still getting a hang once a day but only on one of the lime2s, so it's likely to be a separate issue. Fortunately, having the hardware watchdog timer set up to reboot the system means that it doesn't cause any major problems.

I had the same issue today. It's not something I have to worry about since my application doesn't care about hotplug, but perhaps this will help you? http://askubuntu.com/questions/575487/network-eth0-dhcp-static-ip-and-autonegotiation-issues

We use miniterm.py which is included with pyserial for Python.

I too am running docker installed direct from the stock repositories. Running Armbian 5.15 Xenial on a lime2-emmc. Next step is to also get aufs running. Now that we are able to do it directly from stock, are there any advantages to using the hypriot builds and repositories? I am building our Docker base images on a development machine and copying them over, since the build size is a little too big+intense to do on the emmc (final image is 700+ MB). But our actual application image can be built on top of the base image fine, since it is only a few file copies. (We are running from SSD in production, the emmc is just for failsafe.) docker info/version:

Yes, thank you @Zador! That answers my question. @chradev: thank you for the answers. Re: my question, it was about your system which you answered via PM.

Thank you for your work on this, as per my comments in the customisation and 'debian on lime2-emmc' threads. I have my system up and working the way I like it, but it is not automated in the fashion you are doing here... I would very much like it to be, but it is low on my priority list as we have to deploy this hardware very soon. Hopefully after that I can be more useful, but I am only just now getting back to embedded Linux for the first time since 2007. Back to the matter at hand. I have a few questions for my own understanding. The u-boot and kernel patches are the same as the ones in the current Armbian release, correct? Is there a reason why the lime2-emmc hasn't been defined as a separate board so we can eventually have it mainlined? With the boot order patch, why do it this way rather than customising the boot.cmd? FYI, I changed my boot.cmd to the following which boots from the SATA drive if found, if not then continues with the eMMC. If a bootable SD card is inserted, it overrides both of them. I see that your boot script is more robust because it tries loading the kernel image, fdt, and initramfs and falls over to another boot device if those fail, whereas mine will require hardware removal if those fail. I will be changing mine to be more like yours in that regard. boot.cmd (p.s. what does that setup control? Looks very nice.)

Hi all, I see that this is a recent thread and seems a good place to ask a similar question relating to getting Armbian on the Lime2-eMMC, which I have been attempting to do for a few days now. I have read through the related threads (the armbian-customization thread, plus the ones pertaining to the other boards), and this seems a good location to document my complete efforts to get it working for other newbies. The last attempt using nand-sata-install failed with a complete failure to boot, not even loading u-boot, so I set that aside for the moment and will come back to it shortly. But the alternative I've successfully got to boot is: Build Armbian with the emmc-compatible patches. cp lib/patch/kernel/sunxi-next/add-emmc-lime2.patch.disabled userpatches/kernel/sunxi-next/add-emmc-lime2.patch cp lib/patch/u-boot/u-boot-next/add-emmc-lime2.patch.disabled userpatches/u-boot/u-boot-next/add-emmc-lime2.patch ./compile.sh BOARD=lime2 BRANCH=next RELEASE=xenial KERNEL_ONLY=no PROGRESS_DISPLAY=plain Copy to SD card and boot from it. Check that the eMMC is detected. root@lime2:~# dmesg | grep mmc [ 0.000000] Kernel command line: console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1 [ 3.819355] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 3.852205] sunxi-mmc 1c0f000.mmc: base:0xf08dc000 irq:26 [ 3.888722] mmc0: host does not support reading read-only switch, assuming write-enable [ 3.891047] mmc0: new high speed SDHC card at address 0001 [ 3.891983] mmcblk0: mmc0:0001 00000 29.8 GiB [ 3.892012] sunxi-mmc 1c11000.mmc: base:0xf08f2000 irq:27 [ 3.893690] mmcblk0: p1 [ 3.905611] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !! [ 3.910023] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !! [ 3.910928] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !! [ 3.911820] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !! [ 3.912710] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !! [ 3.951649] mmc1: new DDR MMC card at address 0001 [ 3.952681] mmcblk1: mmc1:0001 P1XXXX 3.60 GiB [ 3.953090] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB [ 3.953463] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB [ 3.954724] mmcblk1: p1 [ 6.193692] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 7.618451] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro We have both mmcblk0 and mmcblk1, so the eMMC is detected. (Output might look a little different, the above is with the eMMC already partitioned.) Copy over the same .raw image used for the SD card to the running system and dd it to the eMMC. Now the problem I had with booting directly is that the rootfs is set to be /dev/mmcblk0 but the eMMC enumerates as mmcblk1, so the boot fails. We can set the rootfs by partition uuid instead. Mount the eMMC, then look at the block device ids. dd bs=1M if=Armbian_5.15_Lime2_Ubuntu_xenial_4.6.3.raw of=/dev/mmcblk1 mkdir -p /mnt/emmc mount /dev/mmcblk1p1 /mnt/emmc root@lime2:/mnt/emmc/boot# blkid /dev/mmcblk0p1: UUID="4b73aadb-b2ef-49c9-b539-503ee3fe99be" TYPE="ext4" PARTUUID="e9b1e023-01" /dev/mmcblk1p1: UUID="4b73aadb-b2ef-49c9-b539-503ee3fe99be" TYPE="ext4" PARTUUID="e9b1e023-01" /dev/mmcblk0: PTUUID="e9b1e023" PTTYPE="dos" /dev/mmcblk1: PTUUID="e9b1e023" PTTYPE="dos" Note the two device uuids and partition uuids are the same since they've been dd-ed from the same raw image. Edit the boot script on the eMMC and change the root= kernel parameter from the mmcblk device to be the partition uuid from above, i.e.: cd /mnt/emmc/boot mv boot.cmd boot-old.cmd sed 's_root=/dev/mmcblk0p1_root=PARTUUID=e9b1e023-01_' <boot-old.cmd >boot.cmd mkimage -C none -A arm -T script -d boot.cmd boot.scr Now shutdown, pop out the SD card, power back up and you should be booting from the eMMC. As said above, the SD card and eMMC have the same partition ids, which isn't great. But it doesn't affect the boot process, because the system will always boot from the SD card if it's present. I will have a closer look at the sata-nand-install script now and see why that's failing.