XFer012

Necroposting, I know, but just in case someone else googles up this thread as I did.
The MPI3508 3.5" screen is cheap and sold a ton apparently.
 
So the problem is, the display is actually 480x320 but identifies itself as 1024x768 (!), which is not correct as size and not even as aspect ratio (4:3 vs. actual 3:2)
 
Trying to force 480x320 in armbianEnv.txt does not work, the display shows nothing; probably there are no proper timings in the kernel/DTB/whatever for such low an HDMI resolution.
 
So the trick is using 720x480, which is 1.5x the actual resolution. The aspect ratio is correct, the timings are there, and after all it's even quite readable.
 
So in /boot/armbianEnv.txt add:
    extraargs=video=HDMI-A-1:720x480@60
    disp_mode=720x480
 
and then recompile boot.scr:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
 
Display should run fine.
 
fbset reports:
 
mode "720x480"
    geometry 720 480 720 480 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode
 
which may be added to /etc/fb.modes
 
Hope this helps, despite not being optimal.

Necroposting, I know, but just in case someone else googles up this thread as I did.
The MPI3508 3.5" screen is cheap and sold a ton apparently.
 
So the problem is, the display is actually 480x320 but identifies itself as 1024x768 (!), which is not correct as size and not even as aspect ratio (4:3 vs. actual 3:2)
 
Trying to force 480x320 in armbianEnv.txt does not work, the display shows nothing; probably there are no proper timings in the kernel/DTB/whatever for such low an HDMI resolution.
 
So the trick is using 720x480, which is 1.5x the actual resolution. The aspect ratio is correct, the timings are there, and after all it's even quite readable.
 
So in /boot/armbianEnv.txt add:
    extraargs=video=HDMI-A-1:720x480@60
    disp_mode=720x480
 
and then recompile boot.scr:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
 
Display should run fine.
 
fbset reports:
 
mode "720x480"
    geometry 720 480 720 480 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode
 
which may be added to /etc/fb.modes
 
Hope this helps, despite not being optimal.

No. Some CPUs can run on lower voltage with same frequency to reduce their power loss but most will become unstable this way. There is only one way to find out if it works.

Finally I got my lcd (some of them) to work with armbian on mainline kernel (5.4) using device tree overlay. It should be working on 4.19 kernel too.
I test mine on orange pi zero. The one I am able to get working is ili9341 and st7735 based lcd.
I'll add more detail later but for now I'd like to get this out.
 
edit 1 :
Adding ssd1306 and nokia 5110 overlay to the repo
 
device tree overlay

Hi @spender, looking at your configuration, I dont see anything obviously wrong, I check your wiring at it seem correct . There is some difference with my setting (like I disable spidev on the dts and not enable spidev on armbienEnv.txt) but I am not sure it is the problem since based on your dmesg, look like the kernel driver still successfully loaded. Unfortunately it seem you have to dig at the hardware level to troubleshoot.
 
Here is my suggestion , not in particular order :
- Use older kernel in which fbtft_device still exist (I think 4.19, I am sure there is armbian image with that kernel) to test the lcd. It easier using fbtft_device because you dont need to restart to test it. If you can make it work here great, that mean the wiring actually correct and your lcd work, then its a matter of making the mainline kernel work.
- Test with logic analyzer, cheap saleae clone and sigrok goes really far. Make sure the signal is actually generated and WITH correct POLARITY.  I found out that I have to reverse the reset signal polarity in the dts by doing this. If correct signal is generated but your lcd doesnt display anything, I am afraid your lcd is toast.
- Make sure the lcd and driver are in same mode. Ili9341 can work with 8 bit or 9 bit spi, your module might only work with either setting or provide jumper to change the mode. However ili9341 kernel driver only work with 9 bit spi mode, so if you can't make the lcd work in 9 bit mode, I am afraid you cant use it with kernel driver.

I too wanted to boot to a second partition and struggled. The workaround by @richardk sort of fixes of the problem but isn't a general solution. After examining the U-Boot environment (printenv at the u-boot prompt) and /boot/boot.cmd I feel that boot.cmd needs to be patched. If you set the boot flag on the second partition (parted or fdisk, etc.) then U-Boot correctly sets 'distro_bootpart' and thereafter uses '${devnum}:${distro_bootpart}'. I modified boot.cmd to follow the same convention, rebuilt boot.scr and it works.
 
*** a/boot.cmd 2020-03-29 11:47:02.268576905 -0700 --- b/boot.cmd 2020-03-29 11:55:28.541325423 -0700 *************** *** 18,25 **** echo "Boot script loaded from ${devtype}" ! if test -e ${devtype} ${devnum} ${prefix}armbianEnv.txt; then ! load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt env import -t ${load_addr} ${filesize} fi --- 18,25 ---- echo "Boot script loaded from ${devtype}" ! if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}armbianEnv.txt; then ! load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}armbianEnv.txt env import -t ${load_addr} ${filesize} fi *************** *** 34,71 **** if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi ! load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} fdt addr ${fdt_addr_r} fdt resize 65536 for overlay_file in ${overlays}; do ! if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done for overlay_file in ${user_overlays}; do ! if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done if test "${overlay_error}" = "true"; then echo "Error applying DT overlays, restoring original DT" ! load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} else ! if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" source ${load_addr} fi ! if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then ! load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr echo "Applying user provided fixup script (fixup.scr)" source ${load_addr} fi fi ! load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd ! load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} --- 34,71 ---- if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi ! load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}dtb/${fdtfile} fdt addr ${fdt_addr_r} fdt resize 65536 for overlay_file in ${overlays}; do ! if load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done for overlay_file in ${user_overlays}; do ! if load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done if test "${overlay_error}" = "true"; then echo "Error applying DT overlays, restoring original DT" ! load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}dtb/${fdtfile} else ! if load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" source ${load_addr} fi ! if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}fixup.scr; then ! load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} ${prefix}fixup.scr echo "Applying user provided fixup script (fixup.scr)" source ${load_addr} fi fi ! load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} ${prefix}uInitrd ! load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${prefix}Image booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}  

SUCCESS.   I've got it booting the second partition.  
 
Lessons:
 
armbianEnv.txt really wants UUID=.  If you make a new partition, make sure to match UUIDs.
 
Edit boot.cmd; find:
   echo "Boot script loaded from ${devtype} ${devnum}"
 
Before that line, add:
   setenv partnum "2"
   setenv devnum "${devnum}:${partnum}"
 
That's how it's working.
 
I thought I could adjust so that it took partnum=2 from armbianEnv.txt (and move the new setenv devnum down after armbianEbv.tct is loaded).  I don't know why that didn't work; I might have messed something else up.
 
Anyway, I'm good to go.
 

This is the same stuff that we incorporate via patches at the moment.
However building may become easier and we can get rid of a few of those.

I've taken peeks at threads related to hardware decoding (of H.264 and HEVC, mainly) on Allwinner and Rockchip platforms on and off, sometimes dabbled in trying and failing to implement solutions recommended there. Being a complete amateur, I find the topic very opaque and confusing, with various different components that need to interface with each other, be patched in sync, and sometimes change drastically between kernel versions, etc. Today I sat down and read up on these subjects, scouring wikis, documentation, this forum, and assorted other sources to try and understand how this works. In this post I will attempt to compile what I've learned on the different software components involved, their relationships, their current status, and solutions to the problem. I hope people more knowledgeable will correct me when I get something wrong or cite outdated information. Stuff which I am highly uncertain of I will print in italics.
(This post is going to focus on mainline implementations of Cedrus/Allwinner, I haven't looked into Hantro/Rkvdec/Rockchip specifics yet. I will speak only of H.264 and H.265/HEVC; I don't understand the high/low stuff and didn't pay attention to other codecs.)
 
Components:
 
Basics: Video codecs like H.264, H.265/HEVC, MPEG-2, etc. are standardised methods which serve to more efficiently encode and decode videos, reducing their filesize. Software en-/decoding is very CPU-intensive. Modern GPUS and ARM SoCs therefore contain specialised hardware (VPUs) to delegate these tasks to. Working hardware decoding is particularly important for underpowered ARM CPUs.
Drivers: Topmost in the stack are the VPU drivers. These are Sunxi-Cedrus/Cedrus V4L2 M2M and Cedar [Is this the legacy one?] on Allwinner; Hantro and Rkvdec on Rockchip. These are all still in development, but Cedrus already fully supports H.264, and partially supports HEVC, and is already usable in the mainline kernel.
APIs: In order for anything (userspace APIs, libraries) to make use of the VPU drivers, you need backends/APIs. For Cedrus, there is the unmaintained libva-v4l2-request backend which implements VA-API, the legacy VDPAU implementation libvdpau-sunxi, and as of kernel version 5.11, H.264 has been merged into the uAPI headers. Different applications may make recourse to one or another of these APIs.
Libraries: FFmpeg and GStreamer. provide libraries and APIs of their own to other applications but can (importantly!) also output directly to the framebuffer. FFmpeg must be patched to access either libva-v4l2-request or the Cedrus driver headers. GStreamer directly accesses kernel headers since 1.18 (works on 5.9, not on 5.10; 1.20 will support 5.11.)
Media players: mpv and depends on FFmpeg for hardware acceleration (and must be patched together with it). VLC can be set to access libva-v4l2-request directly. Kodi 19.0+ supports hardware acceleration out of the box without any out-of-tree patches.
Display server: An additional complication is drawing the output of any of the above on screen. Most successful implementations I've seen bypass X11 and either output directly to the framebuffer or force a plane/display layer on top of any X windows. Wayland apparently makes this easier by allowing applications to use their own DRM planes, but this hasn't been explored much yet. Kodi 19.0 works with all three windowing systems (X, Wayland, and gbm).
 
Codec status:
 
Taken from the LibreElec thread (which reflects LibreElec's status and is ahead of what works elsewhere, but outlines hardware limitations):
 
 
Approaches:
 
Many people have managed to make it work on their machines using different approaches. Note that some of these solutions are one or two years old, and kernel developments since may have changed the situation. Ordered from newer to older:
 
LibreElec – kernel + ffmpeg + Kodi: LibreElec is a Just-Enough-OS with the sole purpose of running Kodi, a media player. It's at the bleeding edge and usually implements codecs and features well before mainline or other distros. It achieves this by heavily patching everything up and down the stack, from the Linux kernel over FFmpeg to Kodi itself. These patches could all be applied to an Armbian build, but there are a lot of them, they're poorly documented, and you'd need to dig into their github to understand what they all do. LibreElec runs Kodi directly without a desktop. kodi-gbm is a package that can be installed on Armbian and functions similarly.
Key contributors to the project are @jernej and @Kwiboo, who sometimes post about their work here (and have been very helpful with questions, thank you). @balbes150 includes some of LibreElec's patches in his Armbian-TV builds, but I don't know which.
 
Kodi 19.0: 
 
LibreElec patches + mpv:
 
 
@megous – Kernel 5.11 + GStreamer: This implementation, done here on a PinePhone (A64), patches the 5.9 kernel and uses a recent version of GStreamer (1.18 and up), whose output is rendered directly to a DRM plane via kmssink. (No X or Wayland.)
GStreamer 1.18 works with the 5.9 kernel. It does not work with 5.10, because of numerous changes to the kernel headers in this version. In 5.11 the H.264 headers were moved into the uAPI; the master branch of GStreamer reflects this, but there haven't been any releases with these patches yet. It'll probably be in repositories with GStreamer 1.20; until then you can build it from source.
 
@Sash0k – patched libva-v4l2-request + VLC: This updates bootlin's libva-v4l2-request and follows the Sunxi wiki's instructions for enabling VLC to make use of it. It works on the desktop. This only works for H.264 and breaks HEVC. When I tried to replicate this approach on a recent Armbian build, I discovered that the h264.c files in the kernel (that libva-v4l2-request draws on) have changed considerably between 5.8 and 5.10, and I lack the understanding to reconcile libva-v4l2-request with them.
 
@ubobrov – old kernel + libcedrus + libvdpau-sunxi + ffmpeg + mpv: This approach, which supports encoding decoding of H.264 uses the libvdpau-sunxi API and ports the legacy driver to mainline as a loadable kernel module and if I understand it correctly, ubobrov ported a legacy feature to mainline. In the post quoted below the kernel is 4.20, but the same method has been successfully applied to 5.7.8 by another user. It requires that the board's device tree be patched, as documented in ubobrov's github repository.
 
 
The summary seems to be that none of the current implementations on Allwinner boards really play nice with X or desktop sessions, and it's best to output directly to the framebuffer. Kwiboo has forked FFmpeg and mpv to make good use of new and unstable kernel features/hardware acceleration which will take a while to make their way upstream. The recent 5.11 move of stateless H.264 out of staging and into the uAPI should facilitate further developments.
I intend to try some of these things in the nearer future. Thanks to everyone who works on mainlining all of this VPU stuff, and to users here who contribute solutions and readily & patiently answer questions (Jernej especially). I hope I didn't post any falsehoods out of ignorance, and welcome any corrections.
 
Other related threads here:
https://forum.armbian.com/topic/11551-4kp30-video-on-orange-pi-lite-and-mainline-hardware-acceleration/
https://forum.armbian.com/topic/16804-orange-pi-pc-h3-armbian-focal-5104-sunxi-av-tv-out-cvbs-enable/page/2/
https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/
https://forum.armbian.com/topic/13622-mainline-vpu/

Ok, so let's see the steps I followed.
 
1. Installed Armbian Unstable for OrangePi Zero2:
https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
 
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
 
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
 
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
 
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
 
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  

Ok, so let's see the steps I followed.
 
1. Installed Armbian Unstable for OrangePi Zero2:
https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
 
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
 
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
 
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
 
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
 
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  

Ok, so let's see the steps I followed.
 
1. Installed Armbian Unstable for OrangePi Zero2:
https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
 
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
 
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
 
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
 
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
 
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  

Ok, so let's see the steps I followed.
 
1. Installed Armbian Unstable for OrangePi Zero2:
https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
 
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
 
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
 
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
 
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
 
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  

Ok, so let's see the steps I followed.
 
1. Installed Armbian Unstable for OrangePi Zero2:
https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
 
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
 
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
 
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
 
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
 
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  

I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU.  I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver.  Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant.
 
@JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall.  The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design.  Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade.
 
I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.

You've been brave, but surrender, never
A bit a pity there's not more interest in this board. And I've not seen any other H616 SBCs coming. 
Their Orange(Armbian) images do seem ok. I wonder if we could not learn anything from their script/builds.
https://github.com/orangepi-xunlong/OrangePi_Build
They've copied Armbian, maybe Armbian should copy them now  
I don't know. Maybe this one should be a pass. Is the effort supporting it worth it? Tho the board is good for some use cases. 

@XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them
 
good luck - hexdump

@XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel
 
i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work
 
all that is not a perfect solution, but maybe its helpful for you on your way
 
good luck and best wishes - hexdump

@XFer012Check USB changes here https://github.com/jernejsk/linux-1/commit/a57b81d6188b0f8888d4856c17eff5c5e9816fd8 You can ignore others. Note the changes in number of phys in usbphy nodes.

@XFer012Above DT change will most probably lock up CPU - CPU is changing clock from which it is running. Much safer bet is to change CONFIG_SYS_CLK_FREQ in U-Boot to the frequency you want. There CPU is first switched to alternate (slow) clock source and once main CPU clock is adjusted, it's switched back.

You can try with (but no guarantee) in cpu0 node:
assigned-clocks = <&ccu CLK_CPUX>; assigned-clock-rates = <1080000000>; Safe default is set in SPL (one of the first things that's is done).
Note that everything is done by community without any plan. I just told you current pattern regarding these things. It could be that someone would prepare such patches soon or no one would find it interesting enough to work on it.

Check ohci, ehci and usbphy nodes in my DT: https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts#L134 and https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi. You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too.
Note that these are developer level instructions - I don't plan to write more detailed steps.

that gets sorted out usually very late, when a lot of other features are already working.
 
Those messages don't indicate alpha stage. Disabling just means that regulator was enabled at boot but Linux doesn't need it. "using dummy regulator" means that voltage regulator is not needed (vcc- regulators might get specified later but most of the time are not needed). syscon value message is imo useless and will probably get removed sooner or later.
In short - several of these messages will probably stay in later, more complete kernel.