ag123

Updated section on loop devices in systemd-nspawn container
https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35
Currently systemd-nspawn do not support loop devices needed in the compile.sh build. This section documents some workarounds to create loop devices in a systemd-nspawn container. Use this shell script to start systemd-nspawn
#!/usr/bin/bash sudo systemd-nspawn -b --capability=CAP_MKNOD \ --property=DeviceAllow="block-loop rwm" \ --property=DeviceAllow="block-blkext rwm" \ --property=DeviceAllow="/dev/loop-control rwm" \ -D /opt/armbian-build  
when the container is started up, in the shell within the container, use this shell script to create the loop devices
#!/usr/bin/bash if ! test -e /dev/loop-control; then sudo mknod /dev/loop-control c 10 237 fi for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do if ! test -e /dev/loop${i}; then sudo mknod /dev/loop${i} b 7 ${i} fi done  
In current tests, the above did create the loop devices, but is inadequate to fully resolve the issue with loop devices in armbian build compile.sh.

@Gunjan Gupta the changes for zero3 CPU Frequency are all bundled into this commit
https://github.com/pixdrift/armbian_build/commit/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0

It's on my branch zero3_cpufreq
https://github.com/pixdrift/armbian_build/tree/zero3_cpufreq
 
Changes of interest are are
https://github.com/pixdrift/armbian_build/blob/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2-dtsi.patch#L98-L141

Thanks for the offer to take a look

Jus one more piece of news. After rebooting the device (I believe I had to reboot it twice), bluetooth started and I was able to pair it with a loudspeaker, working beautifully.  On top of that, I was then able to set VLC to use OpenGL for embedded systems (which did not work before) and, with this configuration, some videos even played with 0 lost frames.
I also connected a 4G modem that supported the rndis driver through the USB and it was recognised without problem. I then installed SQM and cake-autorate to keep the latency in control and so far so good. It seems to be working quite stable. This little device seems to be quite promising, with several nice features at an unbeatable price...

Looks like there might be another H618 board in the pipeline named orange pi r1b - https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/boards/orangepir1b.conf

Sorry @Gunjan Gupta not having much luck with these images unfortunately.

I did a quick test of both kernel versions on a Zero2, and neither had HDMI output, although interestingly after the kernel boots it appears to send an HDMI signal (monitor detects it) but doesn't have any output. I tested both kernel versions using Bookworm as the OS.

I noticed in your branch, you haven't enabled console output 'both' or marked display as 'yes', so I rebuilt after updating the configuration and unfortunately I still didn't get anything displaying on HDMI out.
https://github.com/viraniac/armbian_build/blob/h616-hdmi/config/boards/orangepizero2.conf#L7-L8

I did test CPU Freq though and that appears to be working correctly. Here is some debugging output from the 6.1 Bookworm build.
 
root@orangepizero2:~# uname -a Linux orangepizero2 6.1.69-current-sunxi64 #1 SMP Wed Dec 20 16:00:29 UTC 2023 aarch64 GNU/Linux root@orangepizero2:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: 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: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) 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: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 2: 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: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 3: 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: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) root@orangepizero2:~# lsmod Module Size Used by algif_hash 16384 1 algif_skcipher 16384 1 af_alg 24576 6 algif_hash,algif_skcipher bnep 28672 2 hci_uart 135168 1 btqca 24576 1 hci_uart btrtl 28672 1 hci_uart btbcm 20480 1 hci_uart btintel 40960 1 hci_uart bluetooth 724992 29 btrtl,btqca,btintel,hci_uart,btbcm,bnep ecdh_generic 16384 2 bluetooth ecc 32768 1 ecdh_generic sprdwl_ng 352256 0 sunxi_addr 20480 1 sprdwl_ng cfg80211 376832 1 sprdwl_ng sunrpc 290816 1 snd_soc_hdmi_codec 24576 0 lz4hc 16384 0 lz4 16384 0 polyval_ce 16384 0 sunxi_cedrus 45056 0 polyval_generic 16384 1 polyval_ce v4l2_mem2mem 36864 1 sunxi_cedrus videobuf2_dma_contig 24576 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig dw_hdmi_cec 16384 0 dw_hdmi_i2s_audio 16384 0 videobuf2_v4l2 24576 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 49152 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops videodev 204800 4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem panfrost 69632 0 mc 53248 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem gpu_sched 28672 1 panfrost dump_reg 24576 0 apple_mfi_fastcharge 20480 0 drm_shmem_helper 20480 1 panfrost display_connector 20480 0 cpufreq_dt 20480 0 zram 28672 3 binfmt_misc 24576 1 sprdbt_tty 36864 2 uwe5622_bsp_sdio 208896 2 sprdbt_tty,sprdwl_ng rfkill 36864 7 sprdbt_tty,bluetooth,cfg80211 fuse 126976 1 dm_mod 131072 0 hid_apple 28672 0 realtek 32768 1 dwmac_sun8i 28672 0 mdio_mux 16384 1 dwmac_sun8i root@orangepizero2:~# dmesg | grep -i hdmi [ 1.444604] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.445267] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.445657] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008ea4d48) [ 96.336072] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 96.336102] sun8i-dw-hdmi 6000000.hdmi: read_hpd result: 1 [ 103.529860] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 189.979691] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin
It seems very close, just not displaying anything. I will do some more testing and let you know if I get something to work.

If anyone else has a Zero2 and wants to validate my testing, I have posted the images built from @Gunjan Gupta's HDMI testing branch here
https://armdev.pixeldrift.net/orangepi/zero2/viraniac/

Hi @Ivan Sy thanks for your interest in our Zero3 work and welcome to the forum!

I won't speculate on timelines for official support, but a PR with everything necessary (that @Werner alludes to) shouldn't be far off and we have most of the pieces working to different degrees which is what you will see in some of the testing and discussion in this thread.

The biggest challenge with merging to mainline is really getting the HDMI patch working for the zero2 as the zero2 and zero3 share a lot of similarities in their SoC. @Gunjan Gupta has done some incredible work to wrangle patches for the Zero2 to get everything working, and that is why you will see some Zero2 discussion here which may seem out of place.

Unfortunately the most recent Zero2 test for HDMI still has some challenges, and I have given as much feedback as possible to @Gunjan Gupta but unfortunately @Gunjan Gupta doesn't have a physical Zero2 to test on (yet). Once this patch is merged into the mainline Armbian, I think there will be some effort to move the remaining pieces that are common for both Zero2/Zero3 into a consolidated .dtsi file so both boards can benefit, then it will only take a small amount of effort to add Zero3 configuration (because it's almost identical).

The Zero3 fork I am maintaining, and posting here doesn't take into consideration anything other than the Edge branch and making the Zero3 work, where @Gunjan Gupta has put incredible effort into the Zero2 specifically and I have been porting/testing those changes on Zero3 as we go.

I think the Zero3 is a great board and I am confident that if we maintain momentum with the people who are contributing feedback and assistance from the community here, combined with the amazing patching work form upstream.. we will be able to put together a PR of the quality the project will approve of

Also, if you do buy a Zero2 or Zero3 board, please hang around and help us test  and to anyone else browsing this thread that has a Zero2/Zero3 board, create an account and say hi

The 'most complete' testing build at time of writing is this version, USE AT YOUR OWN RISK!
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.tar.xz

There are elements that we know aren't working (Bluetooth, CPU Frequency scaling) and items that are currently untested (audio output via HDMI and the expansion board).

I understand you are looking for a working image, but the Zero3 Armbian image is still in early development and depends heavily on people testing and providing feedback with identified issues. If you do run this image, please provide feedback on specific items you have tested and let us know. It is too early in the development at this stage to provide any advice or assistance for third party user space programs/applications that may produce errors or not work.

@pixdriftTry hdmi on orange pi zero 2 for both 6.1 and 6.6 kernel from my branch - https://github.com/viraniac/armbian_build/tree/h616-hdmi 
 
If this works, I will then move all the orangepizero2 patches to orangepizero.dtsi. I want to get this out of the way before I bump the edge kernel to 6.7

@pixdrift could you please test the kernel from the following link on Orange Pi Zero 2 - https://drive.google.com/drive/folders/1cjCyISx3r7bVlXEPapf_5BbONQMyTcHX?usp=drive_link 
 
This kernel has all of the sun4i-drm patches enabled. See if HDMI works

Another day another update

I merged in the Bluetooth fixes from @Gunjan Gupta's pull request to Armbian main branch into my zero3 fork, this includes moving to the extension pattern for the wifi driver.

I did a quick build and tested Bluetooth (pairing to a BT speaker) and the pairing worked, but I didn't test past this. If you have some tests you can do with Bluetooth, I would appreciate the feedback (USE AT YOUR OWN RISK etc.)
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.bt.fixed.tar.xz

I have looked at the CPU Frequency patch @Gunjan Gupta mentioned and I will look at modifying this patch to write to the shared .dtsi as suggested so both zero2 and zero3 benefit, I think that is a great suggestion.. this update doesn't include any CPU Frequency fixes yet unfortunately.
 
Thanks to everyone here that is providing feedback from their testing!
 
The github repo isn't updated with the BT fixes yet, I will try and get to this tonight so everyone can build updated images.
 
-edit-
 
GitHub fork for zero3 is now up to date with BT fixes
https://github.com/pixdrift/armbian_build/tree/zero3

https://github.com/armbian/build/pull/6070 should fix the cpufreq hang issue and should also get bluetooth working for orange pi zero 2

@pixdrift oops for that cpufreq lockup on zero 2
 
I tried probing the cpufreq modules:
 
>find /lib/modules -type f -name "*freq*" /lib/modules/6.6.4-edge-sunxi64/kernel/drivers/cpufreq/cpufreq-dt.ko /lib/modules/6.6.4-edge-sunxi64/kernel/drivers/cpufreq/scpi-cpufreq.ko > ls /lib/modules/6.6.4-edge-sunxi64/kernel/drivers/cpufreq cpufreq-dt.ko scpi-cpufreq.ko > sudo modprobe cpufreq-dt scpi-cpufreq > sudo cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.  
perhaps like @Gunjan Gupta
mentioned it may require additional codes e.g. that patch.
 
well no worries, I'd try to get around with my kernel build, hope I can resolve the loop devices nspawn limitations
but that the freeze for orange pi zero 2 isn't good, and i'm half guessing the symptom may be observed on zero 3 if cpufreq is after all patched in and some how work.
possibly a problem with the wifi driver design. I'm not sure where I read about that always 1 load is possibly caused by the uwe5622 wifi driver disabling interrupts and go into a busy polling loop.
if for some reason changing frequencies causes interrupts, it can cause other process to stall/freeze waiting for the interrupt to be served.
 
 

@Benedito Portela note that what you read here is *highly experimental*, we are 'playing' with the codes and hope that somehow we'd make it work, and we are testing initial experimental images / builds, but there are no assurances whatsoever. But that if you do run the images e.g. from @pixdrift, do feedback on your findings.
And that Orange Pi do distribute official images if you look in the download section for the board, but that those could be distributions other than Armbian.
 
 

I have updated the Zero 3 image with a few minor updates

1. The build now uses the u-boot upstream repository tag v2024.01-rc5 instead of the specific commit for the merge of the zero3 defconfig
2. The default configuration now includes the bluetooth tools installation to match zero2 in mainline armbian repository (if someone could test bluetooth and provide feedback it would be appreciated)
3. Kernel bumped from 6.6.4 to 6.6.7 and all patches apply cleanly and build works as expected (and CLI bookworm version has been tested).

I have built some new images (bookworm cli and xfce) with this configuration using 6.6.7 here that you are welcome to use at your own risk
https://armdev.pixeldrift.net/orangepi/zero3/
 
Source repo with the changes is here, use zero3 branch for latest stable of these changes.. I will try and make sure that this branch remains deployable
https://github.com/pixdrift/armbian_build/tree/zero3
 
I think the next step is really to look at getting Zero 3 into the mainline Armbian repository, even if it's in a reduced state of configuration due to patch issues.. this would at least set the ground work for when the components included in these builds mature. @Gunjan Gupta as you have been through this before for other boards, I was hoping to get some of your time to assist (I will see how far I get first )


Speaking of which, @Gunjan Gupta I had a quick look at adding HDMI for the Zero 2 (to the main Armbian repo, not your fork) based off a conversation you had in another thread, but unfortunately I am having issues with the HDMI patch when adding it to the main branch in the armbian repo (fails to build/patch). Have you had any success building with this patch on the current main Armbian branch? I was going to have a closer look at it tonight, but thought I'd ask if you had already looked at it.
 
Failing patch is the main HDMI driver patch:
drivers-wip-H616-hdmi-video-output
 

Adjust patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2.patch to patch arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero.dtsi instead of arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
 
Interesting. So it happens on h616 as well. Its that wifi driver causing the trouble again. I have encountered this issue on Orange Pi 3 LTS as well. I ended up removing sprdwl_ng from MODULES and loaded it instead using a systemd service. See https://github.com/armbian/build/commit/608618a6f5b341a1a171d3a0841a4807432d8294

Thanks for the feedback.

This is interesting, looking at the kernel config for the build, the following is configured, and I assumed this is correct for this board.

If anyone has any feedback/advice on this it would be appreciated.. happy to update the image if we can find a fix. I will do some reading myself
 
│ Symbol: ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM [=y] │ │ Type : tristate │ │ Defined at drivers/cpufreq/Kconfig.arm:32 │ │ Prompt: Allwinner nvmem based SUN50I CPUFreq driver │ │ Depends on: CPU_FREQ [=y] && (ARM || ARM64 [=y]) && ARCH_SUNXI [=y] && NVMEM_SUNXI_SID [=y] │ │ Location: │ │ -> CPU Power Management │ │ -> CPU Frequency scaling │ │ -> CPU Frequency scaling (CPU_FREQ [=y]) │ │ (3) -> Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM [=y]) │ │ Selects: PM_OPP [=y]
-edit-
 
Your output appears to be an improvement over the current state of the Zero2 (my recent build from Armbian main branch at least).
 
When I run the cpufreq-info command, the Zero2 appears to lock up and never recover
___ ____ _ _____ ____ / _ \| _ \(_) |__ /___ _ __ ___|___ \ | | | | |_) | | / // _ \ '__/ _ \ __) | | |_| | __/| | / /| __/ | | (_) / __/ \___/|_| |_| /____\___|_| \___/_____| Welcome to Armbian-unofficial 24.2.0-trunk Bookworm with bleeding edge Linux 6.6.6-edge-sunxi64 No end-user support: built from trunk System load: 26% Up time: 0 min Memory usage: 12% of 919M IP: XXX.XXX.XXX.XXX CPU temp: 41°C Usage of /: 4% of 58G RX today: 146.6 MiB Last login: Fri Dec 15 18:29:24 AEDT 2023 on ttyS0 root@orangepizero2:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0:  

There are five different patches that are imported from megous kernel tree (xff.cz) that conflicts with hdmi patch. The hdmi patch has to be rewritten to fix the same. I haven't started working on it yet, but I will do it soon. Most likely within next 2 weeks window as I would be bumping the allwinner kernel versions. Legacy kernel will be moved o 6.1, current to 6.6 and edge kernel to 6.7

Bluetooth is not going to work. Its currently broken in zero2 as well. The kernel has the required driver, but the hciattach binary and corresponding service file for the same is missing. I am going to create a extension for uwe5622 wireless module that should make it easy to set this thing in the future

I have updated zero3 branch in my fork so it's up to date and you should be able to build Zero 3 images from it for testing: https://github.com/pixdrift/armbian_build/tree/0f9820ff2238ab15fdbfef9adfefca47b031a757

agree with @Igor, supporting a board is a long term commitment and no easy feat.
Those who are reading this thread should take it that there is no official Armbian release (not even 'community' nor 'unsupported')  for this board (yet).
The images tested prior to these comment includes:
vendor's images some images created by 3rd parties (possibly including Armbian derivative) These are 'community efforts', attempts to run it on Orange Pi Zero 3 and is purely 'experimental'.
 
But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here.
Note that for a supported board, it would call on the community for continuous maintenance and integration,  as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all.
It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian.
--
I've been (*messing*) experimenting with this board and I learned something, while one is messing with 'experimental' software, and 'experimental' boards e.g. this board.
It is easy to think of it as a software problem. After all the experiments, it turns out some of my network woes I encountered are simply due to a defective network cable.
But that said, there are 3rd party images or some such images there are broken in the software.

issues with other (e.g. network) hardware are after all quite common e.g. in this case a problem with network hub, and in my case a defective network cable
https://forum.armbian.com/topic/29954-sd-card-corrupt-after-hard-power-off/?do=findComment&comment=176561
 
i.e. there are so many blind spots when something doesn't work, and your hardware (including like cables, other hardware etc) should be in the checklist for troubleshooting.
 

Building Armbian using Ubuntu (jammy) in a systemd-nspawn container
https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35
 
Special thanks goes to
@Gunjan Gupta
 for the tip on PREFER_DOCKER=no
 

A colleague just pointed out to me that you are doing docker in docker. May be just run ./compile.sh PREFER_DOCKER=no to avoid spawning docker instance within docker?

hi, just like to join this discussion in a 'development' sense
it seemed there are some works in the head Linux v6.5-rc1
https://groups.google.com/g/linux-sunxi/c/p64EM9m9inY
https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3
https://linux-sunxi.org/Linux_mainlining_effort
 
they seemed to be continued works on H616 mainlining efforts, but that those are working on H618 e.g. Orange Pi zero 3 etc
it could be good to look at the head revisions e.g. v6.5 when we 'backport' codes into e.g. v6.1.31 that is used with armbian.
that could save a lot of rework if at some point we (armbian) decide to move on and use a new kernel e.g. v6.5
and accordingly, i read a post that say things like the wifi drivers as different vendors tried to implement their own drivers, it creates a 'problem' for the mainlining efforts to attempt to reconcile 2 different versions of the 'same driver'.  Hence, it may be good to look at head revisions e.g. v6.5 while 'porting' them back into v6.1.31. it would likely allow us to have 1 version of drivers e.g. from mainline that possibly works on different boards using the same wifi chips etc.
 
 

oh well, i didn't realise this rather nice tool exists, i guess i've been pretty old school as before i get to know armbian, many things used to be you are on your own, and dd is one of the tools that's just there
https://etcher.io/
 

just like to share my 2 cents as  i'm using 5.59 Debian stretch image on Orange Pi PC
if you have been using the 'old' images e.g. 3.x series, that is quite  different from stretch (i've not tried bionic) which uses 4.x kernels. the 4.x kernels are mainline linux kernels.
the old 3.4 kernels uses some of the binary blobs like FEX etc distributed by Allwinner et.al.  4.x kernels are mainline linux kernels and FEX is not there as FEX Is propriety and the binary blobs is close sourced. 4.x mainline kernels has some of the old 3.x functionality reverse engineered open sourced and the features are pretty functional but not all of it.

i've used the 5.59 ubuntu stretch (mainline kernel 4.14.65 image for orange pi pc and do note that it is a cli (command line based) image
HDMI works for me in 5.59 Ubuntu Stretch mainline image, connect a usb keyboard and mouse to work on it like a PC
i'm not too sure if the Orange Pi PC you have bought a year back is after all the same as that i bought just recently, but based on the specs i think it should be pretty much the same. I'm not too sure if things may have changed between the year. If things are the same, install the image on a new (or different) SD card
(i work in linux and simply did
dd if=Armbian_5.59_Orangepipc_Debian_stretch_next_4.14.65.img of=/dev/<the sdcard device> bs=1m
to write the image to the sd card.
and boot that on the Orange Pi PC, it should boot and should leave you on the command prompt in HDMI asking you to logon. be a little careful with the initial password changes as you would need the new changed passwords after the initial logon and user creation. i made some mistakes and got locked out initially.
 
ssh needs to be setup anew as the os is reinstalled. i think if you are used to access the sbc as orangepipc.local. you may find that ping etc didn't turn up orangepipc.local.
i found out that that is mainly because avahi-daemon (i.e. mdns) is not installed on the orange pi pc. what i did is to do apt-cache search avahi on the sbc and install the avahi-daemon (e.g. apt-get install avahi-daemon) and subsequently i'm able to ping my board as orangepipc.local connected on the ethernet. i'm not using any wireless dongle.
after that ping and ssh to the hostname orangepipc.local works.
 
if you want to install the desktop, you need to run the commands:
- apt-get upgrade armbian-config
followed by
- armbian-config as root
and there is an option to install the desktop
 
Note that a new image Armbian 5.60 may be released soon, if you want that earlier, you could run apt-get upgrade armbian-config followed by armbian-config and switch to the nightly build
 
if things are still not working for you, you may want to fall back to the Xenial 3.4 image instead, as you have mentioned it seem to work well for you
 
i won't be able to help much with the wifi dongle but in armbian-config i think there is something like install/upgrade firmware package. i found that the 'firmware package' distribute quite a number of blobs and some of it seem to be related to wifi  chips. you could try that to see if it helps. and this is for the stretch image and i'm using the nightly builds