manuti

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

As far as I know with Allwinner's H5 BSP an OPi PC 2 is still not able to clock higher than 1008 MHz since here voltage regulation is simply broken (it might have changed but I stopped looking into Xunlong's/Buddy's Github repo since causing headache).
 
FriendlyELEC chose NanoPi NEO 2 to be a fixed voltage SBC for this reason: since they couldn't get voltage regulation to work. Then in March Icenowy and me were talking to them and I mentioned that voltage regulation is working already with mainline kernel. They discussed internally, decided to drop BSP support for their H3 and H5 boards and since they now can make use of DVFS to also re-design both NanoPi Neo Plus2 and NanoPi M1 Plus 2.

I am getting exactly this one (2G/16G/Gigabit/dual band) to see how it will go.

It depends on your specific needs. Usually, it's never just about pure calculating power.
 
A theoretical comparison is usually bad way since you (can) have bad kernel/support on those big numbers and the board can still not be used for nothing but (Android) media player ... where top stability is not needed. There is usually no schematics for media players and therefore it's much harder to fix anything. And ... there will not be many people having this player since it's costly.
 
But. It can be better than this and you might get lucky. Sometimes some player works well I put my luck on Alfawise Z28 Pro since it matches chip on Rock64 where we are putting our efforts to. Not that powerful but with more chances of success.

Here you can find a reasonable support for the cheap Beelink X2 https://www.armbian.com/beelinkx2/ with 1GB of RAM and 8GB. It can be used as low profile desktop PC and can be more capable than you think with Linux.
But the BeelinkX2 have a small problem related to your idea, if you choose to replace Android with Armbian in the internal memory you loose also the access to the microSD card.
Here https://raspberryparatorpes.net/hardware/beelink-x2-primeras-impresiones/ you can see some pictures and the size compared to a Raspberry Pi and an Orange Pi One. 
Maybe is interesting to use a Orange Pi PC with case and a 64GB microSD card.

http://linux-sunxi.org/USB/UAS

You will need to ask that to Raspberry forum, because here, in the Armbian forum, there is NO support for Raspberries.
 

bonkers

And another small ROCK64/RK3328 update. We're still struggling with some USB problems (RK engineers are aware of and I hope we'll see a fix soon) but since ayufan in the meantime also creates OMV images for ROCK64 automagically I thought let's give it a try again. The settings we came up with the last 3 months here and over in OMV forum are almost all adopted but I ran into some minor glitches with ayufan's build. I had trouble with running rrdcached keeping all cores busy at 100% (had to deactivate it manually), then it seems /usr/local/sbin/rock64_fix_irqs.sh doesn't get executed at boot (this script does the usual tuning Armbian does in /etc/init.d/armhwinfo on all platforms -- a lot of time/efforts went into this over the years) and then also /var/lib/netatalk/CNID isn't handled by folder2ram which negatively affects some of the Netatalk performance numbers below (everything dealing with small files/requests).
 
Also /etc/cron.d/make_nas_processes_faster doesn't work, also manually trying to set I/O scheduling class and priority has no effect (maybe a missing kernel config?).
 
Anyway: executing the /usr/local/sbin/rock64_fix_irqs.sh script increases NAS throughput numbers by 15-20 MB/s and even if not all tunables work right now and we will get 1 or even 2 USB3/UAS fixes it now looks like this (first test made with JMS567, 2nd with ASM1153 powered by ROCK64):


Identical performance (every variation below 5% is identical!) and since CNID database currently lives on the rootfs which is on a SD card the numbers for 'create' and 'lock/unlock' will automagically decrease once folder2ram will take care of the CNID databases. With Windows Explorer or macOS Finder sequential transfer speeds exceeding 100 MB/s should already work (see here why/how LanTest test results differ)
 
 

There's a reason Apple sent truckloads of engineers to USB Implementers forum technical commitees for 'next generation connector' and power delivery specs to avoid such BS (or that Micro USB crap). But it will take some time until we see USB-C everywhere -- especially implemented correctly  

Another update wrt upcoming ROCK64 board. It's still not decided whether Armbian will support this board anytime soon or at all but NAS results already look promising. USB3 performance is excellent (outperforming ODROID-XU4 easily) but currently we have discovered a few network issues while testing/evaluating the board (most probably we need to tweak so called TX/RX GbE delay settings).
 
But even without this tweak it already looks as follows:
 
These are the 'Enterprise network settings' (test size is 3GB and transmission block size 1MB):

These are 'Gigabit Ethernet' settings with just 300 MB filesize and 128KB blocksize:

It's pretty obvious that there's something wrong with network settings when we look at the sequential transfer speeds. Just compare with Pine64 above where USB2 storage is the bottleneck: there the test with 300 MB filesize runs entirely in RAM and Pine64 scores 66/78 MB/s write/read, with the Enterprise settings speeds drop down to storage performance: ~38MB/s in both directions. With ROCK64 all tests run entirely in RAM (I test with the 4GB model) and there's a significant drop in transfer speeds if we compare 1MB with 128KB blocksize.
 
My settings (TCP/IP offloading deactivated, eth0 IRQs on cpu3, USB3 IRQs on cpu2, performance governor, Receive Packet Steering enabled):
root@rock64:~# tail /etc/rc.local echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for i in 1 2 3 ; do echo 4 >/proc/irq/$(awk -F":" "/xhci/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity echo 8 >/proc/irq/$(awk -F":" "/eth0/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity done echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 >/proc/sys/net/core/rps_sock_flow_entries echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt exit 0 root@rock64:~# cat /etc/network/interfaces.d/eth0 allow-hotplug eth0 iface eth0 inet dhcp offload-tx off offload-rx off hwaddress ether 42:40:08:16:da:2b The good news: This all is still WiP (work in progress) and I'm pretty confident that we see a performance boost in both directions soon (15-20 MB/s more each -- with Windows Explorer throughput numbers exceeding 100 MB/s should already be possible with appropriate OMV/Samba settings -- see here for an example and here for an explanation why Explorer performs better)

What about thinking about (discussing) update procedures? Armbian has default, next and dev variants while the distros are horribly outdated (stable, stable, stable) but for whatever reasons Armbian tries to introduce update drama every few months. Why exactly?
 
I'm a big fan of users testing stuff if they have been warned they're using experimental software. But if users choose to use something called 'stable' why can't Armbian provide something stable?
 
What about differentiating between next (somewhat stable LTS release) and dev (latest and greatest mainline kernel)? Applies even more to u-boot updates (this one -- BTW users and 3rd party image builders don't get it if we remain polite, they simply ignore the contents of the message)

Time for a small '2017 follow-up' on this issue this time only focussing on 'disk performance' (HDD/SSD, not onboard storage like eMMC or SD cards).
 
Since we all know that we don't need to differentiate here between individual boards but can look at board families (the SoC is the important thing) I only check the following 'families':
cheap Allwinner stuff running with A64 or H5 (that's the Pine64 numbers below, H3 boards score a bit lower) Allwinner A20, R40 or V40 (that's the Banana Pi Pro numbers below, maybe random IO numbers look better with the R40/V40 boards but since those are only available from manufacturers also known as brain damaged retards that's not an option today) i.MX6 (Wandboard Quad, not supported by Armbian but a few other boards using the same SoC) Exynos 5422 (ODROID XU3 or XU4) RK3328 (ROCK64) Armada 38x (Clearfog Pro, same numbers will apply to Turris Omnia, Clearfog Base or Helios4 soon) Why are all other boards missing? Since uninteresting if it's about storage. SATA or USB3 are a must, the only exception below are the UAS capable USB2 Allwinner devices since they show a few more MB/s sequential throughput and way better random IO numbers compared to USB2 solutions that only support the old/anachronistic USB Mass Storage mode.

All tests done with Samsung EVO SSDs (my EVO840 used for all tests except of the ODROID-XU4 results which were made with a much faster EVO850 instead and Pine64 numbers with a slower EVO750 so random IO numbers should be multiplied with 1.3 or even 1.4):
                      Random IO in IOPS     Sequential IO in MB/sec                         4K read/write           1M read/write Pine64 (USB2/UAS)         2260/1948                42 /  41 Banana Pi Pro (SATA)      3943/3478               122 /  37 Wandboard Quad (SATA)     4141/5073               100 / 100 ODROID-XU4 (USB3/UAS)     4637/5126               262 / 282 ROCK64 (USB3/UAS)         4619/5972               311 / 297 Clearfog Pro (SATA)      10148/19184              507 / 448 Testing methodology is somewhat wrong but I refuse to waste much of my time to do proper benchmarking since it's only about getting the idea what to expect. So as a summary:
USB2 SBC that lack UAS capabilities are simply too slow to be even listed here UAS capable cheap Allwinner USB2 boards show ok-ish performance for low-end setups (think of NanoPi NEO2 as NAS for example) SBC featuring 'real SATA' have to be differentiated. Armada 38x shows top performance like x86/x64 boards, i.MX6 is somewhat ok, A20/R40/V40 simply suck (you better don't buy this crap any more) USB3 SBC like ODROID-XU4/HC1 or ROCK64 show way better performance. You only have to take care of the USB downsides (XU4 with an internal USB hub and receptacles problems is in a bad position here) and ensure that you're using good USB-to-SATA bridges to connect SSD or HDD If we also take price/performance ratio into account then ROCK64 or other RK3328 boards that will follow are really hard to beat. The 1GB ROCK64 variant will most probably stay below the $25 margin and you should keep in mind that more DRAM is pretty useless if you think about (NAS) performance. Only on devices where IO throughput is way lower than network throughput having more DRAM as needed might improve NAS write performance if settings are appropriate (since then amounts of data that fit into RAM will be written at network speed and flushed later to disk)

As in depth as this discussion went I can see that a lot of you are way beyond my level. But this is also the 1st result for a search on "OrangePi NAS Review" so I would like to point people to the review I did for those who are interested in this product. You can find it here.

Allright, now wifi it works after running
 apt-get install linux-u-boot-bananapipro-next linux-image-dev-sunxi linux-headers-dev-sunxi  linux-dtb-next-sunxi linux-jessie-root-bananapipro armbian-firmware-full -y
 

As you can imagine, my time & know how (in this area) is somehow limited, but if it helps you and other developers to do the hard stuff that I'm for sure not able to do, we can give it a try. 
 
I see the point, maybe something to consider as soon as more important issues are solved. I'm still impressed by the FriendlyArm wiki, but for sure the have much more man power to do that.  

Yes, because it's deprecated. Updating on our system is: apt-get update && apt-get upgrade

Conclusions:
 
- nightly kernel and BSP building yes, nightly images once per week
- focus more to provide simpler way for new developers to get in
- nightly images should be carefully picked to provide best "price performance" ratio
 
and another proposed actions:
 
- moving another three boards (Lamobo R1 / Cubieboard 1 / Lime A10) into deprecated sessions. All those boards get one last update with last known working configuration and frozen kernel packages
 
 
This a current project overview, which we try to follow. Is this time span perfectly o.k. ? Not sure. We will need to adjust it in the future, but it’s something to go with and stick to it, when and if we agree:
 
UPCOMING MILESTONES
Milestone Responsible Person Due On Feature developement --- Due in 81 Days Feature freeze --- Due in 90 Days Beta testing and bug fixing --- Due in 130 Days Writing release documentation --- Due in 142 Days Launch --- Due in 149 Days Withing project management we manage to establish fully operating testing system – a person get’s an email, when and what to test – his report is clicking few check boxes + adding a note when necessarily. Technology was tested twice and it works, methodology needs broad discussion. Project manager is the one, who has overview and drive (volunteer) developers to fix this and that. In reality this means I was driving myself and Michael was assisting in this and solving problems which are out of my league. Since we were also testers, most of bugs were saved already on the way ...
 
 
Project management is yet another full time position, which waits to be filled developed and filled in. We deliberately use this hidden, because I was not sure if it’s the right way to go, because not everybody needs to  be involved in everything and because not finished products are better to hide. Check email.
 
Until there is no somebody who will take a full lead on this, I am moving it forward with (my) highest possible speed. Well, in fact it's already we. Tido is helping in this beta trial process.
 
 
We can add text to forum description, which board are officially supported – I know people will still fail to see.
 
 
Yes. This is at least much simpler to support and is to consider.
 

Yeah. At least we are highly motivated to end / limit at best as possible.
 
 
We would certainly need more moderators, which would take care of such questions appropriately. Technical knowledge about those boards is not a requirements. If @chwe wants to take care of general moderator duties, he is one click away
 

This is fine, but very hard to maintain.
 
The rest elsewhere. This one is already off topic.

Ok, I'm now only answering to the question 'board support decision'. We support already too much boards, a lot has changed in 2016 and in 2017 again and we just ignore this until Armbian project will collapse.
 
Who decides whether a new board will be supported? Is it you? Is it 'us'? If the latter who are 'we'? Is it a random hardware vendor just shipping some dev samples and trusting in 'Armbian morons' doing his job for free?
 
We're acting like the latter today.
 
We work on boards for which ZERO Armbian use cases exist (Orange Pi Zero Plus 2 H5 or however this unbelievable f*cking stupid name is written exactly, at least it's absolutely STUPID to bring Armbian to this board since the only possible use case is 'Desktop Linux' since this board unfortunately has HDMI but just 512MB DRAM which is simply not enough for a 64-bit Linux running a Desktop environment, for H5 we've only mainline kernel since H5 BSP is such an INSANE crap so not even video acceleration will work here. It's STUPID to bring Armbian to this device but we do it).
 
We work on boards that are not even supported by the hardware vendor. For example this BPi M2 Ultra thing, those SinoVoip folks only provide incorrect information (see DRAM timings, they write 733MHz, use 648 MHz but the SoC's memory controller supported 576MHz maximum --> reference, reference, reference look at the 'Technische Daten' PDF there, those irresponsible morons advertise this board with CPU @ 1.5GHz, DRAM at 733 MHz, Mali GPU at 500 MHz while in reality all numbers are way lower. Do we want later 'bug reports' that tell us 'Great Banana Pi M2 Ultra is able to run at 1500 MHz, Armbian is broken since allows only 1200 MHz'?!), those morons as usual do not even care about schematics being correct ('In schematic you can see two uart2 ports.'), they never release schematics timely, they're known to send out defective developer samples and they're either too stupid or too ignorant to get that this is a real problem.
 
And what do we do? We ignore that and play morons happily working on bringing support to their boards so they are ensured their behaviour is totally OK and nothing needs to be changed. We behave like the greater morons than them since they succeed with their irresponsible behaviour since some community idiots are doing their job for free even if they actively hinder us all the time (incorrect information/schematics, defective board samples, no changelog for hardware changes).
 
That's the whole purpose of a 'board bring up' DISCUSSION (that was the Rock64 example). Weighing pros/cons, benefits for users and developers, documenting what's missing (eg. incorrect information/schematics -- maybe even the most stupid board maker will get the idea he has to improve in this area if all his boards are rejected for the same simple reason: him behaving like an irresponsible asshole)
 
Board bring up is fun, board support is boring but more important depending on how we look at the Armbian project (playground vs. providing a distro able to run serious stuff). We have to reduce the number of supported boards but instead we add more and more. Unless such discussions start all babbling is useless anyway (eg. whether to differentiate .playground boards from .wip boards that will at least get support eventually since we came to the conclusion that it's worth the efforts in the beginning).

And Armbian released 5.30 yesterday and ships with Chromium with sandboxing completely disabled (bad) even if we knew better, see my post above from 6 days ago that got ignored. 
 
Is it really necessary to mark @Igorand @zador.blood.stainedin every post where I need an opinion since removing '--no-sandbox' switch from chromium config would require
changes to a few kernel configs tests with Chromium later To be honest: To me the whole 5.30 release came as a surprise especially since a few open issues exist(ed).

Firefox 54 finally goes multi-process, eight years after work began
https://arstechnica.co.uk/information-technology/2017/06/firefox-multiple-content-processes

Repository just bumped to 5.31 which should fix the problem of this topic - updating. Affected images are in process of replacing.

The more I test, the less I know  This test image works fine on M1+, while network doesn't come up (properly) on: M1, PRO and R1

I support the idea of protocol - if this is meant that way - but honestly I haven't been able to catch up - only quick scan. 
 

My impression is different. A lot has been done, but also a lot can be done. The question is, what do we want and can we afford? Some things were made wrong, but in general we don't waste that much time either (if we rule out supporting Orange Pi zero wireless, similar pointless cases and perhaps support in general). We are already at a limit of what we can do with resources we have and that is one of the primary reasons, why all things weren't done yet. Even we cut off half of the board support ...

There is more than just clear comm and few rules to achieve greatness.

20 tools, each covering one aspect of a community or group by Pieter Hintjens:
 

 
 
It could have impact or not. Perhaps our way of doing is too good, strict or perfect? It depend from which perspective do we look. I know that current scenario of engagement is not ideal and needs change if we don't want to get crazy and to level things up. This takes time and energy and we are going from one large project to another without stop. I see that more problematic than we failed to implement some protocol or feature.
 

Actually we did testings, but this kind of issue could be found only if all boards were tested. We are not on that level, even 5 people (we have 8 people in total for testing from last call, but theirs board diversity is another problem) responded to assigned tasks. Testing protocol was not fixed yet, since we need few real world experiences, before we know what is important and to wrote all this down.
 
We need to divide stable and latest builds, freeze non critical stuff (u-boot), ... yes. 

I'll fix recent upgrade problems, when I'll fully understand them, but first I would need to get some sleep and recharge. I removed failed u-boot from repo but images for bananas are failed too.

'OMV image' is nothing special, that's just a Debian Jessie Armbian image with mainline kernel and 'OpenMediaVault' installed by default. But 'sudo nmtui' should work on every board with onboard Wi-Fi that is listed as fully supported (potential exception: Tinkerboard but here I don't know why this board has status 'supported' and not still 'WiP')
 
Wrt default behaviour: on most boards we use a default config where eth0 is configured the 'old way' (interfaces file) so Wi-Fi is handled by network manager. This ensures that the forum is not flooded with 99 percent 'There is no interfaces file! Armbian is broken! WTF?!' threads but allows for easy Wi-Fi setup (nmtui). To get 'laptop behaviour' (use Ethernet if available and do a fallback to Wi-Fi if possible otherwise) eth0 should be removed from interfaces file (impossible since it will take another decade until at least 50 percent of Linux users accept that Network Manager is not entirely evil) and a lot of users run into troubles when connecting eth0 and wlan0 to the same network (the 'Ethernet only works when Wi-Fi is connected' drama).