tkaiser

The only feature that's interesting on the Raspberry Pi is that one can use the VPU correctly now (after a few years). We use RPi B+ as IP camera (even when the CPU core is clocked with just 200 MHz the VPU is able to provide a 1080p@30 fps h.264 encoded video stream) or for digital signage, often combined. In the meantime also lightweight distros exist like http://dietpi.com
 
For everything else the RPi is always the worst choice due to its one single USB 2.0 connection to the outside.
 
Supporting the RPi would mean Armbian either focuses on a completely new use case (desktop stuff -- VPU) or on a completely new user base (clueless people).

No idea. I tried the script on ODROID-XU4 and Banana Pi and it always fails in the same situation: 
hdparm --fallocate $whatever file always returns with 'File too large' regardless of the size. Since the very same happens on the Banana Pi also when the SSD is connected via SATA maybe it's just a bug in hdparm v9.43 (that's the version Jessie and Stretch use, had no time to test with Ubuntu yet)

Nope, they sort it by popularity or whatever (Pine64 at the top and ROCK64 at the bottom for example) and try to group by board names (eg. putting LeMaker's Banana Pro and SinoVoip's BPi M2+ in one section while both are totally incompatible -- same problem also with NanoPis). Doing so is HIGHLY MISLEADING since not brands are important but the technical base. A NanoPi NEO 2 and a NanoPi M3 are from two different worlds while a NEO 2 and an Orange Pi Zero Plus are almost the same (especially when Armbian is running on them it will be very hard to spot any difference in usage and performance!)
 
If people search on the download page they search for features. If they're absolutely clueless we can't help them anyway. If we want to guide people a little bit we have to stop what we're doing now (focused on technical details) and start to get into the heads of our users (what are they interested in? And are these the correct reasons? Again 'SATA': Not the existence of a small port with 7 pins to connect a SATA cable to is relevant but what users associate with this. And on boards we list as what they consider the label for 'fast storage' they get just insanely slow and broken GL830 USB-SATA crap).
 
Seriously: people looking for the NAS use case click on GbE, click on SATA, check the boards, think 'the more DRAM the better', think 'the more CPU cores the better', weigh some features and end up buying an Orange Pi Plus 2 instead of an ODROID-XU4 (which is magnitudes faster as NAS but is not even considered since users think 'SATA is better than USB3'). What we do here is highly misleading and must stop.

I know there are direct means to access GPIOs, but then I would need to write code unique to each CPU. If Armbian only supported AllWinner H3 devices, it would be an easy decision. For now, I think it's best to keep the code simpler and support all SoCs.
 
I'm not sure where this project is headed. I don't have the time to turn it into a support-everything/do-everything library. I saw a need and I put together a simple solution. It would be great if this was given the "blessing" of Armbian and turned into a real community effort.
 

Hmm... not really since this should happen at the driver layer. He uses a script describing 'We need a very modern hdparm, for its --fallocate and --trim-sector-ranges-stdin flags' which is interesting since I'll try TRIM with my JMS578 then soon  

And both are WRONG! That's the problem. Better no information than misleading/wrong information. Unless this categorization can be edited/reviewed by us (eg. part of board config files) I would really prefer to stop 'advertising' wrong features.
mSATA: the Hummingboard has no mSATA but mPCIe only, same with the Clearfogs by default: you need to rebuild u-boot and have to freeze the packages to get reliable mSATA/SATA on the mPCIe slot(s) SATA: This category is totally worthless if boards with crap SATA like the Orange Pi Plus and Plus 2 are listed here too. People look after SATA since they associate 'fast storage' with this. This is already wrong with those A20 boards but it gets bizarre when we're talking about the crappy GL830. And the only boards with real fast SATA -- not on mSATA slots but M.2 slot with key type B -- are missing here Again: user perspective. The features listed there should match user expectations (and that's fast storage and not 'technically a SATA port is on the board even if it's crap'). Just another part of the same problem...

Well, with SuperSpeed I doubt there will be any real differences since 5 Gbps with 8b10b encoding means USB bottelenecking here with ~400MB/s maximum. And if the host is SuperSpeed Plus capable (10 Gbps with 128b132b encoding) then the SATA 3.0 controller on the other side of the chip will be the bottleneck (6 Gbps with 8b10b encoding --> ~480 MB/s max, no idea how/why benchmarks show up to 520 MB/s here). Though there might be differences wrt random IO but honestly: if I need high random IOPS then eliminating the USB bottleneck is a better idea.
 
These numbers here show that 'native SATA' provided by Marvell SoCs outperforms any USB3 solution easily especially wrt random IO (and I doubt ASM1351 will make a real difference here). BTW: same test with an EspressoBin shows only slightly lower numbers than the Clearfog from my link.
 
 
Is needed at both ends of the USB cable (and AFAIK it's still missing in Linux for USB)
 

I bought two of them just to realize that they're based on crappy Norelsys chips (the reason why Armbian in the meantime does UAS blacklisting on its own -- the same happens on ayufan OS images for ROCK64 though there it's done differently). The JMS578 ORICO thingie looks different: http://www.orico.cc/goods.php?id=6355
 
Please read through this carefully again. The guy has one JMS567 and there's something wrong with it (queue size limited to 14 for whatever reasons). When comparing ASM1153 and JMS567/JMS578 they perform both pretty identical (JMS578 should be able to support TRIM but AFAIK there's still software support missing in Linux)

No idea. I've one ASM1153E here but never measured consumption (only pretty unprecise and then I didn't notice differences to JMS567 or JMS578). Since the basic problem is always one USB3 SuperSpeed PHY and one SATA 3.0 PHY being active I also doubt that there are real power savings possible,
 
Though for JMicron SATA bridges we learned recently that there exists the possibility to update/modify the firmware so maybe there are some tweaks possible. While I'm currently in direct contact with JMicron (issue here) I don't want to ask these questions now since waiting for firmware fixes that provide full SAT compliance for JMS567/JMS578.

Got some nice feedback from JMicron explaining firmware versions.
0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
 
When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
 
Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
 
JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

BTW: I tested through a variety of other OS images the last weeks/months and since some of those have been recently re-released I gave it a try again today. Just as an example how important appropriate settings are if you want to squeeze out the max out of your hardware.
 
The following is 3 times exactly the same hardware (HC1 with same SSD as /dev/sda1, same SanDisk Extreme Plus with the OS on, same Gigabit network, same MacBook as client). It's even exactly same Debian version (latest Jessie) and also exactly identical Samba version. Why the performance differs that much is explained here in detail.
The first distro tested uses an outdated 3.10 kernel, doesn't take care about IRQ affinity or any other relevant settings (except cpufreq scaling) and also uses default (AKA bad) Samba settings. The second distro is the one the first is based on. Same kernel but different cpufreq settings. Obviously also no further optimizations but here OMV has been installed with armbian-config/softy by me which explains the much better SMB write performance The 3rd is latest official OMV 3 image based on Armbian and our next kernel branch so using a rather recent 4.9 LTS kernel soon to be switched to 4.14 (tweaks explained here)  
Disclaimer: The dietpi and Meveric numbers were made a few weeks ago and I couldn't believe that they were that low. But today I did a quick re-test (only one run since it takes ages due to that low performance) and so I decided to publish results. Please be aware that these Samba tests were made with a MacBook running macOS as client which does not show best possible performance (for reasons see here for example -- it needs a more recent Samba version with special settings to perform optimal with macOS clients) so most probably in real-world scenarios and with Windows as clients performance differences might not be that huge and overall SMB performance higher with the non OMV images.
 
BTW: SMB write performance with dietpi increased by 6-7 times as expected just by adding the usual 4 simple lines with some adjusted settings to smb.conf. Edit: And 'use sendfile = yes' might also make a real difference, see posts below. Won't test with dietpi again since already deleted.

4 cores:
___ ____ _ ___ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) / _ \ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | | | | | '_ \ / _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | | |_| | | | | __/ \___/|_| \__,_|_| |_|\__, |\___| |_| |_| \___/|_| |_|\___| |___/ Welcome to ARMBIAN 5.35 user-built Debian GNU/Linux 8 (jessie) 3.4.113-sun8i System load: 0.37 0.24 0.10 Up time: 2 min Memory usage: 10 % of 494MB IP: 192.168.3.157 CPU temp: 41°C Usage of /: 82% of 1.1G Last login: Sat Nov 25 16:49:11 2017 from xxxxs-ubuntu.fritz.box pi@orangepione:~$ uname -a Linux orangepione 3.4.113-sun8i #4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux pi@orangepione:~$ cat /proc/cpuinfo Processor : ARMv7 Processor rev 5 (v7l) processor : 0 BogoMIPS : 1942.85 processor : 1 BogoMIPS : 1942.85 processor : 2 BogoMIPS : 1942.85 processor : 3 BogoMIPS : 1942.85 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 Hardware : sun8i Revision : 0000 Serial : 540078678620542709ce pi@orangepione:~$  

I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
 

Well, I'm pretty sure they can understand English. But I'm here to help of course... We are already in contact with @guidol
 

I don't think there is anything to fix there. Observed issue is the old bug (either disp2, arch timer or a combination of both) which is disappearing and reappearing again randomly due to its nature. But I didn't test this yet and we can always update pine64-default branch later using a newer ayufan's branch once any of those branches in considered "stable".

Maybe @bozden can help here? IMO it's really important that if 3rd parties try to directly link to Armbian images (and not the download pages) that they use those generic links like 'Ubuntu_xenial_default.7z' which will be resolved automagically to most recent OS image in the background. It's sad to see outdated images being spread...

BTW: I tested through a variety of other OS images the last weeks/months and since some of those have been recently re-released I gave it a try again today. Just as an example how important appropriate settings are if you want to squeeze out the max out of your hardware.
 
The following is 3 times exactly the same hardware (HC1 with same SSD as /dev/sda1, same SanDisk Extreme Plus with the OS on, same Gigabit network, same MacBook as client). It's even exactly same Debian version (latest Jessie) and also exactly identical Samba version. Why the performance differs that much is explained here in detail.
The first distro tested uses an outdated 3.10 kernel, doesn't take care about IRQ affinity or any other relevant settings (except cpufreq scaling) and also uses default (AKA bad) Samba settings. The second distro is the one the first is based on. Same kernel but different cpufreq settings. Obviously also no further optimizations but here OMV has been installed with armbian-config/softy by me which explains the much better SMB write performance The 3rd is latest official OMV 3 image based on Armbian and our next kernel branch so using a rather recent 4.9 LTS kernel soon to be switched to 4.14 (tweaks explained here)  
Disclaimer: The dietpi and Meveric numbers were made a few weeks ago and I couldn't believe that they were that low. But today I did a quick re-test (only one run since it takes ages due to that low performance) and so I decided to publish results. Please be aware that these Samba tests were made with a MacBook running macOS as client which does not show best possible performance (for reasons see here for example -- it needs a more recent Samba version with special settings to perform optimal with macOS clients) so most probably in real-world scenarios and with Windows as clients performance differences might not be that huge and overall SMB performance higher with the non OMV images.
 
BTW: SMB write performance with dietpi increased by 6-7 times as expected just by adding the usual 4 simple lines with some adjusted settings to smb.conf. Edit: And 'use sendfile = yes' might also make a real difference, see posts below. Won't test with dietpi again since already deleted.

Good point I almost forgot about since this is set by default with OMV already (tested on day 1 when I started with OMV back in April -- OMV uses some internal preferences which then get fed into the daemon's config files automagically):
root@odroidxu4:~# testparm 2>/dev/null | grep sendfile use sendfile = Yes So I tested the opposite now with Armbian/OMV by setting 'use sendfile = no' in OMV's "/config/services/smb/extraoptions", verified with testparm and as expected read performance drops a lot (directory enumeration too) while write performance slightly increases:

So yes, 'use sendfile = yes' is important even with beefy hardware (I did a quick check also with performance governor but numbers are close to identical so it's not related with cpufreq scaling and also not a true CPU bottleneck -- watched utilization with htop, everything happens on the big cores and it looks like there's still some room... unlike with A20 where usually the smbd thread is bottlenecked by the CPU core it's running on)
 
As a comparison the 'use sendfile = yes' numbers from above again:

I just open-sourced some code to replace fbtft and fbcp. It uses dirty-tiles to try to minimize the writes to the SPI LCD and improve the framerate. I'm working with some of the guys at sudomod to get it working on Lakka builds too. You can download it here:
 
https://github.com/bitbank2/BB-CP
 
 

This whole stuff looks interesting. My only concern is the rather outdated kernels they use (for Raspberry Pi it's 4.4.50 and for the Oranges 3.4.113 -- at least I don't like to run stuff that matters with that outdated kernels)
 
 
Sorry, but when this OPi R1 is used correctly (as a little routing device without peripherals attached) it should be almost impossible to underpower this thing even with crappy USB cables and crappy phone chargers. I tested 2 years ago with undervolting an Orange Pi PC: still booted at 4.4V but then of course both HDMI and USB peripherals got in trouble (since way below the specs: HDMI allows for 4.8V – 5.3V and USB for 4.75V - 5.25V) while the camera was still working.
 
On the R1 without HDMI and USB consumers that need 4.8V minimum (without USB peripherals also minimal consumption which helps with voltage drops) and most if not all components on board 3.3V max it shouldn't really matter how crappy you power the board. We got OPi Zero with reasonable settings below 700mW (mW and not mA) so depending on how much the RTL8152 consumes I would still assume that we're talking here about less than 2.5W peak consumption (too lazy and uninterested to measure myself)

Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.

Today something called 'zeroshell updated:2017-11-23' appeared on Orange Pi R1 download page: http://www.orangepi.org/downloadresources/
 
Curious I downloaded the image and had a look (still keen on either correct schematics or a correct hardware description. There's an additional led on this board next to the USB Ethernet MagJack and I still hope we can use a GPIO to toggle powering of the RTL8152 Ethernet chip in case it hangs).
 
Guess what a surprise seeing that they use our work and rely on legacy kernel (IMO 'a bit' challenging for something with security in mind):
root@orangepizero:/mnt/sda1# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT | grep sda sda 14.9G ├─sda4 ext4 2.1G /mnt/sda4 ├─sda2 iso9660 640M /mnt/sda2 ├─sda3 iso9660 640M /mnt/sda3 └─sda1 vfat 319M /mnt/sda1 root@orangepizero:/mnt/sda1# bin2fex OPIZERO.bin | grep corekeep fexc-bin: OPIZERO.bin: version: 1.2 fexc-bin: OPIZERO.bin: size: 35384 (84 sections), header value: 35384 [corekeeper] corekeeper_enabled = 1 root@orangepizero:/mnt/sda1# cat boot-slot.cmd setenv machid 1029 setenv bootm_boot_mode sec fatload mmc 0:1 0x500 slot.scr source 0x500 setenv bootargs ${CONSOLE} root=HD=${HD} rootwait panic=10 panic=10 loglevel=0 ${PARAMETERS} fatload mmc 0:1 0x43000000 OPIZERO.bin fatload mmc 0:1 0x48000000 ${SLOT}/${KERNEL}/vmlinuz-OPIZERO bootz 0x48000000 root@orangepizero:/mnt/sda1# cat slot setenv SLOT 1 setenv HD ZS-7D1C9C63_3.8.1A_1 setenv KERNEL 3.4.113-ARM-ZS setenv CONSOLE console=ttyS0,115200n8 setenv PARAMETERS quiet root@orangepizero:/mnt/sda4/_DB.001/LOG/2017/Nov/16/zeroshell# cat Administration Nov 16 20:50:12 zeroshell Administration: SUCCESS: System successfully started with Linux kernel 3.4.113-ARM-ZS and ZeroShell 3.8.1A  

Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.

Maybe there are commercial NTFS drivers available (for ARM) but I would simply drop the idea to use NTFS since as it's implemented in a standard Debian or Ubuntu ('ntfs-3g' package: 'read/write NTFS driver for FUSE') it will always be the worst combination of slow and ressource hungry.
 
I would simply use a 'native' filesystem on Linux (ext4 or btrfs) and if you need something to interchange between different systems maybe ExFAT is a solution (no idea, I stopped this idea years ago when I did some tests with ExFat and UDF and especially the latter turned into a nightmare)

In the meantime there's both an Android 7.x 'SDK' out for H3 boards and a new BSP relying on some 4.4 kernel version is said to be ready to release today. No idea who'll look into this (none of the TV box vendors most probably since why should they), maybe the guys behind https://h3droid.com