Aditya

I've look during more than an hour, it deosn't seems to be implemented ...
 
The only other way I would see is to run this python script and add a " os.system("reboot") " after the "button pressed" print :

Right ! I didn't mentioned it, loading overlay dynamically requires root privileges ...

It is Okay

The <0x74> is KEY_POWER, I've tried <0x198> which seem to be for KEY_RESTART, but it doesn't seem to work ... I will try to dig kernel sources to figure out ...

Right ! You need to install DT compiler from here : http://ftp.debian.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_armhf.deb
And do not provide this path "git-work/dtc/dtc" but simply "dtc -@ -I dts -O dtb -o /boot/dtb/overlay/sun8i-h3-gpio-keys.dtbo gpio-keys.dts" ...

Sure !
Take this overlay source and save it as "gpio-keys.dts" :
 
Compile it as an overlay DTBO using this command :
git-work/dtc/dtc -@ -I dts -O dtb -o /boot/dtb/overlay/sun8i-h3-gpio-keys.dtbo gpio-keys.dts Then, add this overlay either in /boot/armbianEnv.txt with "overlays=gpio-keys" or by loading it dynamically using :
mkdir /sys/kernel/config/device-tree/overlays/gpiokeys cat /boot/dtb/overlay/sun8i-h3-gpio-keys.dtbo > /sys/kernel/config/device-tree/overlays/gpiokeys/dtbo  
As soon as you connect the PA10 pin to GND, it will trigger a "shutdown" ...

Beware that even if you trigger event from GPIO to execute "halt" command using a "gpio-key" node in DT, the OPiZero will still be connected to PSU since there is no PMIC to really turn off the power...

Will be fixed once before 2/2020 https://armbian.atlassian.net/projects/AR/issues/AR-86

See I am a noob at all this. But I found somewhere that these commands can release RAM. Maybe give them a try prior to compiling
/usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 sync; echo 3 | sudo tee /proc/sys/vm/drop_caches The first one clears RamLog and the second clears the Buff/Cache.
Try these just for fun.
Or wait for the gurus to give the apt answer

Release details

https://docs.armbian.com/Release_Changelog/
 
Upgrading your Armbian to v19.11.y
 
This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
 
 
Choose latest version of 19.11.x and select upgrade according to this scheme:
Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
 

Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
Main build system changes
Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
LIB_TAG="v19.08" to your build config file which by default is:
userpatches/config-default.conf Then run your script as you did before.
 
Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
 
Enjoy! 

When using "sudo", it only affect the left part, here "echo", everything at right of ">" isn't "sudo" applied ...
So, if you wish to use "sudo", syntax would be :
echo "default-on" | sudo tee /sys/class/leds/orangepi:green:pwr/trigger Note here : "power" is not an available choice, do "cat /sys/class/leds/orangepi:green:pwr/trigger", it will show you all possible choices and the current setting is indicated with brackets. The choice you probably wish is "default-on".
 

Well - the LEDs are not statically defined, because you can define their usage by yourself - and the OS can have another default funtion like on a other OS (Orange Pi original Linux <--> armbian)
 
Your could find the available LEDs here:
root@pihole:~# ls -l /sys/class/leds
total 0
lrwxrwxrwx 1 root root 0 Jan  1  1970 green_led -> ../../devices/platform/leds-gpio/leds/green_led
lrwxrwxrwx 1 root root 0 Jan  1  1970 red_led -> ../../devices/platform/leds-gpio/leds/red_led
 
and which function is assigned to the LED you could find out while do a "more" an their trigger-file:
root@pihole:~# more /sys/class/leds/red_led/trigger
none mmc0 mmc1 timer [heartbeat] backlight default-on
 
here you could see I assigned the funtion [heartbeat] to the red LED
 
I did this in the /etc/rc.local with the following command (before the line with "exit 0") :
echo "heartbeat" > /sys/class/leds/red_led/trigger
 
heartbeat is this flashing LED - showing the system is running
 
mmc0 will be like a HDD-LED for your uSD-Card:
echo "mmc0" > /sys/class/leds/green_led/trigger
 
The names of your LEDs may varies.
 

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.

If you look at schematic, you will see that the RJ45 socket of the OPiOne has an integrated transformer built-in ...

H2 = H3 - 4k video
 
The difference is in the other components. Wifi on Opi Zero is total crap, while on Lite is little better. One is best out of those three, while recommended is Orangepi PC+ ... less overheating due to better voltage regulation.