willmore

Igor, yes, I think the issue is the 'how to communicate this better' problem.  I understand your situation and I appreciate all of your work.  Let me add my perspective and the motivation that lead me to ask my question.
 
In this thread we see that there is a desire to have a working Linux distro for the Opi Zero 3.  Armbian is a great starting point--plain Debian would work as well, but Armbian has some SBC specific customizations that make it more appropriate--so that's what people tend to use.  Someone pointed out there was a mostly working version available.  They and others have been working for months to try to improve it.  I think all of this is a simple distillation of facts and it's in dispute.
 
Where there seems to be some issue is motivations.  I don't know the person who made the original port--"leeboby" on github.  I don't know what their long term intention is.  Maybe they are interested in their port becoming official and taking over an official Armbian maintainer role.  Maybe it's just a 'fire and forget' effort they did for some reason.  I don't know.  But the people here would clearly like to move towards some kind of more official board support under the Armbian umbrella.
 
To that end, the question was asked if there could be a board specific sub-forum created for this clearly unsupported board so that conversations about an unsupported board wouldn't 1) pollute the general unsupported board forum 2) make it clear that it was unsupported (to manage peoples expectations) 3) make it easier for people to find information on the effort to get this board supported by Armbian.  Having a sub-forum would help provide a sense of community and help develop interest in the effort.  *with hope* a maintainer would be attracted to or developed by this community.  As you point out, this is a completely volunteer effort.  I see people in this thread (before the split) who are showing interest in doing volunteer work.  I though I reasonably could expect a community manager to encourage the development of a community--in this case by creating a sub-forum for the board under the unmaintained board/sun-xi forum.

So, the question I though was being asked is "can this effort find a space to work?"  What you heard was "support this board!"  Your reply was "we aren't going to support that board without a maintainer".  What I heard was "we have no interest in assisting in your effort to support this board".  So, let me ask a better question now that I hope we all have a better shared understanding of the context of the question.

Is there a place in these forums for efforts to create support for currently unsupported boards to work?  It would need to be such that it's very clear to anyone participating that *the board is not supported and might never be supported by Armbian and that it's simply a community effort to try to reach that goal*.  I hope that addresses your concerns with people trying to abuse Armbian for support of other peoples ports.

If the answer is no, that's fine, this is your forum and it's up to you to decide how you wish it to be used.  I simply wanted the proper question to be asked so that we all knew what was being asked.
 
I just hope there's a way to collect community base interest and effort and channel it into something that makes Armbian better.  Thank you for all of your work and specifically the time you've taken to address this question of mine.

There are other issues too (interrupt frequency being too high for example). All the ths patches in my ths-5.3 tree are probably the latest and the most debugged code for thermal sensors on H6 and other soc atm, since the last version (v5) was posted to mailing list by Yangtao Li.

This is a known bug in the THS driver. Fix is:
https://megous.com/git/linux/commit/?h=ths-5.3&id=555de6dfd8d7473d37e07047cb576accb620f896

Okay, I took a multimeter to my NAS board.  There isn't conductivity between the host side power and the jack on the board.  There are two diodes in parallel that isolate the NAS board jack from the 5V the host provides.  The diodes are in the direction that the jack *could* supply power back to the host.  The two diodes are Schottky devices, so the voltage drop through them should be fairly low for the currents the Z can pull.  That might be different for an H5 based host.
 
@tkaiser, you probably have better data on that.  My general observation is that the Z uses around half the current of the PC2.
 
I'm going to try powering things on soon.

Hello, all.  My second OpiZ came today and brought a friend--a NAS shield.  I posted about it over in the "OpiZ comes to market" thread, but it probably makes more sense to talk about the NAS side of things over here and leave that thread OpiZ related.
 
Just looking at the board gives me the same questions as logjamin about the DC power.  Clearly it makes sense to put a 5V jack on the NAS board as getting power over a micro-USB connector->GPIO header->JST connector->drive is suicidal for your data.  I am curious if the 5V jack on the NAS back feeds the OpiZ.  If so, that removes one of the annoyances of the Z--power over micro-USB.
 
The kit I got came with three each: short male/female standoff, long female/female standoff, wide head screw.  The problem is the flange around the head of the screw is so big that it bumps into the SATA connector right next to it--the other two holes have sufficient clearance.  If they had stuck with using a second M/F standoff like in the picture at the start of this thread, all would have been fine.  Trying to save a penny.....  I clipped a small part of the screw flange off so that it could safely clear the SATA connector.
 
I think I'm going to take the board back off and probe out the GPIO connector to see about the DC power issue.  Surely they wouldn't expect the Z and the NAS to have separate power feeds.  That leads to so many grounding problems, it's not funny.
 
@tkaiser, you've asked this in a couple of threads and no one answered you, so I'll take a swing at it.  Yes, you *could* put USB3 over a GPIO header.  Most PC motherboards with USB3 have a header on them for a set of front pannel USB3 jacks.  So, it is doable.  Now, the spacing of the pins and the arrangement of them is likely to be sensitive and need some though (steal the layout the PC motherboards use ).  So, a higher performing NAS hat could work that way.
 
Heck, I should go look into that in more detail....  It might be as easy as adding the extra SS signals on another row of that connector which could yield a backwards compatable setup--where the new NAS board works on older 1x13 hosts and a 2x13 host can work with the old 1x13 NAS board.  Hey, Steven, you listening?  I'll test them for you?  Of course, we'll need a SoC with USB3.....
 
Okay, that's enough rambling.  I'll go fiddle around with the board and see what I can find out.

They were always hardcoded, it's just that the sunxi legacy kernel has some hacks and closed source blobs that allow reconfiguring the DRAM frequency on the fly.
 
"Should" is subjective here. Since nobody tried to implement this yet you can assume that developers think that this is not necessary or can't be reliably or cleanly implemented.

Yeah, but that's all just due to some of my personal superheroes doing such a great work (talking about especially icenowy and you right now). Thank you BTW
 
But still it's a huge problem with Allwinner SoCs that we can't use what board or chip makers provide (at least not without wasting insane amounts of time to turn Allwinner's BSP crap into something useful like longsleep did two years ago). And then there's the insanely time consuming mainline upstreaming process...

2018 SD card update
 
It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)
 
Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.
 
Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one  Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.
 
Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.
 
A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).
 
I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:
1K w/r 4K w/r 16K w/r Crappy card 4GB 32 1854 35 1595 2 603 Samsung EVO+ 128GB 141 1549 160 1471 579 1161 Ultra A1 32GB 456 3171 843 2791 548 1777 Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Extreme Plus 16GB 566 2998 731 2738 557 2037 Extreme Pro 8GB 304 2779 323 2754 221 1821 (All results in IOPS --> IO operations per second) For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..
 
What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)
MB/s write MB/s read Crappy card 4GB 9 15 Samsung EVO+ 128GB 21 65 Ultra A1 32GB 20 66 Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Extreme Plus 16GB 63 67 Extreme Pro 8GB 50 67 Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:
1K w/r 4K w/r 16K w/r Ultra A1 DDR50 449 2966 678 2191 445 985 Ultra A1 SDR104 456 3171 843 2791 548 1777 1K w/r 4K w/r 16K w/r Extreme A1 DDR50 740 3049 1039 2408 747 1068 Extreme A1 SDR104 833 3289 1507 3281 1126 2113 We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)
 
Some conclusions:
When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria) We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1') Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund. TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.
 
Finally: All detailed SD card test results can be found here: https://pastebin.com/2wxPWcWr As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size: https://pastebin.com/ePUCXyg6

Then it should be called "DFS" instead 
And yes, frequency switching should work on those images, as I remember the main problem was with the regulators (the "V" part in DVFS), and since AW refuse to provide the ARISC firmware sources it was never fixed.

Fortunately, VPU driver is around 95% usable also for newer SoCs.
 
I have a feeling that H6 support will become useful a bit quicker.

If you want a KODI box why not asking the KODI guys?
Bootlin is today working on Allwinner SoCs that are horribly outdated (A33 being the only expection somehow, the others are A10, A13 and A20 from 5 to 8 years ago). They're all ARMv7 and support for Allwinner SoCs that are just outdated (A64 and H5) will come later. According to their Kickstarter page at the end of Dec 2018 if they succeed.
 
Welcome to the Allwinner reality. Get the hardware, be able to use only a shitty Android or crappy Android/Linux hybrids, wait for software support becoming mature (100% relying on community) and use the hardware as intended when it's already obsolete.

This feature cost 30.000 EUR and will be implemented free of charge when it is delivered  You can find detail info on that page.

Only some 'MHz fanatics' were really concerned. Or to be more precise: people who do not understand the difference between performance and clockspeeds and who also do not understand the challenges to run chips at high clockspeeds (both consumption and heat increase a lot). Again: https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/#comment-530956 (there you can also read what happened then in detail to get more control over clockspeeds on C2)
 
If I'm concerned about performance I need a use case first and then I test for performance with this use case (and don't rely on theoretical clockspeeds since this is plain stupid). That's what both Willy Tarreau and @willmore did unlike those people who for whatever reasons bought an ODROID-C2 instead of an RPi 3 due to '2 GHz' vs. '1.2 GHz' (those people exist en masse). So it was pretty obvious once that happened that an A53 'clocked at 2 GHz' performing like one clocked at 1.5 GHz is just that: limited to 1.5 GHz. So what? This is on those devices always the result of consumption and thermal constraints so why bother?
 
Since I mentioned 'use case' and Raspberry Pi 3:
If you need the performance for a use case called 'AES encryption' (VPN, full disk encryption, stuff like that) then looking at clockspeeds is what? Plain stupid as usual! Both ODROID-C2 regardless of being able to clock at 2 GHz or just 1.5 GHz performs as crappy as the RPi 3. They both do not support ARMv8 Crypto Extensions and perform magnitudes slower than any cheap NanoPi NEO2 or Orange Pi Zero Plus running at below 1 GHz CPU clockspeed: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 RPi 3 is the SBC with the most screwed up DVFS/cpufreq/clockspeed situation. The problem should be well known since 2015: an awful lot of RPi suffer from underpowering and run then frequency capped (limited to 600 MHz). But just like in situations when throttling is happening the kernel has not the slightest idea at which clockspeed the CPU cores are running and reports bogus values like 900 MHz on RPi 2, 1200 MHz on RPI 3 and 1400 MHz on RPi 3+ while in reality being limited to 600 MHz. Is this 'cheating' or at least a problem? Not when your target audience is only absolutely clueless people (RPi users). They're happy to achieve top clockspeeds only in idle and being limited to 600 MHz once performance would be needed and even start to complain once they are made aware of the real problem (seriously: check this link, it's unbelievable)  

done, maybe your first hijack post should also be here.. but it somehow good in both threads.. 
 
For me an more interesting point is that RPi hides 'all the magic' behind threadX, but we have somehow a similar situation with Amlogic when they only provide blobs for hardware responses/interaction.
 
Part of me thinks that people who buy by  >GHz=better performance deserves it to get cheated on, but from my more serious side... It's not the right thing to cheat on your customers.. Remember the shitstorm apple got for the clockdown of their older iphones when the battery got bad? It's not that it is the false thing to avoid that you users got fooled by a bad battery, but it's completely wrong to not inform your users that this happens. If the s912 can only reach 2GHz in a single core mode, I'm fine but lie to the customer is a shot in your own knee. It needs a lot of time to rebuild your reputation, probably not that much an issue for the 'cheap as hell' tv box, but in case you want to be one of the 'premium' TV-Box SoCs it gets problematic.  They have a nice SoC for TV boxes with a VPU which seems to be powerful enough for a lot of this use cases. So no need for cheating. 
 
99.9% irrelevant..  (assuming that 'few' is in the same range than the multiple of millions) [/smartass mode off]. IMO the main reason you should care about linux users is that you also get free development from experienced kernel developers. E.g. Allwinner could rebase their android kernel on a mainline kernel where a lot of their SoCs features are properly mainlined and then add their 'crap' to have an enhanced recent kernel... I'm somehow fascinated that the linux-sunxi community is so patient in mainlining their SoCs even when AW showed multiple times that they don't care (I know they stopped to actively avoid people from contributing by sharing parts of the documentation but they could do it better without that much effort).. 
 
IMO the 'next' generation of TV boxes will combine something like TV-box (with recording function) and cheap home NAS with acceptable performance. People don't want to have multiple devices for such tasks, so at least USB3 or a sort of pci is a must, that's where I see the H6 in front of the current Amlogic SoCs (despite the fact that their PCI implementation seems to be 'broken by design' and I don't know how well their VPU stuff performs). The RK3328 seems to be developed with this use-cases in mind and might perform well. Imagine an adroid TV-Box with something like OMV working in the backgroud which can be configured through the gui or browser... I'm sure.. people would buy it..  If you have all the graphics/decoding stuff on the GPU/VPU, the CPU should be fine to handle some server tasks in the background without affecting UI and their applications that much. 

I would call the price/performance not good but simply awesome today given we get ultra performant cards like the 32GB SanDisk Ultra A1 for as low as 12 bucks currently: https://www.amazon.com/Sandisk-Ultra-Micro-UHS-I-Adapter/dp/B073JWXGNT/ (I got mine 2 weeks ago for 13€ at a local shop though). And the A1 logo is important since cards compliant to A1 performance class perform magnitudes faster with random IO and small blocksizes (which pretty much describes the majority of IO happening with Linux on our boards).
 
As can be seen in my '2018 A1 SD card performance update' the random IO performance at small blocksizes is magnitudes better compared to an average/old/slow/bad SD card with low capacity:
average 4GB card SanDisk Ultra A1 1K read 1854 3171 4K read 1595 2791 16K read 603 1777 1K write 32 456 4K write 35 843 16K write 2 548 With pretty common writes at 4K block size the A1 SanDisk shows 843 vs. 35 IOPS (IO operations per second) and with 16K writes it's 548 vs. 2 IOPS. So that's over 20 or even 250 times faster (I don't know the reason but so far all average SD cards I tested with up to 8 GB capacity show this same weird 16KB random write bottleneck -- even those normal SanDisk Ultra with just 8GB). This might be one of the reasons why 'common knowledge' amongst SBC users seems to be trying to prevent writing to SD card at all. Since the majority doesn't take care which SD cards they use, test them wrongly (looking at irrelevant sequential transfer speeds instead of random IO and IOPS) and chose therefore pretty crappy ones.
 
BTW: the smallest A1 rated cards available start with 16GB capacity. But for obvious reasons I would better buy those with 32GB or even 64GB: price/performance ratio is much better and it should be common knowledge that buying larger cards 'than needed' leads to SD cards wearing out later.
 

Since LEDs are current devices,  they cannot be easily controlled in the voltage domain. So if you do not want to do pwm control, then you need to do current control.  PWM control is a lot easier!
You need to use a driver circuit to control your LEDs.  That can be as simple as a uln2803 chip, or a complicated current limiting discrete circuit.
First figure out what the voltage is you need to control, and the total amount of current. Then we might be able to help.

Remember. This is open source project running by amateurs and not enterprise-grade service.  Go to GitHub and monitor progress. 
 
We always write major changes to release documentation. 
 

Didn't you notice this?
* packaged versions might be slightly older than in this table!

Adding unreliable overclocking settings on Allwinner and Rockchip devices is unfortunately pretty easy (and the proposed patch looks wrong already in the first line since increasing cpufreq by 100 MHz without adjusting the voltage at all). That's why stuff like https://github.com/ehoutsma/StabilityTester exists. Feel free to try it out, @ErwinH used the tool to develop a sane DVFS OPP table last year for Orange Pi PC2 with this (since we found out that this highly optimized Linpack is a great way to check for DVFS undervoltage caused instabilities already before the board freezes/crashes. That lesson was learned when dealing with unreliable overclocking on Pine64 before)

exquisitus, I don't see how jhpadjustable's reply was patronizing, prejudiced, or full of attitude. He politely said that if you want to know the history of the module (and why it's not well supported) there are other threads talking about it. I really don't see how his reply is "less useful than no reply at all" since he told you where you can find more information (something you can also do with the forum's search feature).
 
When people here provide information to users, and then get replies like yours, it's no wonder the driver situation doesn't improve. Anyone who is working to make it better just gets people coming and being offended by their answers.
 
If you're unhappy with the state of the XR819 driver, I have the perfect place for you to go to solve your problems: https://github.com/fifteenhex/xradio/pulls
 
I hate to say it, I really do, but I think you need to see this: https://www.youtube.com/watch?v=F-mju_gW3c8

As a user and not a dev, I'd like to add that I'd much prefer that a distro be stable than faster-and-unstable.  For an experienced user, I know I can fiddle with these values and characterize the abilities of *my* particular boards if I want to take the time.  For an unexperienced user, an increased chance--howerver small--of the software making my hardware unstable is unacceptable as I'm likely already chasing a bunch of problems of my own creation--the aforementioned SD and power problems being primary amongst them.
 
That's my long way of saying, please choose 624.

Hmm  I installed the 672Mhz-orangepizeropluversion with --force-all on my NanoPi Neo2 - now after reboot he didnt get up anymore to ssh in
Now I have to unscrew the NAS... 
root@nanopineo22:/home/guido/uboot_test# dpkg --force-all -i ./linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb dpkg: regarding .../linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb containing linux-u-boot-orangepizeroplus-next: linux-u-boot-nanopineo2-next conflicts with armbian-u-boot linux-u-boot-orangepizeroplus-next provides armbian-u-boot and is to be installed. dpkg: warning: ignoring conflict, may proceed anyway! dpkg: regarding .../linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb containing linux-u-boot-orangepizeroplus-next: linux-u-boot-orangepizeroplus-next conflicts with armbian-u-boot linux-u-boot-nanopineo2-next provides armbian-u-boot and is present and installed. dpkg: warning: ignoring conflict, may proceed anyway! (Reading database ... 35468 files and directories currently installed.) Preparing to unpack .../linux-u-boot-next-orangepizeroplus_5.34_672mhz_arm64.deb ... Unpacking linux-u-boot-orangepizeroplus-next (5.34) ... dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite '/usr/lib/u-boot/LICENSE', which is also in package linux-u-boot-nanopineo2-next 5.34.171118 dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite '/usr/lib/u-boot/platform_install.sh', which is also in package linux-u-boot-nanopineo2-next 5.34.171118 dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite '/usr/lib/u-boot/LICENSE.atf', which is also in package linux-u-boot-nanopineo2-next 5.34.171118 Setting up linux-u-boot-orangepizeroplus-next (5.34) ... Updating u-boot on /dev/mmcblk0 root@nanopineo22:/home/guido/uboot_test# reboot [EDIT] because I didnt know how to roll that back: I reinstalled the NanoPi Neo2 
45 minutes with Standard-Installation and some reconfiguration... I think I have to create a Checklist for installing
Music and NAS is running again.

@tkaiser NanoPi Neo2 with debian stretch:
Linux nanopineo22 4.13.13-sunxi64 #214 SMP Thu Nov 16 01:52:21 CET 2017 aarch64 GNU/Linux
as attachment
 
NanoPi_Neo2_tinymembench.txt

Ok, switching from 408 MHz DRAM clock to 624 MHz on OPi Zero Plus (still cpufreq limited since DVFS not working, I'm running at 1008 MHz but can consider myself lucky since we've seen H5 boards that get instable at 1008 MHz with 1.1V VDD_CPUX for sure):
Test BSP Armbian old Armbian new std memcpy MB/s: 887.9 634.8 875.1 std memset MB/s: 2037.9 1553.0 2252.7 7z comp 22: 1288 1234 1515 7z comp 23: 1344 1279 1637 7z decomp 22: 3296 3329 3832 7z decomp 23: 3215 3317 3768 sysbench 648 (s): 14.4798 14.1447 14.1378 sysbench 816 (s): 11.4151 11.2191 11.1106 sysbench 1008 (s): 9.2395 9.0787 8.9818 openssl speed aes: almost identical So once DVFS is working there will be another slight performance increase in a few weeks.

PC2: http://sprunge.us/jVAH

Since I prepare a little NAS test with Orange Pi Zero Plus today I upgraded the firmware of the other JMS578 on the NAS Expansion board. Side effect: with the more recent firmware the USB-to-SATA bridge also provides more real information from the connected disk instead of itself.
 
Prior to the firmware upgrade only /dev/sda shows nice information:

 
After I upgraded the 2nd JMS578 (needs a full shutdown and removing power after the upgrade!) now /dev/sdb also reveals more information (though the drive's serial still bogus):