5kft

Great  !  The DT files are actually all generated from a patch, e.g., see https://github.com/5kft/build/blob/9ad96bd2090325092142a5c1dc75fe085c940bc5/patch/kernel/sunxi-next/general-sunxi-overlays.patch (this version has my changes to fix the H5-related entries, and some other things).  You can edit the sun8i-h3 DT entries locally in the file ".../build/patch/kernel/sunxi-next/general-sunxi-overlays.patch".

I just fixed this for the H5 boards, and have submitted a PR (https://github.com/armbian/build/pull/1056).  With these changes SPI is working for me again   Similar changes likely need to be made for the H3 DTs.

I just fixed this for the H5 boards, and have submitted a PR (https://github.com/armbian/build/pull/1056).  With these changes SPI is working for me again   Similar changes likely need to be made for the H3 DTs.

This.
 
Both overlays and fixup scripts need updates after migration from 4.14 to 4.17.

@5kft, yes let me know when you have an image to download and tell me all the instructions to check that all is ok.

Just had a quick look: https://github.com/friendlyarm/u-boot/commits/5532d5e641a990595156e83952049dd34cf838c0/common/board_r.c ?

Hi, I own a NanoPI Neo2 v1.0. Let me know which OS image I have to install, and I'll run out these commands :)
May be only in further days, but I'd be happy to help.
Pat

Here the output from (one of) my v1.0:
 
root@nanopi-neo22(192.168.6.22):~# sudo su - root@nanopi-neo22(192.168.6.22):~# cd /sys/class/gpio root@nanopi-neo22(192.168.6.22):/sys/class/gpio# echo 355 >export root@nanopi-neo22(192.168.6.22):/sys/class/gpio# cd gpio355 root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# echo in >direction root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# cat value 1 Kernel: Linux nanopi-neo22 4.17.7-sunxi64 #129 SMP Tue Jul 17 20:35:09 UTC 2018 aarch64 GNU/Linux  

Ah - thank you for this pointer!  This is great, exactly what I need!  

Updated images. https://www.armbian.com/nanopi-fire3
 
Thanks!

Yes - here's an example:  https://i.imgur.com/ynC6IiP.jpg.  Very simple, and perfect for fitting on a tiny perfboard 

Yes - here's an example:  https://i.imgur.com/ynC6IiP.jpg.  Very simple, and perfect for fitting on a tiny perfboard 

I totally agree, it is a really, really nice and powerful little board!  Temperature is a challenge with it, so I mounted a 25x25x10mm fan using thermal tape, and added a small circuit to drive it via the pwm1 line (transistor-controlled from the 5v input rail):
 

 
The fan scales up and down smoothly based on the CPU temperature (e.g., see https://github.com/5kft/nanopi-fire3-fancontrol/blob/master/fancontrol).  Using this with cpuburn-a53 on all eight cores at 1.4GHz it doesn't get above ~85C, and idles at ~35C (fan is running slow and silent at that temperature).  Very fun stuff!  
 

By default the OPi Zero Plus is missing the necessary 1.3v regulator entry in the DT.  Did you successfully apply this patch to enable it?  https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/sunxi-next-h5-orangepi-zero-plus-add-regulator.patch
 

Given the number of boards that can support higher CPU clocks (e.g., Nano Pi Neo 2, Plus2, Core2, OPi Zero Plus, OPi Zero Plus2 w/H/W MOSFET fix, etc.) it'd be great to be able to do this with overlays, rather than introduce a combinatorial explosion of board DTBs (i.e., per-board 1.1GHz max, 1.3GHz max, 1.4GHz max).
 
I have made some test override overlays to add the regulator and extend the CPU operating table (e.g., adding additional CPU core clock frequencies).  This works fine - one can just add the desired overlays in armbianEnv.txt and the new clock speeds appear and work:
... overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz param_spidev_spi_bus=1 ... However the problem is that one can't reliably run these boards at the higher clock rates without adjusting the thermal-zone cooling-map for the higher speeds.  Unfortunately device tree overlays don't appear to support thermal zones (at least I can't get them to compile with these present ).
 
I'm interested if anyone might have any ideas to to manage this.  Just brainstorming here, but perhaps we could make the default cooling-map for the H5 a bit more conservative, and then it could cover the introduction of the higher possible clock rates?  Or perhaps we could remove some slower entries from the H5 default clock operating table to allow for the addition of the optional higher clock rates (to better correspond to the default H5 cooling-map)?
 
Again, the nice thing about the overlay route is that we wouldn't have to change the 1.1GHz Armbian H5 default, so operation will be reliable.  But if users want to try speeding up their boards (whatever brand, VDD regulator, etc.), then they can just add an overlay or two and voila the higher speeds will be enabled.
 

The challenge with the Neo2 is that there are two hardware versions, so by default Armbian can't enable the regulator that is present only in the new 1.1 version of the board.  However I made a patch that I use for my Neo2 v1.1 board that adds support for the MP2143DJ regulator to the DT - see https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/sunxi-next-h5-nanopi-neo2-fix-leds-add-regulator.patch (this also corrects the LED names for the board).
 
In order to enable the higher clock rate, you'll also have to update the "sun50i-h5.dtsi" DT include.  I updated both this and the associated cooling-map in this patch:  https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/update-H5-board-config-support.patch (search for "sun50i-h5.dtsi" in this file).  You can extract just the patch for this file and ignore the other file patches I made.
 
Note that if you make these changes in your DT, then you'll also need to edit "/etc/default/cpufrequtils" on your Armbian board and change MAX_SPEED value to 1296000.  This way the board will run at a maximum of 1.3GHz via cpufrequtils.  With these changes thermal cooling works very well for me - the board auto-clocks down when it gets too hot, etc.
 
Unfortunately my Neo2's H5 is unstable at anything faster than 1.3GHz as the v1.1 regulator is restricted to 1.3v output maximum, so you can't overvolt.
 
I've been running my Neo2 using this for months using this configuration and it's been working great.  It's really a neat little board!
 
In any case, I hope this info might be useful - good luck!

Decoding SMD part codes can be an interesting exercise   Unfortunately my AliExpress order for these parts had an issue and was never delivered.  I ended up ordering a set of BSN20s from Digi-Key in the U.S. (https://www.digikey.com/products/en?keywords=BSN20-7DICT-ND).
 
Of course I can't promise that any of the following is applicable in general, but at least for my parts it seems to work...:
 
My parts have the codes "N20" and "E9" on them.  Doing a quick Google search for the package type (SOT-23) and the label on the part (N20) - i.e., "SOT-23 N20" - turns up this page:  http://www.s-manuals.com/smd/n2.  Looking in the table one can see two BSN20s listed, with the associated data sheets.  From the data sheet the "E9" is a date code, so it looks like my parts were made in September 2017 (which seems reasonable).
 
If you search for "SOT-23 J1" you'll see this page:  http://www.s-manuals.com/smd/j1.  Looking in the table you'll see lots of SOT-23 J1 devices.  Assuming that your part is in fact actually an N-Channel MOSFET, there are two entries for BSS138s...so that might be the part you have.  You may want to download the datasheet (http://www.s-manuals.com/pdf/datasheet/b/s/bss138_taitron.pdf) and compare the part specs with a standard BSN20 datasheet (e.g., mine is https://www.diodes.com/assets/Datasheets/ds31898.pdf) to determine if it might work okay...?
 

I'd like to make a patch explicitly for this and send a pull request to get it into the mainline, but unfortunately I don't have time to support this (much as I would like to!)...
 
If you just want to add support for the LEDs, you could clone the official Armbian master build tree, then do a custom patch.  For example, change to ".../build" and run "compile.sh":
 
./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no CREATE_PATCHES=yes BOARD=orangepizeroplus2-h5 When the build pauses for the kernel patch, edit ".../build/cache/sources/linux-mainline/linux-4.14.y/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts", and simply add a block for the LEDs (I added mine following the existing "wifi-pwrseq" block).  E.g.,
leds { compatible = "gpio-leds"; pwr { label = "orangepi:green:pwr"; gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */ default-state = "on"; }; status { label = "orangepi:red:status"; gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>; /* PA17 */ }; }; Save, and continue the build.  Then simply install the generated packages in ".../build/output/debs".  (It should also be possible to generate an overlay for this, but I haven't bothered to do this.)

Yes.  Actually I ended up commenting out the "&hdmi" block, the "&mixer0" block, and the "&sound_hdmi" block (I don't need audio support either):
/* &hdmi { status = "okay"; }; &mixer0 { status = "okay"; }; */ &r_pio { wifi_wake: wifi_wake@0 { pins = "PL7"; function = "irq"; bias-pull-up; }; }; /* &sound_hdmi { status = "okay"; }; */  
 

Yes.  Actually I ended up commenting out the "&hdmi" block, the "&mixer0" block, and the "&sound_hdmi" block (I don't need audio support either):
/* &hdmi { status = "okay"; }; &mixer0 { status = "okay"; }; */ &r_pio { wifi_wake: wifi_wake@0 { pins = "PL7"; function = "irq"; bias-pull-up; }; }; /* &sound_hdmi { status = "okay"; }; */  
 

It's been a long time since I've looked at the boot/reboot messages on my OPi Zero +2, but when I first was trying it I noticed that all of the HDMI-related drivers were segfaulting at reboot, causing it to hang.  Given that I'm using these boards headless, I didn't need HDMI enabled, so I disabled these drivers via the DT.  This solved all of my reboot crashes/hangs.  If you want to try this, you can edit "sun50i-h5-orangepi-zero-plus2.dts" as before, and comment out the "&hdmi" block.
 
(Yes, I know it would be better to determine root cause for the crashes and fix that, etc. etc. but this is an easy workaround )
 

I'd like to make a patch explicitly for this and send a pull request to get it into the mainline, but unfortunately I don't have time to support this (much as I would like to!)...
 
If you just want to add support for the LEDs, you could clone the official Armbian master build tree, then do a custom patch.  For example, change to ".../build" and run "compile.sh":
 
./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no CREATE_PATCHES=yes BOARD=orangepizeroplus2-h5 When the build pauses for the kernel patch, edit ".../build/cache/sources/linux-mainline/linux-4.14.y/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts", and simply add a block for the LEDs (I added mine following the existing "wifi-pwrseq" block).  E.g.,
leds { compatible = "gpio-leds"; pwr { label = "orangepi:green:pwr"; gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */ default-state = "on"; }; status { label = "orangepi:red:status"; gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>; /* PA17 */ }; }; Save, and continue the build.  Then simply install the generated packages in ".../build/output/debs".  (It should also be possible to generate an overlay for this, but I haven't bothered to do this.)

The mosfets arrived and finaly managed to make a test, and it works! Thank you again 5kft !
 
For me it worked with this Armbian version: Armbian_5.34.171121_Orangepizeroplus2-h5_Ubuntu_xenial_next_4.13.14.img, then compiled  with the build compilation tips shown by 5kft  in a previous post. It seems it runs at 1296 Mhz from the start, I didn't need to update cpufrequtils.
Surprisingly, it stays in idle at a lower temperature than before. Idle now is 38 celsius -although with a temperature meter is around 45. Before it was 55 - real it was with 2-3 degrees more (ambient temperature around 25).
 
20:33:36: 1296MHz 0.02 0% 0% 0% 0% 0% 0% 38.2°C 0/11  
pi@orangepizeroplus2:~$ cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 6.24 ms. hardware limits: 240 MHz - 1.30 GHz available frequency steps: 240 MHz, 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 1.30 GHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.30 GHz. cpufreq stats: 240 MHz:0.04%, 408 MHz:1.33%, 648 MHz:0.14%, 816 MHz:0.12%, 912 MHz:0.08%, 960 MHz:0.08%, 1.01 GHz:0.07%, 1.06 GHz:0.04%, 1.10 GHz:0.05%, 1.15 GHz:0.04%, 1.25 GHz:0.04%, 1.30 GHz:97.98% (254) pi@orangepizeroplus2:~$ sudo sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run && cat /sys/devices/virtual/thermal/thermal_zone0/temp sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 7.0661s total number of events: 10000 total time taken by event execution: 28.2527 per-request statistics: min: 2.82ms avg: 2.83ms max: 5.55ms approx. 95 percentile: 2.83ms Threads fairness: events (avg/stddev): 2500.0000/1.87 execution time (avg/stddev): 7.0632/0.00 56450  

I very much hope that those BSN20s will work - I bought mine from that very same seller 
 
Regarding increasing the clocks, I've attached a subset of my test patchset for the current mainline sunxi-next kernel (4.14.y) that you could start from.  Hopefully you should be able to just copy this to your "armbian/build/userpatches/kernel/sunxi-next/" directory, then build your kernel as normal (e.g., "./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no BOARD=orangepizeroplus2-h5").  Note that you'll need to update your "/etc/default/cpufrequtils" configuration to set the new min/max speeds (don't forget to reboot or restart the cpufreq daemon after doing this).
 
When you do the build, make sure the patch step succeeds - the "z" at the beginning of the filename helps ensure that it is the last patch applied.
 
(Note also that on reboot the HDMI driver crashes on my Plus2 - as a temporary workaround I disabled HDMI in the DTS as well.  Also I noticed that the default Armbian OPi plus2 patchset adds the regulator entry - I was confusing this change with my Neo Plus2 patch for this.)
 
z-test-fix-h5-clock-reg-kernel-sunxi64-next.patch

I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-)  The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc.  (I wish it had 1GB of RAM but that's a different subject.)  I'd love to use these boards for a number of projects.
 
As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board.  I also enabled the allowed clock changes to 1.2GHz for cpufreq.  All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v.
 
I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v.  I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board!  I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board.
 
So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board.  And now it works great!  VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems.
 
Would anyone have an idea why Xunlong doesn't solder this part on the board by default?  They include all the other parts in this part of the power circuit, just not this MOSFET.  I was going to buy a few more of these boards, and I'd like to be able to clock them up.  Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...?
 
Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis?  My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS).  By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds.
 
Thank you!