manuti

Interesting, maybe a packaging fix is needed.
 
No idea and won't look into further. Current situation is that most needed bits are part of Armbian repo, everyone can build/improve legacy images and wrt 'full support' we need a wiki page and some copy&paste work (using Beelink X2 mainline stuff it's mostly just that + testing which I can't since not owning the device).
 
Desktop and CLI image as well as 'support package' with individual packages: http://kaiser-edv.de/tmp/NumpU8/
45a44de60feb7b388ad77c456ff58917 Armbian_5.34_Sunvell-r69_Support_Package.tar.gz f3eb7ae54762e37df11a069d4193fddb Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113_desktop.img.xz 44fdbd858437df4c1cfce81f0d92a8a6 Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz (No Debian yet of course since Stretch needs a newer kernel than the smelly Allwinner 3.4)

Today I did try my very best... Opened the R69 (without breaking anything), solder the TTL-Pins, connecting USB-TTL -
BUT when I power on with the u-boot button pressed I didnt get any output to disable the u-boot boot-sequence
(normally counting 3.2.1 on other boards and you have to press a key)
 
So I can - today - only deliver the boot-log from android on the R69 and two find commands for *.bin and *.fex as android-root on the filesystem:
 
 

Of course. All data gone.
Nope, it's just metadata (small checksums used to verify data integrity) but no parity data like it's used with RAID5/6 and of course you can't reconstruct data from this type of metadata.
 
On H3/H5 boards that are limited by USB2 an interesting alternative could be a mdraid RAID10 with far layout using 2 disks (you don't need 4 for RAID10 and you should always use RAID10 if you wanted to use RAID1 on Linux in the meantime). This way you get full redundancy and protection against a drive fail while doubling at least read performance. This is an OPi Plus 2E with 2 SSDs in UAS capable JMS567 disk enclosures using a RAID10 with rather small chunk size (default ist 512K) and a btrfs on top:
mdadm --create /dev/md127 --verbose --level=10 --raid-devices=2 --layout=f2 --chunk=4 /dev/sda /dev/sdc RAID-10 made of Intel 540S and Samsung PM851 with 4k chunk size: random random kB reclen write rewrite read reread read write 102400 4 7044 7549 8654 8824 7058 7011 102400 16 14815 14508 25361 25344 21222 14731 102400 128 26835 26558 46249 47619 44310 26084 102400 512 26882 29306 51175 51847 51979 28552 102400 1024 29347 29960 51424 52177 52287 29056 102400 16384 30129 30715 74614 77384 78568 29954 4096000 4 36556 35967 81080 82749 4096000 1024 36335 35705 81314 81422  

This is strange. While the mainline kernel might not be as finely tuned as the legacy kernel, and the smaller boards are known to run hot, my experience doesn't seem to be typical.
 
These are my temperature readings from my OrangePi Zero v1.4 running the "next" build:
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 07:03:07: 240MHz 0.03 2% 1% 0% 0% 0% 0% 103.5°C 5/8 07:03:12: 240MHz 0.02 2% 1% 0% 0% 0% 0% 103.9°C 6/8 07:03:17: 240MHz 0.10 2% 1% 0% 0% 0% 0% 103.7°C 5/8 07:03:23: 240MHz 0.09 2% 1% 0% 0% 0% 0% 103.8°C 5/8 07:03:28: 240MHz 0.08 2% 1% 0% 0% 0% 0% 104.3°C 6/8  
Yet, it passes the "thumb test". The greatest reading I get with my cheap infrared thermometer is 42℃ but the average is around 37℃ (reading from both side).  It shuts down doing a simple "apt-get update".
 
Anyway, I'm just sharing for some extra context.

I don't get it, why they advertize it as suitable for H3 boards? H5 boards cannot speak LCD/HDMI or what?
Interesting thingy, definitely, probably I'll buy it someday. But now I have a 21" HDMI capable monitor bought specifically for my "playing" with SBCs.

Why?
 
Check https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829 for example to get a clue which advantages the more modern CPU might have if you need AES encryption (still needs real-world tests of course, the numbers there are just a comparison at 'proof of concept' level). Then these Marvell things are made for NAS and router purposes unlike tablet, phone and TV box SoCs on other SBC. CPU utilization for IO and network related tasks is often less compared to other platforms due to better internal design.
 
But if CPU horsepower is really sufficient depends on the types of applications of course. If the box should do video transcoding or also build kernels the HC1 will outperform Espressobin of course. That's one of the reasons I still look forward to more RK3328 variants since quad-core and most probably video transcoding possible HW accelerated using Rockchip's video engine. But still lack of IO possibilities of course.
 

Maybe Balena www.balena.io has a better support for your board. 

Softy worked perfectly!

@Da Alchemist
I prepared another test patch for multichannel audio support. Can you test it?
http://sprunge.us/gcbB

I preffer Lakka.tv:
 http://www.lakka.tv/get/linux/ 
with decent Orange Pi support http://www.lakka.tv/get/linux/opi/ 
https://raspberryparatorpes.net/sistemas-operativos/lakka-tv-mas-emulacion-y-retrogaming-para-torpes/

This is wrong, yes. Not expected to work since customize-image.sh has to be run as part of the build process. If you want to install OMV later you would today download softy, execute it and choose 'Install OMV':
wget https://raw.githubusercontent.com/armbian/config/dev/softy /bin/bash softy In a few weeks this is all part of next major Armbian release, then it's simply: armbian-config --> software --> Install OMV  (works today also but installation is not optimized so today better use the wget workaround above)

I have received it. It works for screen with HDMI to VGA adaptator on 1024x768 60Hz, that's very cool
I will continue the tests, I have some problems for other things (wifi, bluetooth...).

Great work with all the benchmarks! I greatly appreciate your job.
 
I don't know if I'm doing it wrong but instead of building the OMV image for my board (Orange pi One) I downloaded the pre-built jessie image from armbian website and run the customize-image.sh.template:
 
wget https://raw.githubusercontent.com/armbian/build/master/config/templates/customize-image.sh.template mv customize-image.sh.template omv.sh nano omv.sh # uncomment InstallOpenMediaVault chmod 700 omv.sh ./omv.sh jessie sun8i orangepione no Is it equivalent to building the whole image from ground up?
 
By the way, the above process fails because the space in the sd card becomes full.

There is some warning at first login that you need to reboot ... to expand SD card too full size. Is this the problem?

Yeah, I'll fix that. Usually I'm lazy when it comes to DT...
 
I tested it already. Just one line fix was required to make it work, which is already included on my github:
https://github.com/jernejsk/linux-1/commit/5de498da7efd4593976c4e41ca7367ac23352616#diff-0dd6c05e592804ae87e06c218a333a37R318

For what it's worth, and one of the most discussed topics can now hopefully finally closed: Mali in mainline
 
Did not try it, but the source is trustworthy to my humble knowledge... Still no open source release, but I guess it silences a lot of people questioning for Mali support!
 
For the real Mali die hards, here is a link to some more background info: Free Electrons

Another related to this topic. Rockchip VPU driver call for testings.

Yes, The OPiPC+ is one of my favorite, one of the reason is price/feature ratio, having eMMC is really nice.
I'm also using those in my daily job.
But, all my boards are headless, so I can't give hint about 3D stuff.
 
 

Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
 
For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
 
Driver should work (not tested), but DT must be updated.
 
Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.

No time wasted!
 
I thought today a little bit about why Armbian ships with such an anachronistic default configuration and whether it would be worth a try with more recent kernels to switch from swap to zram (and adjust vm swappiness since with vm.swappiness=0 most probably no one will ever see a difference).
 
An interesting test would be
sed -i 's/vm.swappiness=0/vm.swappiness=60/' /etc/sysctl.conf FILE=$(mktemp) wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb -qO $FILE && dpkg -i $FILE reboot But I've to admit that I don't know how to test whether something changes since I know swapping only as problem of the past. I've now 3 ROCK64 with different DRAM sizes. Maybe someone has an idea how a useful 'benchmark' could look like comparing different DRAM sizes?
 
 

I got the driver -it was not downloading 2 days ago but now it did so I will try it. I will update in a day or two. Hopefully I wont need your conf otherwise I will tell you waht to look  for. (For the 308 it should be at /etc/X11/xorg.conf -thats what their posts say). I will post back in a bit.

Helping with what?
 
BTW: I build custom debian (not raspian) images for the RPi for NAS projects (even if Raspberries are such lousy devices for this use case) and I try to ensure that this never will destroy the Armbian project.

Another small update on why settings/details matter. FriendlyELEC's NanoPi M3 isn't the best choice for a NAS since while featuring Gigabit Ethernet (+940 Mbits/sec possible) it has only USB2/Hi-Speed as potential storage interface and all USB2 receptacles are behind an internal USB hub (and have to share bandwidth therefore). So we're talking about 37MB/s max anyway with the MassStorage/BOT protocol and maybe up to 42-43 MB/s if USB Attached SCSI (UAS) would be available.
 
I tested a bit around with NanoPi M3 last year but since storage performance was already way too low (26.5/31 MB/s write/read) I didn't test NAS performance. Since we're in the meantime able to run this board with mainline kernel I gave it a try again: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=38120
 
Now we get a nice performance increase when testing storage locally: 26.5/31 MB/s write/read back then, now 35/37.5 MB/s (or 8.5/6.5 MB/s more). I had to make a minor correction to our build system to get decent storage performance with our chosen ondemand cpufreq governor too and the other important difference compared to situation with M3's 3.4 kernel is that with the old kernel IRQs are processed on all CPU cores in parallel while we can now choose fixed IRQ affinity (letting interrupts for various stuff be always processed on the same CPU core): https://github.com/armbian/build/blob/4f08c97d745892b6d664b96f8a4f84f48ee1f53f/packages/bsp/common/etc/init.d/armhwinfo#L255-L267
 
Without that fix it would look like this since all IRQs are processed on cpu0:

After fixing IRQ affinity and with the ondemand tweaks active (to get the CPU cores clocking up from 400 MHz to 1400 MHz instantly as soon as IO activity is happening) we're talking about:

 
This is not that impressive as with ROCK64 above where we get 15-20 MB/s more just by taking care of settings but it's a nice little performance boost we get for free (just by taking time and care of settings). What's missing is UAS support, given the Nexell SoC's USB IP can be UAS enabled (requires most probably changes to the USB host controller driver) we would get an additional ~5 MB/s in both directions. Then we would talk about 20/25 MB/s NAS throughput with the old kernel (and active IRQ balancing and inappopriate settings) vs. 38/39 (or even 39/40) MB/s with mainline kernel, fixed/optimized IRQ affinity and UAS.
 
Settings matter  
 

ODROID HC1 Mini Review
 
ODROID XU4 is one of the most powerful boards Armbian supports (due to being a big.LITTLE design with 4 x A15@2GHz and 4 x A7@1.4GHz). Though the SoC is a bit old performance is still impressive, the SoC features 2 independent USB3 ports (on XU3/XU4 one is connected to an USB Gigabit Ethernet chip, the other to an internal USB3 hub providing 2 USB3 receptacles) but in the past many users had troubles with USB3 due to
 
cable/connector problems (the USB3-A receptacle specification/design is a total fail IMO, unfortunately we've still not USB-C everywhere) underpowering problems with Hardkernel's Cloudshell 1 or XU4 powered disk enclosures and also some real UAS issues with 4.9 kernel (UAS --> USB Attached SCSI, a way more efficient method to access USB storage compared to the old MassStorage protocol)  
Hardkernel's answer to these issues was a stripped down XU4 version dropping the internal USB hub, display and GPIO support but adding instead a great performing and UAS capable USB-to-SATA bridge (JMS578) directly to the PCB so no more cable/contact issues, no more underpowering and no more UAS hassles with some disk enclosures (that contain a broken SATA bridge or combine a working UAS capable chip with a branded/broken firmware).
 
Thanks to Hardkernel I received a developer sample a week ago and could test/optimize already. I skip posting nice pictures and general information since as usual everything available at CNX already: just take a look here and there (especially take the additional hour to read through comments!).
 
So let's focus on stuff not already covered:

 
 
On the bottom side of the PCB in this area the Exynos 5422 SoC is located and attached with thermal paste to the black aluminium enclosure acting as a giant heatsink. While this works pretty well the octa-core SoC also dissipates heat into the PCB so if you plan to continously let this board run under full load better check temperature of the SD card slot if you're concerned about the temperature range of the SD card used Green led used by JMS578, starts to blink with disk activity and might be better located next to SD card slot on a future PCB revision for stacked/cluster use cases Blue led used as heartbeat signal by default (adjustable --> /sys/class/leds/blue/trigger but only none, mmc1 and heartbeat available, no always-on) Red led (power, lights solid when board is powered on) Drilled hole to fix a connected 2.5" disk. I didn't find a screw of the necessary length -- few more mm are needed than normal -- so I hope Hardkernels adds one when shipping HC1 to securely mount disks (7mm - 15mm disk height supported) Not an issue (was only one for me)! Hardkernel responded: 'We’ve been shipping the HC1 with a machine screw (M3 x 8mm) except for several early engineering samples. So all new users will receive the screw and they can fasten the HDD/SSD out of the box.'  
In my tests I found it a bit surprising that position of the heatsink fins doesn't matter that much (one would think with heatsink fins on top as shown on the right above reported temperatures would be a lot lower compared to the left position but that's not the case -- maybe 1°C difference -- which is also good news since the HC1 is stackable). The whole enclosure gets warm so heat disspation works really efficient here and when running some demanding benchmarks on HC1 and XU4 in parallel HC1 always performed better since throttling started later and was not that aggressive.
 
I had a few network problems in my lab the last days but could resolve them and while testing with optimal settings I decided also to move the usb5 interrupt (handling the USB3 port to which the USB Gigabit Ethernet adapter on ODROID XU3/XU4/HC1/HC2/MC1 is connected) from cpu3 (little) to cpu7 (big core):

As a quick comparison performance with same OS image but with XU4 and same SSD in an external JMS576 enclosure this time:
 
Tested with our Armbian based OMV image, kernel 4.9.37, ondemand cpufreq governor (clocking little/big cores down to 600 MHz when idle and allowing 1400/2000 MHz under full load), some ondemand tweaks (io_is_busy being the most important one) and latest IRQ affinity tweak. The disk I tested with is my usual Samsung EVO840 (so results are comparable with numbers for other Armbian supported devices -- see here). When combining HC1 with spinning rust (especially with older notebook HDDs) it's always worth considering adjusting cpufreq settings since most HDDs aren't that fast anyway so you could adjust /etc/default/cpufrequtils and configure there for example 1400 MHz max limiting also the big cluster to 1.4 GHz max which won't hurt performance with HDDs anyway but you'll have ~3W less consumption with full performance NAS workloads.
 
While this is stuff for another review it should be noted that DVFS (dynamic voltage frequency scaling) has a huge impact on consumption especially with higher clockspeeds (allowing the cores to clock down to 200 MHz instead of 600 MHz somewhat destroys overall performance but saves you only ~0.1W on idle consumption while limiting the big cluster's maximum cpufreq from 2000 MHz down to 1400 MHz saves you ~3W under full load while retaining same NAS performance at least when using HDDs). Also HDD temperature is a consideration since the giant heatsink also transfers some heat back into a connected disk though with my tests this led to a maximum increase of 7°C (SSD temperature read out via SMART after running a heavy benchmark on HC1 comparing temperatures on SSD attached to HC1 and attached to a XU4 where SSD was lying next to the board).
 
People who want to run other stuff on HC1 in parallel might think about letting Ethernet IRQs being handled by a little core again (reverting my latest change to move usb5 interrupts from cpu3 to cpu7) since this only slightly affects top NAS write performance while leaving the powerful big cores free to do other stuff in parallel. IRQ/SMP/HMP affinity might become a matter of use case on HC1 so it's not easy to find settings that work perfect everywhere. To test through all this stuff in detail and to really give good advises wrt overall consumption savings I lack the necessary equipment (would need some sort of 'smart powermeter' that can feed the results in my monitoring system) so I'll leave these tests for others.
 
So let's finish with first preliminary conclusions:
 
HC1 is a very nice design addressing a few of XU3/XU4 former USB3 issues (mostly related to 'hardware' issues like cable/contact problems with USB3-A or underpowering) Heat dissipation works very well (and combining this enclosure design with a huge, slow and therefore silent fan is always an option, Hardkernel evens sells a large fan suitable for 4 HC1 or MC1 units) The used JMS578 bridge chip to provide SATA access is a really good choice since this IC does not only support UAS (USB Attached SCSI, way more efficient than the older MassStorage protocol and also the reason why SSDs perform twice as fast on HC1 now with 4.x kernel) but also SAT ('SCSI / ATA Translation') so you can make use of tools like hdparm/hdidle without any issues and also TRIM (though software support is lacking at least in 4.9 kernel tested with) Dealing with attached SATA disks is way more reliable than on other 'USB only' platforms since connection/underpowering problems are solved Only downside is the age/generation of the Exynos 5422 SoC since being an ARMv7 design it's lacking for example 'ARM crypto extensions' compared to some more recent ARM SoCs which can do stuff like AES encryption a lot more efficient/faster  
Almost forgot: Software support efforts needed for HC1 (or the other variants MC1 or HC2) are zero since Hardkernel kept everything 100% compatible to ODROID XU4  
 
Edit: Updated 'screw situation' after Hardkernel explained they ship with an M3/8mm screw by default