rusatch

It works, thanks.

There is also bad news  There is only @martinayotte left doing adaptations and testings on this kernel branch (I am just about to leave office for few weeks and will not do any code) which means "you" will need to step up and help. Recompiling, if things are not prepared, adjusted and tested on all Allwinner boards, is pointless. 1st stage is DEV kernel with 5.4.y anyway ...

@rusatch, I am very glad to hear this!!  Thank you!

Hi @rusatch - yes, however this is actually even easier to enable now; no patching and custom kernels should be needed   If you build Armbian from the latest top-of-tree for a sunxi device (starting with the 4.17.y kernel), two new DT overlays are provided that you can load via "/boot/armbianEnv.txt" that provide this regulator and will enable higher clock speeds to be used.  The original thread regarding this (with instructions) can be found here:  https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58181.  I'll repeat these instructions here for others:
 
If you would like to try to run your board at 1.3GHz, and your board has a regulator on GPIO PL6 that supports 1.3v (e.g., Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, etc.), then all you would have to do is the following:
 
1.  Make sure that you know what you are doing (!).  If you enable the following on a board that does not properly have access to the CPU regulator - i.e., unmodified OrangePi board with missing Q5 MOSFET, or a board that does not have a compatible 1.1v/1.3v regulator controlled via GPIO PL6 - then your board will almost certainly crash on boot!
 
2.  Edit /boot/armbianEnv.txt, and add these lines:
overlay_prefix=sun50i-h5 overlays=gpio-regulator-1.3v cpu-clock-1.3GHz If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz  
3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000:
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
4.  Reboot the board
 
That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).

Ooh. With overlays its very usefull. Thank you very much. Its very cool!
Today i recieve mosfets from aliexpress, used link that was in this thread. Tomorrow i will include mosfet on board and try use overlays.
 
update: Found additional overlay named cpu-clock-1.4GHz. Is this experemental overlay?

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'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"; }; */  
 

A dirty hack to make it working in orangepi PC2 immediately :
 
Edit the file WiringOP/wiringPi/wiringPi.c (https://github.com/tumugin/WiringOP), change the function isH5(void) to :
int isH5(void) { return 1; } then "sudo ./build".
 
I don't know C language, so there is no better way for me.
 
 
Edit : I have verified the following is working, other pins/functions are not tested :
## Tested with LED + resistor across physical pin 1 (3.3V) and pin 7 PORT=7 gpio mode $PORT out gpio write $PORT 0; ## LED on gpio write $PORT 1; ## LED off  

Yes. Fixed.

I just wanted to share some instructions on how to control all GPIO pins on the OrangePi Zero Plus 2 board. These instructions are meant for newbies but it can be extremely helpful if you are new to Armbian, OPI and GPIO. At least it would have been for me. 
 
There is a total of 17 different pins to control according to the schematic below. These pins are highlighted in blue numbers that indicate what GPIO port they are available at. Use these numbers in order to know that pins to control. Look for instructions further down. 
 

 
First off some basics: 
Activate a pin by exporting it. For example. In order to activate IO-0 run: echo "352" > /sys/class/gpio/export Set the direction of the port.  echo "out" > /sys/class/gpio/gpio352/direction Turn it on: echo "1" > /sys/class/gpio/gpio352/value Turn it off: echo "0" > /sys/class/gpio/gpio352/value  
To figure out what number to use for each pin follow the schematics above or read from the list below. I really have not figured out wether it is safe to control all pins(and not just IO-pins) for output but it seems to work when I verify with a voltmeter. These pins were identified using the official schematic for the board: http://linux-sunxi.org/File:ORANGE_PI-ZERO-PLUS2_V1_0.pdf
 
If you are interested to learn how pins are identified based on the schematic please dig deeper into these files in the GIT repo: 
https://github.com/armbian/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h
https://github.com/armbian/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h
 
GPIO Table
SDA = 12
SCL = 11
IO-GCLK = 6
IO-0 = 352
IO-2 = 353
IO-3 = 3
SPI1-MOSI = 15
SPI1-MISO = 16
SPI1-CLK = 14
TXD0 = 15
RXD0 = 16
IO-1 = 107
IO-4 = 19
IO-5 = 18
IO-6 = 2
SPI-CE0 = 13
SPI-CE1 = 110
 
I hope this helps someone. 

enable overlay uart 1
and add
param_uart1_rtscts=1
 
to armbianenv.txt
 
and adjust /etc/init.d/ap6212-bluetooth so it looks like this
 
  # Start patching
        rfkill unblock all
        echo "0" > /sys/class/rfkill/rfkill0/state
        echo "1" > /sys/class/rfkill/rfkill0/state
        echo " " > /dev/$PORT
        devmem2 0x1f00060 b 1
        echo 10 > /sys/class/gpio/export
        echo out > /sys/class/gpio/gpio10/direction
        echo 0 > /sys/class/gpio/gpio10/value
        echo 1 > /sys/class/gpio/gpio10/value
        sleep 0.1
        hciattach /dev/$PORT bcm43xx 115200 flow bdaddr $MAC_OPTIONS
        hciconfig hci0 up
 
 and reboot
 
oh you might need to install devmem2
 

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!
 

ok, 2nd day and starting to better understand this, will explain it loudly for myself and anyone else:
 
Though the answer was there from the beginning, too bad that it wasn't clear for meL
http://linux-sunxi.org/GPIO
 
First we need to "create" or "attach" the GPIO port using this command:
 
sudo echo XX > /sys/class/gpio/export The XX is a complex calculation of the GPIO:
 
 
so for Orange PI Zero plus 2 H5 (should be same for h3/h2) the RED led would on GPIO PA17 and GREEN LED on GPIO PL10  (Info from here: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero_Plus_2 )
The calculation would be (Letter A is 1, the "P" not counted): (1 -0) * 32 + 17 =  17  (For RED LED) while for Green LED: (12 - 1) * 32 + 10 = 362
 
sudo echo 362 > /sys/class/gpio/export sudo echo 17 > /sys/class/gpio/export  
Now lets check the status of the GPIOs:
 
cat /sys/kernel/debug/gpio gpiochip1: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl: gpio-9 ( |reset ) out hi gpio-14 ( |sysfs ) out hi gpio-17 ( |sysfs ) in lo gpio-110 ( |sysfs ) in lo gpio-166 ( |cd ) in hi IRQ gpio-204 ( |usb0_id_det ) in lo IRQ gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl: gpio-358 ( |? ) out lo gpio-362 ( |sysfs ) in lo  
The GPIOs should be "out" direction (i guess because we are outputting to it), so lets fix them:
sudo echo out > /sys/class/gpio/gpio362/direction sudo echo out > /sys/class/gpio/gpio17/direction  
Now that the direction is correct, lets try to switch them on or off:
sudo echo 1 > /sys/class/gpio/gpio362/value sudo echo 0 > /sys/class/gpio/gpio362/value sudo echo 1 > /sys/class/gpio/gpio17/value sudo echo 0 > /sys/class/gpio/gpio17/value  
Now that the LEDs are controllable, The  next challenge would be adding some rhythm to the led per hardware occasions such as heart beet, read/write..  i hope it will be easier than above

You have to try use this build . There is wifi working, but without 802.11n support, and without usb.