Jens Bauer

@balbes150, yes it is working!
 
How are you generating / compiling this image? Is it integrate with Igor's lib building system? 
Have you tried to write to NAND chip using nand-sata-install from Armbian?
WiFi is not working by default, don't know if it is only a matter of loading the module or not. The WiFi chip is AP6255.

@balbes150, 
 
The Armbian_5.24_Amlogic-s905x_Ubuntu_xenial_3.14.29_desktop_20161125.img.xz image is booting on Beelink GT1. Please check the full dmesg:
 
https://gist.github.com/Grabber/5737a65926dfe18333a8b2cc26035139
 
What are the next steps?

@choco, I was trying to compile your branch and got this error:
From https://github.com/igorpecovnik/mt7601  * branch            old        -> FETCH_HEAD  * [new branch]      old        -> origin/old [ .... ] Checking out cp: missing destination file operand after '/home/lvmc/Projects/output/cache/sdcard/lib/modules/3.14.29-beelinkgt1/kernel/net/wireless/' Try 'cp --help' for more information. depmod: ERROR: could not open directory /home/lvmc/Projects/output/cache/sdcard//lib/modules/3.14.29-beelinkgt1: No such file or directory depmod: FATAL: could not search modules: No such file or directory What is the current stage / status of your fork. What is done, what is not working, what efforts we have to concentrate our force on?
 
@Igor, @tkaiser, is there a check list of things we have to get working to have a "stable" Armbian release?

We added now a simple method to check this stuff in the next release. You can then simply let armbianmonitor check a device by doing an '/armbianmonitor -c /mountpoint'. Looks then like this for an older 512MB TF card lying around:
 
The results from testing /dev/sda1 (vfat):
  Data OK: 456.10 MB (934096 sectors)
Data LOST: 0.00 Byte (0 sectors)
Average writing speed: 3.11 MB/s
Average reading speed: 10.03 MB/s
                                            random    random
reclen    write  rewrite    read    reread    read     write
     4     1735     1744     4560     4560     4553       58                                                          
   512     4613     4814    10247    10194    10248     2570                                                          
 16384     4718     4960    10411    10340    10410     4847                                                          
 
Health summary: OK
 
Performance summary:
Sequential reading speed: 10.03 MB/s 
 4K random reading speed:  4553 KB/s 
Sequential writing speed:  3.11 MB/s (too low)
 4K random writing speed:    58 KB/s (way too low)
 
The device you tested seems to perform too slow to be used with Armbian.
This applies especially to desktop images where slow storage is responsible
for sluggish behaviour. If you want to have fun with your device do NOT use
this media to put the OS image or the user homedirs on.
 
To interpret the results above correctly or search for better storage
alternatives please refer to http://oss.digirati.com.br/f3/and also
http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card
and http://thewirecutter.com/reviews/best-microsd-card/
 
Since armbianmonitor is just a simple script anyone can already upgrade now:
curl "https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/armbianmonitor/armbianmonitor" >/usr/local/bin/armbianmonitor apt-get install f3

Yes, it was quite obvious that you had a problem with random writes. And the following is not for you but for anybody else stumbling accross this thread.
 
NEVER use bonnie/bonnie++, dd or hdparm to measure storage performance with Armbian.
 
We ship with iozone for a reason since iozone testing is more reliable and especially results are easier comparable.
 
Do a chdir to the directory in question and then do a
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 to get a quick overview how your storage behaves and think about running the 3 sets of tests outlined here if you're interested in maximum sequential transfer speeds.
 
The most important rule when benchmarking: Don't trust in the numbers you get since they are wrong most of the times. But there are tools that prevent you from measuring wrong numbers a bit better than others but none is perfect. A short list of really incapable 'benchmark' tools (unfortunately these are the 3 most recommended amongst SBC users):
hdparm: only a weird joke since the 'benchmark' runs just a few seconds and chances that the results are influenced by a short write burst in the meantime are 50% or higher. If used as often recommended (-tT) then you're tampering disk throughput with memory bandwidth also which makes the results even more meaningless dd: most often used with the wrong flags, therefore not testing disk but RAM (caches/buffers) instead, only testing sequential speeds and mostly with absolutely irrelevant block sizes that tell you nothing about 'real world' performance bonnie/bonnie++: They test something but definitely not what they claim to do. Bonnie(++) output is interesting if you're an engineer to tune your operating system or to learn how compiler switches might influence benchmarks but it's nothing for end-users Same applies to 'mixed' tests that also invoke high CPU utilisation (scp test results vary depending on the strength of negotiated SSH ciphers on weak ARM boards, so you're testing the speed of encryption algorithms and not storage/network most probably) or tamper disk throughput with network throughput (FTP, NFS, SMB, whatever). These tests are useful to get the idea how your application might behave but they can't help you identify the bottlenecks or improve the situation.

BTW: I chose the Orange Pi Plus as an example for a reason. Since this is a device where everyone will get the idea that it's necessary to test stuff individually.
 
When you connect a SATA disk to the Orange Pi Plus which seems the most reasonable choice you probably won't see any performance improvement compared to CubieTruck now. If you use the very same SATA disk, put it in an external enclosure and connect it through USB then performance will improve. Why? Is SATA and USB different on the Orange Pi Plus? No, it's just the H3 SoC features no SATA and the SATA port on the OPi+ has been implemented using the slowest USB-to-SATA bridge in the world (GL830) which isn't able to exceed 15 MB/s write speeds and will be outperformed by any external USB disk not relying on GL830.
 
So refusing to 'benchmark correctly' will just lead to another frustrating situation and a device you might throw into the bin. Measuring all the stuff individually you're able to identify the real bottlenecks and improve the situation.
 
 
In case you asked me: Sure, you can always loose data as long as you're not doing backups
 
Really, running any sort of real benchmark might put significantly more load on a device which might lead to stability problems caused by an insufficient PSU for example. The 'armbianmonitor -c' check was designed to verify the speed/reliability of SD cards and thumb drives (and no, the tests do not destroy anything, just try to fill the storage in question with test patterns that are verified later) but being used with a disk and insufficient power supply they might lead to data/filesystem corruption.
 
But that's what benchmarks are for (when used in an active approach), identifying bottlenecks be it performance or reliability relevant. In case anyone's interested: We used the linpack high performance benchmark to identify reliability issues caused by undervoltage settings with Pine64 in the past: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-196399188

Great, this is the first time we're speaking about the 'active benchmarking' approach. You talked all the time about storage performance and now you tell us the real bottleneck: CPU utilisation. Your dual core A20 is already too busy with this torrent stuff to be able to write faster to disk. So in reality it's not about storage performance at all but your application being CPU bound.
 
Using approriate tools (dd and bonnie aren't such as I already tried to explain in THIS thread here) you can check network and storage performance individually and then simply choose a more appropriate device. In your case you might choose an SBC using more/faster CPU cores still with GbE since Fast Ethernet would be a bottleneck already and it seems USB storage speed might be sufficient (to be confirmed by appropriate active benchmarking and identifying how your application writes to disk).
 
In other words: by choosing a device that shows less storage performance but more processing power (eg. an ODROID C1+ or an Orange Pi Plus) you might be able to improve your application's peformance by factor 2.

Maybe it might make more of a difference that you 3 guys are constantly measuring completely different things where the respective bottlenecks are always different so that it's not possible to put any of the numbers you're throwing around into any relationship.
 
You tested FTP, most probably with single large files. So you tested both network throughput (rather limited in one direction), sequential storage speeds (also limited both by the interface and the disk in question). Where the 30 MB/s in one direction originate from might have different reasons: A20's SATA write bandwidth is limited to 40-45 MB/s and using HDDs with 5400 rpm without knowing how full they are (when they're empty sequential transfer speeds are typically twice as high) or in which state (heavy fragmentation) is pretty useless.
 
The 10MB/s Vlad's talking about when using a torrent downloader are most likely no storage limitation but instead one of the application in question or the Internet download speed (pretty useless to tweak I/O schedulers if it's just about not enough data available to be written to the disk).
 
When one starts to test all this stuff individually then you get an idea where bottlenecks are present (quite a few of them on any sunxi device). And then you get also an idea how to improve performance if it's necessary. Everything outlined in detail already: http://linux-sunxi.org/Sunxi_devices_as_NAS#Influence_of_the_chosen_OS_image_on_NAS_performance
 
And as the result of a few hours of work now storage testing made easy: 'armbianmonitor -c' exists, see link above.

In my eyes it's relatively easy (disclaimer: I used/contributed to Bananian first but switched very fast to Armbian over a year ago). Simply count
boards supported OS 'variants' commits made amount of available documentation active contributors and decide then. Nico (the individual behind Bananian) is focused on one secure headless distribution (keep that in mind if you use insufficient tools like sftp since 'performance' might be influenced massively by the SSH ciphers being negotiated between 'client' and 'server'!) but doesn't spend that much time on further development in the meantime.
 
I wouldn't say Bananian is a bad choice but the 'speed' of development already scares me a bit. As an example: Bananian uses an ugly hack (provided by me) to read out the SoC temperature. In the meantime better alternatives exist and I made suggestions to Nico to improve this. But no interest, they still just try to maintain these ugly hacks. Unfortunately this is true for other areas as well.
 
I would believe we'll see a lot of improvements in and around Armbian this year therefore the choice is easy

Right Now I'm researching how to enable GPU H/W acceleration and VPU H/W acceleration.
Do you have any guide?

@garyang, how can I help you?

Finally S912(T95Z Pluse) succeeded in booting Linux.
I just build from http://openlinux.amlogic.com:8000/
Here is part of my build https://drive.google.com/file/d/0ByFJ5X3gpn6PYmlUV0p0UkNqbDA/view?usp=sharing
Image source is balbes150's https://yadi.sk/d/lnMowa-Swau3E
I just overwrite dtb.img and Image files.
Check balbes150's comment
http://forum.armbian.com/index.php/topic/2419-armbian-for-amlogic-s905x/

@balbes150
I've tried multiboot enableed with Universal multi-boot 0.6.
But, It didn't work.(update app and Toothpick both)
My box is T95Z Plus.
I've also built buildroot for S912.
 
PS : I've solved problem.
First, enable kszaq's Libeelec with the Toothpick method.
Second enable balbes150's Universal multi-boot.

Sorry for the late answer, but my free time is very limited.
To be honest, I used copy/paste of make script from @150balbes u-boot repo.
There is it:
#!/bin/bash make distclean export PATH=$PATH:/opt/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin/ export PATH=$PATH:/opt/CodeSourcery/Sourcery_G++_Lite/bin ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- make gxm_q201_v1_config ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- make And it's compiles without errors, but after uninstall gcc-arm-none-eabi
This is the end result:
Building board/amlogic/gxm_q201_v1/acs.bin CC acs.c AS acs_entry.S PP acs.ld.S LD /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/acs.elf OD /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/acs.dump BIN /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/acs.bin Built /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/acs.bin successfully DEPS /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21.ld.d DEPS /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21_entrypoint.d DEPS /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/timer.d DEPS /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/serial.d DEPS /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21_main.d Building board/amlogic/gxm_q201_v1/bl21.bin CC bl21_main.c CC serial.c CC timer.c AS bl21_entrypoint.S PP bl21.ld.S LD /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21.elf OD /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21.dump BIN /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21.bin Built /opt/Amlogic_u-boot/build/board/amlogic/gxm_q201_v1/firmware/bl21.bin successfully CPP user_task.lds CPP task_entry.s CC task_entry.o CC user_task.o CPP misc.s CC misc.o CC uart.o CC suspend.o CC dvfs.o CC lib/string.o CC lib/delay.o LD /opt/Amlogic_u-boot/build/scp_task/bl301.out OBJDUMP /opt/Amlogic_u-boot/build/scp_task/bl301.dis OBJCOPY /opt/Amlogic_u-boot/build/scp_task/bl301.bin 9848+0 records in 9848+0 records out 9848 bytes (9.8 kB, 9.6 KiB) copied, 0.0149399 s, 659 kB/s 3764+0 records in 3764+0 records out 3764 bytes (3.8 kB, 3.7 KiB) copied, 0.00593117 s, 635 kB/s Amlogic img found, use new FIP structure! Creating "../fip/gxl/fip.bin" Firmware Image Package ToC: --------------------------- - SCP Firmware BL3-0: offset=0x4000, size=0xD400 - EL3 Runtime Firmware BL3-1: offset=0x14000, size=0x140D0 - Non-Trusted Firmware BL3-3: offset=0x2C000, size=0xA7F38 --------------------------- ACS tool process done. 11840+0 records in 11840+0 records out 11840 bytes (12 kB, 12 KiB) copied, 0.0181297 s, 653 kB/s 5825+0 records in 5825+0 records out 5825 bytes (5.8 kB, 5.7 KiB) copied, 0.00897931 s, 649 kB/s ../fip/gxl/u-boot.bin build done!

Sure, the same as with every other hardware RAID controller. It's useless to waste time on trying to explain the problem and it's easy to learn what's wrong with that approach as soon as the controller stops working. You have then 2 or more disks with data on it you can't access any more. Home/SOHO RAID simply doesn't deliver the R in RAID unless you have spart parts lying around and a lot of experiences with exactly that RAID card you use (BTDT and given up on RAID hardware completely almost 15 years ago -- we contract with other IT houses for that who are happy dealing with catastrophes)
 
Also it's 2016 and not 1996 any more. We have modern FS with nice features and unless I would need business continuity (eliminating every single point of failure which is not possible with small crappy SOHO RAID) if I want to throw in more disks than necessary then I'll use them for backup (in fact I do regular snapshots on a ZFS mirror and then send them incrementally to totally different locations using 'zfs send/receive' -- same can we do on Linux with btrfs now)

Have you already seen this low-end Marvell announcement (now on Kickstarter): http://www.cnx-software.com/2016/09/23/marvell-espressobin-board-with-gigabit-ethernet-sata-pcie-and-usb-3-0-to-launch-for-39-and-up-crowdfunding/
 
I would prefer this since I would never ever implement SOHO/home RAID (again). ZFS+raidz2 is ok for more than 2 disks, everything else stinks (especially all those cheap HW RAID chips) if you don't have every SPoF lying around (since otherwise the R in RAID becomes a joke)

LOL, and there is the MACCHIATOBin: http://www.cnx-software.com/2016/10/11/solidrun-macchiatobin-is-another-marvell-armada-8040-networking-mini-itx-board/

Hi All,
 
Which SOC gives best performance today for SATA I/O?

According to the Sunxi wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS
"Since not every A20 based sunxi device uses GMAC networking (or even Ethernet at all) the following devices are the best choices: A20-OLinuXino-Lime2, Banana Pi, Banana Pro or Banana Pi M1+, Cubietruck, Hummingbird A20, Lamobo R1, Orange Pi, Orange Pi Mini or pcDuino3 Nano (Lite)."

I've actually got a cubietruck+ here (that uses a terrible USB to sata bridge) but it's a terrible choice. Hoping you guys (or tkaiser ) can steer me in the right direction. I could run out and order a banana pro, but I feel like A20 has been around a while and maybe there's something better today? Clearfog is looking nice, but I guess I'd need a pci-e sata card.
 
This isn't 'really' a NAS -- The actual use case is as follows:
 
 
 


As you can see, the inbound data will come from an OTG connection running g_mass_storage gadget to appear as usb disk to host pc. This is essentially a raid1 array that is decrypted via gpio keypad, and made available as a usb drive to another system. Hardware accel for the encryption would of course be welcomed.
 
I'll need something that doesn't use a usb->sata bridge, because usb will likely be tied up transfering inbound data -- and even if it wasn't they seem terribly slow. A good support community would of course be nice too -- The H8/a83T just doesn't seem to have it yet.
 
Any input would be appreciated.
 
Thanks all,
CMirra

The 'limitation' is that Armbian supports too many boards/architectures and that we're not a large team. U-boot and kernel variants for some boards have to be built with 32-bit compilers, most rely on 64-bit (and then some patches exists and where we are aware of we included them to let the stuff build on 32-bit hosts too).
Check which board has which requirements regarding u-boot and kernel versions: https://github.com/igorpecovnik/lib/tree/master/config/sources Check what Armbian needs/downloads to produce images for all supported (+40) boards: https://github.com/igorpecovnik/lib/blob/master/general.sh#L538-L546 The 'dpkg --add-architecture i386' call is there to let 32-bit software run on the 64-bit build host. The opposite is not possible. And that's the simple reason why 64-bit is a requirement for the build host.
 
In case you're only after one specific board we support you might be fine with a 32-bit environment. But we're simply not able to support that. So much real work is already postponed due to lack of ressources and developers to deal with support requests at this level (since everyone can use Docker, Virtualbox, whatever + a x64 Xenial installation, there is simply no excuse to not use a 64-bit build host these days)
 
Edit: not realized before that you thought about using a PowerBook for the stuff. Nope, neither PowerPC nor ARM are sufficient, you need x86 anyway and there a 64-bit capable host for our build system (we inherit these requirements from the legacy sources we have to use). So please don't even think about anything 'bit related' but get a x64 host (emulation won't help, VirtualPC can only emulate 32-bit guests).
 
BTW: Back at the time I also used a PowerBook G4 I always had a 2nd laptop with Linux/x86 carried around. Fortunately they switched to x86 10 years ago since now all the OS I need to care about (only OS X, Linux and Solaris any more -- sometimes Windows Server) can run on a MacBook.

Armbian build script depends on OS specific and architecture specific tools and configuration, and the only supported environment is Ubuntu Xenial x64.
Virtual machine is recommended in case you don't want to install development tools to your home or work environment, but it is not required if you run Ubuntu Xenial x64 natively or in a container.

Hello!
 
Hopefully someone got ideas or a working, booting .img.
I got an CS918 box, which is based on the rk3188 system. i already played around with probably the most common tools on linux (rkflashkit, upgrade tool ...)
Unfortunately there are some dead download links out there, so i cannot download the most interesting img files. 
I'd prefer a debian img, but ubuntu will do the job too. I also tried out some steps from the "morrison-project" with its interesting scripts, but it didnt work yet.
Thank you for any ideas and links.
 
Greetings
 
CS918

... and it's in our plan / interest to bring one of those, most likely GT1, directly to our supported list. 
 
@chocho
Which compiler is recommended for this u-boot if any?

@chocho, I'm highly interested in helping you port Armbian to GT1. I have a few units in my hands now, how can I help you?

Finally have some free time to solder pins to GT1 UART and boot compiled Armbian image.
It boots, but no ethernet connection, The LAN chip is the same as odroid c2 - Realtek RTL8211F Gigabit Ethernet
This is boot log:
http://pastebin.com/XVJFq8Rn
 
My fork is here:
https://github.com/chavdar75/lib

Attention: 200 pieces S912 TV box for $50 each including shipping: http://www.cnx-software.com/2016/10/07/km8-pro-amlogic-s912-android-box-sells-for-49-99-promo/