manuti

You can install directly using armbian-config.
sudo armbian-config Last entry on the first menu "Softy"

 
And inside this menu mark "Syncthing"
 

 
* Sorry but the snapshots are partly in Spanish.

@tkaiser: thank you very much for your help. I was able to track down the bug. Contrary to first belief, the kernel is not concerned, but in h3disp on line 196 the pll_video is initialized to 646 MHz. With kernels divisor of 4 this results in pixel frequency of 161.5 MHz, which is too high for Vesa 1280*1024.
So I  replaced this initialization with 432 MHz, which results in correct fD of 108 MHz. Now the monitor synchronizes.
Unfortunately I found a bugfix by @igor on 24.Oct.2016 which inserted the 646 MHz value. I could not read the reasoning behind this (facebook srsly?), so I would kindly ask to revert this change if no important reasons for it exist.
 
best wishes and thanks to armbian team for your great work!
gnasch

And this is a BeelinX2 using internal memory (nobody ask, but I like H3 SoC) and Legacy Desktop armbian:
manuti@beelinkx2:~$ 7za b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 1000 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1379 301 445 1342 | 35621 393 816 3213 23: 1378 308 455 1404 | 34656 388 816 3171 24: 1354 317 459 1456 | 34350 391 815 3186 25: 1069 272 449 1221 | 31443 365 809 2956 ---------------------------------------------------------------- Avr: 300 452 1356 384 814 3132 Tot: 342 633 2244  

I am running Opi Prime on stock settings, built from sources one hour ago ... which numbers should be better? I ran again and it stays in the same range.
 
2 x E5-2683

H5 board with gigabit:
https://www.armbian.com/orange-pi-prime/
https://www.armbian.com/nanopi-neo-2 + http://www.friendlyarm.com/index.php?route=product/product&product_id=184

Why do we waste our time with this board (which will most likely be the same shit show as M2+ was/is -- at least that's the device I lost most time with due to vendor even too stupid to provide correct schematic).
 
Why not spending our time on improving things with other boards or Armbian in general (Wi-Fi firmware situation, refactoring to deal better with more and more boards and installation variants, preparing Debian Stretch and so on)?

ya ill try to tidy things up and send a PR.

theres a few weird things like the interface is literally called wan from the device tree perspective rather than eth0... perhaps because of the topaz switch being in the middle of it. i have a few other questions i need to post. Should i start a more topic appropriate thread elsewhere?

Sent from my SM-G920V using Tapatalk

I think i answer myself
 
I am to stupid to do it like i want, with python. But, shell scripts work everywhere an i understand it in most cases. So, here is an solution for my Problem.
 
I use PIN 18, which Linux GPIO is 201. I pot a pullup resistor (10kOhm) to PIN 17 - 3,3V.
After this, i configure the PIN18.
echo 201 > /sys/class/gpio/export echo "in" > /sys/class/gpio/gpio201/direction Now i can check the value

 
cat /sys/class/gpio/gpio201/value The answer should be 1.
If now the PIN18 is shorted to PIN 20 (GND), the answer is 0.

A little script does it for me:
#!/bin/sh BUTTON=201 # shutdown button echo "$BUTTON" > /sys/class/gpio/export echo "in" > /sys/class/gpio/gpio$BUTTON/direction while true ; do   data=`cat /sys/class/gpio/gpio$BUTTON/value`   if [ "$data" -eq "0" ] ; then     shutdown -h now   else     cnt=0 fi   done
 
 
 
 

I'm writing this post from Orange Pi Zero 2+ H3 so it works
I downloaded the desktop image from "other download options and archive"
In my opinion the  Ubuntu desktop – legacy kernel can be added to the "Orange Pi Zero 2+ H3" download page
During the installation I had only one problem with USB OTG - I will describe it in detail in separate thread.
PS
I'm traing to switch the device in my project from OPiPC+ to PPiZero2+H3(because of the bluetooth and small size) I will share the experiences.
Thanks again @Igor the Armbian is awesome!

I want to use a shutdown button to make a secure shutdown with the nanopi neo air. But i am completly lost how it works. I don't find out, which GPIO's i can use for a script.  And if i need a puuldown or not.
Can somebody help me?
 
Thanks 
Chris

... or not. Again, it's a benchmark. It doesn't necessarily hit the bottleneck in the system it was designed to measure, it doesn't tell you where the bottleneck is that is responsible for the numbers you are getting and it doesn't take all the factors into account.
 
Well, results in this thread show some numbers related to the I/O performance, nothing more.
If you wanted to really compare filesystems and not underlying storage, you would need to test a lot of other things:
CPU utilization by the FS driver in different scenarios memory utilization by the FS driver in different scenarios storage space overhead for the internal FS data comparison of available FS tweaks that may affect 3 previous points and for the "scenarios" you may wanted to test
creating a large number of files and directories removing a large number of files and directories renaming or changing metadata for the large number of files and directories appending or removing data in existing files traversing a large directory tree  
So in the end if I/O performance numbers do not differ very much it doesn't mean that filesystems will show similar performance results in different real world scenarios not related to reading or writing files

From left to right: Good, average and crap. The numbers combined below:
Good Average Crap F2FS EXT4 F2FS EXT4 F2FS EXT4 iozone 4K random write IOPS 746 764 208 196 38 33 iozone 4K random read IOPS 1616 1568 1806 1842 1454 1461 iozone 1MB sequential write KB/s 20354 21988 7161 10318 8644 9506 iozone 1MB sequential read KB/s 22474 22548 22429 22476 15638 14834 ioping k iops 1.57 1.55 1.42 1.31 1.06 1.19 fio write iops 311 399 128 132 31 28 fio read iops 934 1197 384 395 93 85 OMV installation time in sec 862 791 886 943 3729 1480 If I look at these numbers I immediately stop thinking about filesystems but start to focus on hardware instead. Obviously avoiding crappy cards and choosing good or at least average ones helps a lot with performance.
 
Interestingly such a task like OMV installation that does a lot of disk IO is somewhat affected by storage (random) performance but not that much. Installation duration with good and average SD card are more or less the same. Then we should keep in mind when looking at sequential speeds that most if not all SBC currently are limited to ~23MB/s here anyway (ASUS Tinkerboard one of the rare exceptions). So it's useless to get a SD card rated for 90MB/s since it will be bottlenecked by the interface anyway.
 
Still random IO performance seems to be the most interesting number to focus on and I would assume those cards showing best performance/price ratio are still Samsung's EVO/EVO+ with 32GB or 64GB (can't test right now since all Samsung I own are busy in installations).
 
One final word regarding F2FS 'real-world' performance. This filesystem comes from an Android vendor and maybe situation with Android where apps constantly issue fsync calls is really different compared to ext4. But for our uses cases this doesn't matter that much (especially having in mind that Armbian ships with ext4 defaults that try to minimize writes to SD card -- for some details regarding this you might want to read through article and especially comments here: http://tech.scargill.net/a-question-of-lifespan/)

Since I've been asked recently why Armbian doesn't ship with F2FS by default I thought let's have a look again what to gain from F2FS (a filesystem specially designed for use with flash media by Samsung few years ago). For a history of F2FS discussion please use the search function: https://forum.armbian.com/index.php?/search/&q=f2fs
 
Armbian fully supports F2FS partitions for a long time now but we don't provide OS images with F2FS for a couple of reasons:
 
F2FS still doesn't support resizing so our default installation variant (ship with a minimized rootfs that gets resized on first boot automagically to the size of SD card / eMMC) wouldn't work F2FS requires a pretty recent kernel and is therefore not an option for default images (since most of downloads use legacy kernel) Unfortunately those installations that would benefit the most from faster random IO (writes) are those using the kernels most outdated (Allwinner A20/H3 who are used by many people as 'desktop linux' where performance heavily depends on fast random writes)  
To use F2FS with Armbian you need to choose a SoC family that is supported by mainline kernel (or at least 4.4 LTS) and then build an image yourself using these options (choosing $FIXED_IMAGE_SIZE to be less than the capacity of the final installation media!)
ROOTFS_TYPE=f2fs FIXED_IMAGE_SIZE=n In the past I tested through this many times and all my tests didn't show that great performance improvements would justify another installation variant but... let's have a look again and focus on the claims first. F2FS has been invented to solve certain problems with flash based media and promises better performance and higher longevity. At least measuring the latter is somewhat questionable but performance can be tested. So I decided to pick 3 different SD cards that represent roughly the kind of flash media people out there use:
 
Crap: An Intenso 4GB Class 4 SD card Average: A random SanDisk 8GB card Superiour: An expensive SanDisk Extreme Plus with 16GB  
For the tests I used an OrangePi One with kernel 4.10 and a Debian Jessie variant to be able to use a scripted OpenMediaVault installation as some sort of a real-world benchmark (the script is roughly based on the results of our OMV PoC). The other 3 benchmarks are our usual iozone3 call, then ioping and a mixed workload measured with fio. Test script is this: https://pastebin.com/pdex14L9
 
First results with an average SanDisk 8 GB card (debug output with F2FS and with EXT4):
F2FS EXT4 iozone 4K random write IOPS 208 196 iozone 4K random read IOPS 1806 1842 iozone 1MB sequential write KB/s 7161 10318 iozone 1MB sequential read KB/s 22429 22476 ioping k iops 1.42 1.31 fio write iops 128 132 fio read iops 384 395 OMV installation time in sec 886 943 I consider benchmark numbers that vary by less than 10% as identical and then it's easy: ext4 outperforms F2FS since all results are identical but sequential reads are +40%  faster with ext4. Test results in detail: F2FS and EXT4. I'm really not impressed by any differences -- only two things are interesting: faster sequential reads with ext4 but very low random IO write performance at 16K blocksize (that's something we noticed with a lot of SD cards already, see first post in 'SD card performance' thread).
 
At the moment I'm not that impressed by performance gains (but that might change later when the crappy 4GB card has finished) and just want to point out that there are other criteria too for choosing a filesystem for systems that are running with a high potential for bit flips (due to users using crappy chargers, bad DRAM clock settings when not using Armbian and so on). Just to give an idea please read through the PDF link here: https://news.ycombinator.com/item?id=11469535 (ext4 more than 1,000 times more reliable than F2FS when running the AFL test against)
 
BTW: mkfs.f2fs info at image creation time (no idea whether something could be 'tuned' here):
Info: Debug level = 0 Info: Label = Info: Segments per section = 1 Info: Sections per zone = 1 Info: Trim is enabled Info: sector size = 512 Info: total sectors = 7649280 (3735 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 4.4.0-72-generic (buildd@lcy01-17) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017" Info: Discarding device Info: Discarded 7649280 sectors Info: Overprovision ratio = 3.300% Info: Overprovision segments = 126 (GC reserved = 68) Info: format successful  

https://github.com/Icenowy/h3-arisc-shutdown

acpid need to be configured to take action, such triggering external scripts for shutdown.
In the meantime, try it with "evtest /dev/input/event0", I've done that and events are coming from PL3 where the button is connected.
 
EDIT : Be aware that you will only be able to shutdown the kernel, but since the OPiOne doesn't have any PMIC, it won't shutdown the power.

And another update wrt 'active benchmarking': Not collecting numbers without meaning but looking at benchmark numbers with the only aim to try to understand what's happening and to improve these numbers.
 
In the meantime I gave OPi Zero with its NAS Expansion board and an el cheapo RTL8153 GbE dongle another try. As reference the numbers from a few days ago: 21.6/26 MB/s (write/read) vs. 33/34 MB/s now. That's a nice improvement of +11 MB/s in write direction and still 8MB/s more in read direction.
 
Before:

After:

What's different? The hardware is not (well, almost not).
We're running with mainline kernel now that means way better driver quality compared to the smelly Android 3.4.x kernel the legacy H3 images have to use This commit increased CPU clockspeed from 1GHz with mainline currently to 1.2GHz ( ~1MB/s more NAS throughput in each direction) This commit resolved an IRQ collision problem (network and storage IRQs both processed by cpu0 which caused a CPU bottleneck, this greatly improved write throughput) And the simple trick to use an USB enclosure with JSM567 instead of the JMS578 on the NAS Expansion board is responsible also for a few MB/s more since now we're using UASP (improved read performance)  
Regarding the latter I also consider this a software tweak since now for whatever reasons JMS578 with mainline kernel makes only use of slower 'Bulk-Only' instead of 'USB Attached SCSI'. I'm confident that this can be resolved if interested users get active and discuss this at linux-usb. Some 'storage only' performance numbers can be found here as comparison.
 
Edit: 'lsusb -v' output for both JMS567 and JMS578 with mainline kernel:

Since there is official support for Docker on ARM for quite a while now, this thread is "resolved" to me.
 
@Igor I suggest to update the docs here: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-run-docker. I opened a PR:  https://github.com/igorpecovnik/lib.docs/pull/5
 

Just as a reference.
 
I put the machine with the NAS in the bottom part and the Pi on top (it seems to be more reasonable this way), and increased clearance on both sides some millimeters.  It reduced temperature around 2 degrees.
Then, I added a nice aluminum heatsink on top of the CPU ... and it worked with another 3 degrees when the machine was exposed.
And ... remade my LEGO prototype box, with the SSD in the bottom and clear exposed areas at each side of the OPI ... and let the machine working (really doing nothing ... just the rpimonitor on) for one and a half hours around 2:00 p.m. in a tropical country.
 

 
.... the result.  63 celsius degrees ...  very near the security temperature threshold (70).
 
Looking around, I found a bigger (around 4 cm wide) 12V fan ... then I connected it to the SATA electricity connector (it even has the right socket).  As this is under-voltage, it runs slowly and makes almost no noise neither vibration, and the fan area is bigger than the 5V tested before.
 
Now, the temperature is 42 celsius degrees ... around 20 degrees less than without the fan.  As can be seen on the old data (before 8:00), this temperature is a little lower than the one with the small JET fan.
 
What I see is that the OPI is, by itself, a hot machine.  When you add the NAS extension and put everything inside an enclosed box, this doesn't help very much to keep the assembly cold.
 
Another test is to put a much bigger heatsink on the machine, maybe covering all the OPIZ square (this is not a strange solution, the Parallella 16 do that).  But by now, it seems that I really need active cooling.
 
Here is the LEGO (and clones) box with the bigger fan.
 

 
I will check the VDD_CPUX to see how it changes the scenario.

In this topic 
The MAC address change after reboot. Need write a permanent MAC address.
sudo nano /etc/modules-load.d/modules.conf
before 8189 clear the #
Ctrl+O, Enter, Ctrl+X
 
sudo nano /etc/modprobe.d/8189fs.conf
options 8189fs rtw_initmac=00:e0:4c:f5:16:d6
Ctrl+O, Enter, Ctrl+X
 
It works for me.

https://www.armbian.com/fff/
 
- with some java scripting to make Donate page as a DIV change on download click
- added graph for support level, which we will define, for example this way:
RECOMMENDED="Ubuntu_xenial_next_nightly.7z:33,Ubuntu_xenial_next.7z:100"

Well ... I have a msata connected to the NAS device ... and these are the numbers:
 
Now, with a real mSATA.
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 684 MB in 2.00 seconds = 341.73 MB/sec Timing buffered disk reads: 92 MB in 3.02 seconds = 30.47 MB/sec As can be seen .. it is a little slower than the WD Blue hard disk with my custom cable, but so near that can be a comparable speed.
 
The disk is a V-NAND SSD 850 EVO 250GB mSATA from SAMSUNG (i.e. a good device).
 
Now, the two main reasons this setup is a good one:
 
1) No spin-up electricity consumption.  Although not so detailed checking (I don't have better measuring tools), but with a USB power tester, the machine maximum consumption was around 0.80 Amp from start-up, including the hdparm test.
 
2) Look at it (picture bellow) ... no SATA cables, extremely compact.
 
About my configuration:
 
This setup has also a SanDisk Cruzer Fit USB 3.0 8G Disk (the short one on one of the USB ports --- the one is not shared with the mSATA device ---).  This is for the swap and other temporary stuff, so I don't need to degrade the OS SD card by constant rewriting there.  And a 3A power supply.
 
And it is important to add some screws on the mSATA storage card.  When you put it, the card remain at 45 degrees from the NAS device plane, so you must pull it down and keep there with "something" ... in this case, two Nylon screws with a nut between the mSATA and the NAS, and a short standoff bellow.
 
I still need to add a 5V fan and the case, and my setup is ready to go production (with my particular information system there).
 
 
 

That's another story and it's possible. Plugin USB drive and check documentation.

Really impressive work for a "one man army". Much appreciate your effort.

One final update regarding Roseapple Pi (using Actions Semi S500 just like LeMaker Guitar or the announced Cubieboard 6). Since I booted the board one last time anyway I thought let's give USB3 there also one last try. I connected a Samsung PM851 in an JMS567 enclosure (with own power supply!) to the USB3 port and had a look with most recent 3.10.105 kernel:
root@roseapple:~# lsusb Bus 002 Device 002: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@roseapple:~# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M That looks nice since UAS seems to be useable. Let's give it a try with the 2 iozone calls from Clearfog measurements above:
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 13525 16451 19141 24275 14287 16492 102400 16 39343 48649 56409 63777 40203 45654 102400 512 68873 75835 89871 102977 98620 94677 102400 1024 115288 111747 170742 176837 172585 104936 102400 16384 117025 105977 195316 196457 196582 117819 iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K kB reclen write rewrite read reread 4096000 4 124421 132386 134795 134760 4096000 1024 127135 134943 127559 128026 If you compare with PM851 numbers made with Clearfog above it's obvious that S500 numbers are not that great. And since S500 features only Fast Ethernet at least for NAS use cases sequential transfer speeds are irrelevant anyway. I tried then to use an external VIA812 USB3 hub with integrated RTL8153 Gigabit Ethernet but this only led to error messages, /dev/sda1 disappearing and the board failing to boot afterwards. Fortunately this Roseapple Pi (formerly called Lemon Pi more correctly) has never been sold. There exist just a few dev/review samples that were sent out around the globe.
 
Maybe the above numbers help some future Cubieboard 6 owners who got tricked into believing CB6 would have 'real SATA'   Funnily USB-SATA on Cubieboard 6 will be much faster than on older Cubieboards (using A20's 'real SATA' or the horrible GL830 USB-to-SATA bridge on Cubieboard 5) but for most use cases this won't help much since there's only Fast Ethernet on the board. So even when adding a RTL8153 Gigabit Ethernet dongle to one of the 2 USB2 ports 'NAS performance' won't exceed that of Cubieboard 3 (the so called Cubietruck)

There are many ways to watch accelerated youtoube videos on stock Armbian legacy install. Just not within a browser.
 
youtube-dl, mpv, ...
You don't need any windows based download tool. 
https://forum.armbian.com/index.php?/topic/499-bananapipro-video-accelerated-no-work/&page=2#comment-28237

It's to avoid Android on those boards since it's crappy and unsupported. Luckily we have a well maintained Openelec fork if you seek multimedia OS.