Werner

Change /boot/armbienEnv.txt to have both "verbosity=7" and "console=serial", you will get more details ...

I use the USB-A to Barrel cable for my OPi's - maybe it was a connector problem?

If people with H6 devices without USB3 hub had problems connecting some USB3 peripherals, there has been and issue discovered now, where TXVBOOSTLVL was left to the default value instead of set to 7 (max). I haven't checked what the default value is (it's not documented), so I'm not sure if it will have any effect, but the patch is here:
 
https://megous.com/git/linux/commit/?h=opi3-5.4&id=ea8b455817276a043ee0508a8b159dca84c13c53
 
It may or may not help. On Opi3 I see no change, probably because HUB is really close to the SoC, but on boards without a HUB, SoC's USB3 phy will have to drive the signal over the longer cable and this patch might benefit those boards.

Linux 5.4 contains the code changes, dts changes will be included in 5.5. So yes, and no.

I remember seeing some patches from @megi about USB3 PHY few days ago ...
We will get those probably in his 5.4.y branch later.

Those mainline PHY patches will work for boards that don't have switchable VBUS on usb3 ports, like Orange Pi 3. It's a bit of a compromise to get at least some allwinner USB3 code into the mainline Linux. I should probably port back to my 5.4 branch the older version of the patches that can also be used with other boards that need to enable VBUS regulators.

You may want to consider buying an OrangePi One. The 512MB configuration is even a tiny bit cheaper than the 512MB OPi Zero, no (useless anyways) wireless onboard, offering HDMI and H3 instead of balls-cut-off-H2+ SoC. It cannot be powered from microUSB though. Barrel plug has to be used.

I dont think its fixed, because I also got this on
Armbian Linux 5.3.8-sunxi
package bsp-kernel[5.99.191102] u-boot[5.91] dtb[5.99.191102] firmware[5.98] config[5.98]
on a OPi Zero.
 
Also got this "problem" since over 2 years:
Since then I use my old workaround from this old thread.

 

... and you have to trust that compilers aren't fake  Or that rootfs was not somehow tempered in the build process ... or package in the upstream repository is somehow not security problematic.
But some are later mislead by flashy ads/words promising wonder upgrades and convenience ... and you get what you were afraid to get 
 

Someday  I wasn't sure that I will manage to RFC package naming 
but its almost done by now.
 

 We were not that bad, but it was fun sending pop-up messages around to X terminals. 

happily we're not a vendor right. would it be nice to have the hashes published somewhere.. of course it would.. it would also be nice to have a unified bootloader on arm which doesn't suck give me headache every time I look at it. or wifi which just works or device tree which actually describes the devices properly and not copy paste gone or boardmaker cares about mainlining their products etc.
 
If you don't trust our images you can still build them yourself. Then you just have to trust that we didn't hide something in the x lines of code to create an image (have fun to review that ).
 
it would also be nice if someone rewrites nand-sata-install.. My attempts so far just made it worse..
 
 
well 42.zip is still a thing? https://en.wikipedia.org/wiki/Zip_bomb
 
well we had fun to send each other shutdown commands over network in school when I was young (nothing was more insecure than our schools network back then - that's why no teacher trusted it and never had exams on the school computer )..
 

Thank you.  
 
 
We know hardware more in details. The rest, user land, is from Debian ... or (Stallmanised) Ubuntu if you choose that flavour. Debian (and any other distribution) is a (major) step back if you look to the ARM single board computers.
 

One user write a very good analysis but can't find it ... This is ours: https://docs.armbian.com/Developer-Guide_Build-Process/ but its several years old.
 
1. Cross-compilers are essential for building from sources and for building on a generic x86 platform. They came from Linaro or ARM and are PGP signed (by Linaro / ARM). https://releases.linaro.org/components/toolchain/binaries/ If you don't trust them, you can build compilers from sources ... with another C compiler you trust  We have as many compilers we need to build all sources. Debian trusts Linaro.
2. Aptly is one of many Debian repository management tools. We choose to use this one. It's open source https://github.com/aptly-dev/aptly and works well.
3. Rootfs, applications and scripts, are cached, PGP signed (by me) and securely uploaded to our servers, like the rest of the stuff. This only shorten the build process in this task section (from 20 minutes down to 10-30 sec or whatever time you need to download 300-500Mb) which you can recreate with Debian debootstrap if you like. Packs are identical to all builds, only divided on package base (Stretch, Buster, Bionic, Buster-minimum, Buster-desktop ... ) and arhitecture - arm / arm64 in our case. We merge this with freshly compiled board support packages, u-boot, kernel and export ISO image which you can merge to the boot media.
4. Ask with more questions. Not sure if I remember everything you might need to know ... It's a big project by now. I was full time for few years and  we would like to hire if there will be enough income. There is plenty of work.
 

All binary code which we use is stored here:
- https://github.com/armbian/build/tree/master/packages/blobs (various open stuff plus some bootloader blobs. some hw is not possible to bring up without)
- https://github.com/armbian/rkbin (rockchip bootloaders, essential for rockchip)
- https://github.com/armbian/firmware (wireless firmware, not essential)
 

If you are happy with this, which is the cheapest hardware, how happy you will be with something which is not that limited  BTW. Wireless on this chip is garbage beyond repair. 

When trying to upgrade to newer branch, what I'm usually do when such duplicate nodes appears, instead of disabling patches, I comment out the duplicate offending nodes, and then compile.
Anyway, I will try to find some "missing time ingredient" in the following days, and Armbian will then be ready for a commit ...

I will try to find some free time, which still the "missing ingredient" ...

Thats a good choice - does run very stable

Just found this thread after googling around to see if PiVPN works with Armbian on an Orange Pi Zero 512MB.
 
Can confirm that it workes perfectly fine on Armbian 5.91 using and Orange Pi Zero H2+ 512 MB Board.
 
Allows me to shut down my open ports on my router :-) Yeah.
 
This is my 3rd Board using Armbian now. 
 
1) Orange Pi One as Pi-hole and Webcam
2) Orange Pi Lite as Webcam
3) Orange Pi Zero as PiVPN
 
Just had to donate to Armbian. This stuff is working very good.

A while ago I did create  a armbian-package-information for at the motd of the login:
Now the line for the kernel does show 2 versions because there are "Version:" and "Config -Version:"
 
root@npi-neo2-24(192.168.6.24):~# dpkg -s linux-image-$BRANCH-$LINUXFAMILY|grep Version Version: 5.96 Config-Version: 5.96 root@npi-neo2-24(192.168.6.24):~# dpkg -s linux-image-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ' 5.96 5.96 So I had to find another way/command to get the information once
I did go back from "dpkg -s" to "dpkg -l" and greped there the version-info:
root@npi-neo2-24(192.168.6.24):~# dpkg -l | awk -v env_var="linux-image-$BRANCH-$LINUXFAMILY" '$2==env_var { print $3 }' 5.96 # end-part of /etc/update-motd.d/10-armbian-header # NEW version # =============================================================================================================== ARMBIAN_bsp=$(more /etc/armbian-release|grep VERSION|cut -f 2 -d '=') ARMBIAN_kernel=$(dpkg -l | awk -v env_var="linux-image-$BRANCH-$LINUXFAMILY" '$2==env_var { print $3 }') ARMBIAN_uboot=$(dpkg -l | awk -v env_var="linux-u-boot-$BOARD-$BRANCH" '$2==env_var { print $3 }') ARMBIAN_dtb=$(dpkg -l | awk -v env_var="linux-dtb-$BRANCH-$LINUXFAMILY" '$2==env_var { print $3 }') ARMBIAN_firmware=$(dpkg -l | awk -v env_var="armbian-firmware" '$2==env_var { print $3 }') ARMBIAN_config=$(dpkg -l | awk -v env_var="armbian-config" '$2==env_var { print $3 }') printf 'package bsp-kernel[\e[0;91m%s\x1B[0m] u-boot[\e[0;91m%s\x1B[0m] dtb[\e[0;91m%s\x1B[0m] firmware[\e[0;91m%s\x1B[0m] config[\e[0;91m%s\x1B[0m]\n' "$ARMBIAN_kernel" "$ARMBIAN_uboot" "$ARMBIAN_dtb" "$ARMBIAN_firmware" "$ARMBIAN_config" printf '\n' # ===============================================================================================================  
After successfully getting the kernel-version only once- I edited the other commands to the "dpkg -l" version - and the result is clear as before
_ _ ____ _ _ _ ____ | \ | | _ \(_) | \ | | ___ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_____| Welcome to Debian Buster with Armbian Linux 5.3.3-sunxi64 package bsp-kernel[5.98.191003] u-boot[5.96] dtb[5.98.191003] firmware[5.96] config[5.96] The only drawback is, when you use a dev-kernel/-dtb on a next-installation (using other kernel via armbian-config) then $BRANCH is next and your kernel is dev
root@npi-neo2-24(192.168.6.24):~# dpkg -l|grep image ii linux-image-dev-sunxi64 5.98.191003 arm64 Linux kernel, version 5.3.3-sunxi64 rc linux-image-next-sunxi64 5.96 arm64 Linux kernel, version 4.19.71-sunxi64 root@npi-neo2-24(192.168.6.24):~# dpkg -l|grep dtb ii linux-dtb-dev-sunxi64 5.98.191003 arm64 Linux DTB, version 5.3.3-sunxi64 # ARMBIAN_kernel=$(dpkg -l | awk -v env_var="linux-image-$BRANCH-$LINUXFAMILY" '$2==env_var { print $3 }') ARMBIAN_kernel=$(dpkg -l | awk -v env_var="linux-image-dev-$LINUXFAMILY" '$2==env_var { print $3 }') # ARMBIAN_dtb=$(dpkg -l | awk -v env_var="linux-dtb-$BRANCH-$LINUXFAMILY" '$2==env_var { print $3 }') ARMBIAN_dtb=$(dpkg -l | awk -v env_var="linux-dtb-dev-$LINUXFAMILY" '$2==env_var { print $3 }')  
 
PS: I also did try - before this - the package apt-show-versions (lists available package versions with distribution)
but this takes much too long to resolve and needs this additionally package
 
 

I rebuilt a full image this morning and I still have no wired network. I went back to kernel 4.19.X. I'll spend some time tonight to compare the device trees between 5.2 and 5.3.

I always freeze firmware updates when using custom build kernel images on my boards to avoid issues like this.

Merged !

That should be pretty easy to fix by commenting or erasing the duplicate in our patch.
I will look at it ...
 
EDIT: removal of guilty patches is now done !
https://github.com/armbian/build/commit/b53556a5f1ada29169d08b6a106a01f87d763774

Its (always) a compromise 
 
The primary reason for this upgrade is to have a better working solution for easy experimenting with things as such: https://forum.armbian.com/topic/11424-playing-with-limamesa-mali-drivers/ 
 
Initial upload repository size will be addressed (recreating/truncating), while for upload limit, there is nothing I can do. On the other hand Github has advantages, like existing user management ... for one user this is not a problem.
 
The bulk of the job surrounding this change is elsewhere - package management RFC - rebuild is done much faster/in parallel, cleaning is more efficient ... 

Maybe simply a rare bad luck, because I personally own more than 10x OPis, and all of them are working great ...

Looks great@igor!

If you're in the states and interested in selling your Helios4, DM me.

Tested on forgotten boards in first AllWinner's garden Tour : nanopiduo2, nanopineo2, nanopim1plus2 and bananapim2plus ...