Orange Pi Zero 3

[pixdrift]

Hi ag123,

 

I did take a look at this. The sunxi-cedrus module is already present in my Armbian image and loaded, you can confirm this from the lsmod output from the build I posted above.

 

From the docs, cedrus looks to be specifically for video encoding/decoding acceleration not display. I don't believe it's related to my display issue.

 

Regarding mainline support listed in:

https://linux-sunxi.org/Linux_mainlining_effort

 

H616 is listed with '?' for the HDMI elements, which is 'status unknown' not explicitly unsupported, and HDMI Video (assuming this is video output) for the H6 shows '5.0', so there may be some hope there.

 

My goal at the moment is to replicate the HDMI output that is in the Orange Pi SDK build (even if it requires kernel patching) in the clean Armbian build, I can confirm this works (just figuring out _how_ it works). I have looked through the Orange Pi SDK Linux/u-boot source and haven't found anything specific yet.. I will keep looking

[ag123]

I'm not sure if this is after all relevant

https://linux-sunxi.org/Display

Quote

HDMI

If you are using a device with HDMI and have proper script.bin for your device setting up display is as simple as adding disp.screen0_output_mode=EDID to your kernel command line in boot.scr file. You can specify a fixed mode like disp.screen0_output_mode=1280x1024p60 or a fallback in case EDID did not work disp.screen0_output_mode=EDID:1280x1024p60. The supported fallback display modes are currently hardcoded in the disp driver. Looking at the clock table in https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.0/drivers/video/sunxi/disp/disp_clk.c might be helpful.

https://linux-sunxi.org/Fex_Guide

https://github.com/linux-sunxi/sunxi-tools

https://linux-sunxi.org/Script.bin

Quote

script.bin is a board-specific binary "configuration file" used by Allwinner-specific drivers in the kernel (and also by the LiveSuit flashing program) with information on how to set-up various devices, ports and I/O pins on boards with Allwinner SoCs.

The corresponding human-readable file format is FEX, it is possible to convert .bin to .fex and back by using Sunxi-tools.

Build script.bin

 Note: This is only needed for running the legacy ("sunxi") Linux kernel, or kernels provided by the board vendor or Allwinner. For running an upstream (or "mainline") kernel, you should use the included device tree files.

 

My guess is script.bin is now replaced by device tree implementation for the same

 

[ag123]

more stuff googling for Mali as keyword

https://en.wikipedia.org/wiki/Mali_(processor)

https://github.com/cwabbott0/mali-isa-docs

https://docs.mesa3d.org/drivers/lima.html

 

and now "panfrost" shows up, this apparently is for recent versions of the Mali GPU, and probably include that on Orange Pi Zero 3

https://docs.mesa3d.org/drivers/panfrost.html

Panfrost
The Panfrost driver stack includes an OpenGL ES implementation for Arm Mali GPUs based on the Midgard and Bifrost microarchitectures. 
It is conformant on Mali-G52 and Mali-G57 but non-conformant on other GPUs. The following hardware is currently supported:
Product		Architecture	OpenGL ES	OpenGL
Mali G31	Bifrost (v7)	3.1		3.1

 

https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf

Figure 3-1 shows the system block diagram of the H616.

GPU G31

 

and this:

https://www.reddit.com/r/OrangePI/comments/16nrvs2/orange_pi_zero_3_gpu_acceleration_on_linux/

GPU is not enabled in the current builds be they 5.4 or 6.1 based, but you can enable it by editing the dtb.

dtc -I dtb -O dts /boot/dtb/allwinner/sun50i-h616-orangepi-zero3.dtb >/tmp/op3.dts

open /tmp/op3.dts with your favourite editor

search for 'mali'

- in the section where you find it edit the line status='disabled' to status='okay'

- recompile

dtc -I dts -O dtb /tmp/op3.dts >zero3.dtb

- Then replace the original with this after backing up and reboot.

- glxinfo should then show the panfrost driver in action.

Needs the 6.1 (next) kernel version for GPU as panfrost is not enabled to about 5.14

 

hopefully we are 1 step closer

[Stephen Graf]

I have been able to build images for the orange-pi zero3 using the Arabian build system. I spend the last few weeks helping to test u-boot on this board and the final patches have been put into u-boot v2024.01-rc5 which should be released Dec 18. I used rc4 and imported the u-boot patches when building Arabian. There was one patch that failed while building under rc4 but since it did not relate to zero3 I just removed the patch. There is one u-boot patch for emac timing that I had trouble with getting into the patch system. Without this patch the Ethernet port only works at 100Mhz. This patch is a kernel patch to the dts that is supposed to eventually come from linux. I did manage to hack the patch in very inelegantly and got the port to run at 1Ghz.

 

A lot of stuff does not work on this image, but it runs. Come Dec 18 and the release of u-boot v2024.01-rc5 we can at least build Armbian images and start working from there.

 

 

  ___  ____  _   _____             _____
 / _ \|  _ \(_) |__  /___ _ __ ___|___ /
| | | | |_) | |   / // _ \ '__/ _ \ |_ \
| |_| |  __/| |  / /|  __/ | | (_) |__) |
 \___/|_|   |_| /____\___|_|  \___/____/

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:   8%               Up time:       4 min
Memory usage:  13% of 919M      IP:            192.168.1.32
CPU temp:      34°C             Usage of /:    12% of 15G
RX today:      2.1 KiB

[ 0 security updates available, 18 updates total: apt upgrade ]
Last check: 2023-12-11 18:06

[pixdrift]

@Stephen Graf

I have posted some info about a config I am working on here. This config is a drop in for Armbian and references the mainline u-boot commit that includes the Orange Pi Zero 3 defconfig, so no patching of u-boot is required (but agreed, will be good when they tag with a release).

I also detail the single patch I have to remove for the image to build correctly on 'edge', but it doesn't appear to be the same image you mentioned? I built against 6.6.5 for my 'edge' image, I will rebuild now and see if I have similar results to yourself.

My issue with the image currently is that it doesn't provide any video out via HDMI, but I can login via serial console and confirm it's working.

Edited December 12, 2023 by pixdrift

[pixdrift]

@ag123 interesting to mentioned mali in the dtb, I found some kernel patches which refer to enabling mali for h616 that are specific to the zero2 board in Armbian.. looking at adding this patch to zero 3 and seeing if mali works.

The patch is:
 

/patch/kernel/sunxi-edge/patches.armbian/arm64-dts-sun50i-h616-orangepi-zero2-Enable-GPU-mali (modifies sun50i-h616-orangepi-zero2.dts)

 

I think I have found what we need

https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.1-sun50iw9/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero3.dts#L109-L123

I think swapping the .dts for the Orange Pi Zero 3 in mainline with the sunxi version would be a good test.. if not, just patch in the hdmi/gpu config lines.. see what happens with this now.

Edited December 12, 2023 by pixdrift

[wast3d55]

@pixdrift Thanks for the detailed breakdown! I have a model with 4gb RAM too, can help with building and testing firmware on different monitors (1400*900 and 1920*1080).

[pixdrift]

Hi @wast3d55, thanks for the offer.. I will try and get something workable that displays and let you know 

So a few more minor updates.. just sharing my process! (TLDR, panfrost is loading and detecting the correct mali device, but no HDMI yet)

I tried patching in the entire orangepi dts from the orangepi repo, but had compilation failures due to the hdmi references (expected as much, it was a bit of a moon shot).

After that experiment I just patched in the 'gpu' block from the orangepi repo dts.. and it's showing some positive results. Note, this is now building with 6.6.6 mainline kernel (as I am using edge and it has bumped up from 6.6.5) with the following patch applied (patched in by armbian build). This patch is basically replicating the zero2 patch that is already in Armbian, but with the updated address from the orangepi repo dts. I have also switched status to "okay" so it loads, but unfortunately this doesn't provide the same magic that is described in the instructions linked by @ag123 because the dts in mainline is missing the HDMI components (my theory).

 

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
index 00fe28caa..8a80de136 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
@@ -16,6 +16,11 @@
        phy-supply = <&reg_dldo1>;
 };

+&gpu {
+        mali-supply = <&reg_dcdc1>;
+        status = "okay";
+};
+
 &ext_rgmii_phy {
        motorcomm,clk-out-frequency-hz = <125000000>;
 };

Now, no display still, but it is looking promising. I still need to validate if below was because of the 6.6.6 kernel change, or because of my dts patch.  @Stephen Graf can you lsmod your 6.6.6 image that doesn't have the patch?, or I can build a clean (no zero3 mali patch) 6.6.6 to compare.
 

root@orangepizero3:~# uname -a
Linux orangepizero3 6.6.6-edge-sunxi64 #1 SMP Mon Dec 11 09:40:17 UTC 2023 aarch64 GNU/Linux
root@orangepizero3:~# dmesg | grep -i mali
[    6.297358] panfrost 1800000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0
root@orangepizero3:~# lsmod
Module                  Size  Used by
rfkill                 24576  1
sunrpc                290816  1
lz4hc                  12288  0
lz4                    12288  0
zram                   28672  3
binfmt_misc            20480  1
polyval_ce             12288  0
polyval_generic        12288  1 polyval_ce
panfrost               69632  0
gpu_sched              32768  1 panfrost
fuse                  126976  1
dm_mod                131072  0
motorcomm              24576  1
dwmac_sun8i            24576  0
mdio_mux               12288  1 dwmac_sun8i
root@orangepizero3:~# dmesg | grep -i hdmi
root@orangepizero3:~#

I think the missing piece now is the HDMI configuration that is included in the orangepi repo dts, this appears to be missing in the mainline dts. I am going to see if I can pull that apart next and at least get hdmi modules loading.

Edited December 12, 2023 by pixdrift

[Stephen Graf]

This is from the stock build without patches for gpu.

 

sysadmin@orangepizero3:~$ lsmod
Module                  Size  Used by
rfkill                 24576  1
sunrpc                290816  1
lz4hc                  12288  0
lz4                    12288  0
sunxi_cedrus           49152  0
v4l2_mem2mem           28672  1 sunxi_cedrus
videobuf2_dma_contig    20480  1 sunxi_cedrus
videobuf2_memops       16384  1 videobuf2_dma_contig
videobuf2_v4l2         20480  2 sunxi_cedrus,v4l2_mem2mem
videodev              221184  3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem
polyval_ce             12288  0
videobuf2_common       45056  5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4lmemops
polyval_generic        12288  1 polyval_ce
mc                     57344  5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_commo
zram                   28672  3
binfmt_misc            20480  1
fuse                  126976  1
dm_mod                131072  0
motorcomm              24576  1
dwmac_sun8i            24576  0
mdio_mux               12288  1 dwmac_sun8i
sysadmin@orangepizero3:~$

[Stephen Graf]

I also seem to have a video device.  Unfortunately I am still waiting delivery of a micro HDMI adapter.

[Stephen Graf]

Video device from ls /dev

 

crw-rw----  1 root tty       7,  70 Dec 11 22:14 vcsu6
crw-------  1 root root     10, 137 Dec 11 22:14 vhci
crw-rw----  1 root video    81,   0 Dec 11 22:14 video0
crw-------  1 root root     10, 130 Dec 11 22:14 watchdog
crw-------  1 root root    247,   0 Dec 11 22:14 watchdog0

[ag123]

I did more google searches for possible keywords:

[v4,0/8] Allwinner H6 Mali GPU support

https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190512174608.10083-1-peron.clem@gmail.com/

 

a DTS for H6

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts?h=v6.6

but note that H6 has a different gpu from H616 but possibly 'similar'

 

from kernel versions 6.6 and above H616, H618 dts (device tree source) is made up of an include template

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi?h=v6.6

 

and a board specific template

for OPi Zero 2

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts?h=v6.6

then for OPi Zero 3

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts?h=v6.6

 

in the linux sunxi-for-next repository

the only things found in the board is addition of dts template for OrangePi Zero 2W

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/for-next

 

mali gpu and hdmi doesn't seemed featured in all 3 of them (Zero 2, Zero 3, Zero 2w). We may need to review how it is done in H6 to see if after all the same driver works similarly 

some abstracts from H6 dtsi

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi?h=sunxi/for-next

// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>

#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/sun50i-h6-ccu.h>
#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
#include <dt-bindings/clock/sun6i-rtc.h>
#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun8i-tcon-top.h>
#include <dt-bindings/reset/sun50i-h6-ccu.h>
#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
#include <dt-bindings/reset/sun8i-de2.h>
#include <dt-bindings/thermal/thermal.h>

/ {
	interrupt-parent = <&gic>;
	#address-cells = <1>;
	#size-cells = <1>;
  
	cpus {
  ... line 65
  	de: display-engine {
		compatible = "allwinner,sun50i-h6-display-engine";
		allwinner,pipelines = <&mixer0>;
		status = "disabled";
	};
  ... line 105
  	soc {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;
  		bus@1000000 {
			compatible = "allwinner,sun50i-h6-de3",
				     "allwinner,sun50i-a64-de2";
			reg = <0x1000000 0x400000>;
			allwinner,sram = <&de2_sram 1>;
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0 0x1000000 0x400000>;

			display_clocks: clock@0 {
				compatible = "allwinner,sun50i-h6-de3-clk";
				reg = <0x0 0x10000>;
				clocks = <&ccu CLK_BUS_DE>,
					 <&ccu CLK_DE>;
				clock-names = "bus",
					      "mod";
				resets = <&ccu RST_BUS_DE>;
				#clock-cells = <1>;
				#reset-cells = <1>;
			};

			mixer0: mixer@100000 {
				compatible = "allwinner,sun50i-h6-de3-mixer-0";
				reg = <0x100000 0x100000>;
				clocks = <&display_clocks CLK_BUS_MIXER0>,
					 <&display_clocks CLK_MIXER0>;
				clock-names = "bus",
					      "mod";
				resets = <&display_clocks RST_MIXER0>;
				iommus = <&iommu 0>;

				ports {
					#address-cells = <1>;
					#size-cells = <0>;

					mixer0_out: port@1 {
						reg = <1>;

						mixer0_out_tcon_top_mixer0: endpoint {
							remote-endpoint = <&tcon_top_mixer0_in_mixer0>;
						};
					};
				};
			};
		};

		video-codec-g2@1c00000 {
			compatible = "allwinner,sun50i-h6-vpu-g2";
			reg = <0x01c00000 0x1000>;
			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&ccu CLK_BUS_VP9>, <&ccu CLK_VP9>;
			clock-names = "bus", "mod";
			resets = <&ccu RST_BUS_VP9>;
			iommus = <&iommu 5>;
		};

		video-codec@1c0e000 {
			compatible = "allwinner,sun50i-h6-video-engine";
			reg = <0x01c0e000 0x2000>;
			clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
				 <&ccu CLK_MBUS_VE>;
			clock-names = "ahb", "mod", "ram";
			resets = <&ccu RST_BUS_VE>;
			interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
			allwinner,sram = <&ve_sram 1>;
			iommus = <&iommu 3>;
		};

		gpu: gpu@1800000 {
			compatible = "allwinner,sun50i-h6-mali",
				     "arm,mali-t720";
			reg = <0x01800000 0x4000>;
			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
				     <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
				     <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
			interrupt-names = "job", "mmu", "gpu";
			clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
			clock-names = "core", "bus";
			resets = <&ccu RST_BUS_GPU>;
			#cooling-cells = <2>;
			status = "disabled";
		};
  
		crypto: crypto@1904000 {
			compatible = "allwinner,sun50i-h6-crypto";
			reg = <0x01904000 0x1000>;
			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>, <&ccu CLK_MBUS_CE>;
			clock-names = "bus", "mod", "ram";
			resets = <&ccu RST_BUS_CE>;
		};

		syscon: syscon@3000000 {
			compatible = "allwinner,sun50i-h6-system-control",
				     "allwinner,sun50i-a64-system-control";
			reg = <0x03000000 0x1000>;
			#address-cells = <1>;
			#size-cells = <1>;
			ranges;

			sram_c: sram@28000 {
				compatible = "mmio-sram";
				reg = <0x00028000 0x1e000>;
				#address-cells = <1>;
				#size-cells = <1>;
				ranges = <0 0x00028000 0x1e000>;

				de2_sram: sram-section@0 {
					compatible = "allwinner,sun50i-h6-sram-c",
						     "allwinner,sun50i-a64-sram-c";
					reg = <0x0000 0x1e000>;
				};
			};

			sram_c1: sram@1a00000 {
				compatible = "mmio-sram";
				reg = <0x01a00000 0x200000>;
				#address-cells = <1>;
				#size-cells = <1>;
				ranges = <0 0x01a00000 0x200000>;

				ve_sram: sram-section@0 {
					compatible = "allwinner,sun50i-h6-sram-c1",
						     "allwinner,sun4i-a10-sram-c1";
					reg = <0x000000 0x200000>;
				};
			};
		};

		ccu: clock@3001000 {
			compatible = "allwinner,sun50i-h6-ccu";
			reg = <0x03001000 0x1000>;
			clocks = <&osc24M>, <&rtc CLK_OSC32K>, <&rtc CLK_IOSC>;
			clock-names = "hosc", "losc", "iosc";
			#clock-cells = <1>;
			#reset-cells = <1>;
		};

		dma: dma-controller@3002000 {
			compatible = "allwinner,sun50i-h6-dma";
			reg = <0x03002000 0x1000>;
			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&ccu CLK_BUS_DMA>, <&ccu CLK_MBUS_DMA>;
			clock-names = "bus", "mbus";
			dma-channels = <16>;
			dma-requests = <46>;
			resets = <&ccu RST_BUS_DMA>;
			#dma-cells = <1>;
		};
... line 783
		hdmi: hdmi@6000000 {
			compatible = "allwinner,sun50i-h6-dw-hdmi";
			reg = <0x06000000 0x10000>;
			reg-io-width = <1>;
			interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>,
				 <&ccu CLK_HDMI>, <&ccu CLK_HDMI_CEC>,
				 <&ccu CLK_HDCP>, <&ccu CLK_BUS_HDCP>;
			clock-names = "iahb", "isfr", "tmds", "cec", "hdcp",
				      "hdcp-bus";
			resets = <&ccu RST_BUS_HDMI_SUB>, <&ccu RST_BUS_HDCP>;
			reset-names = "ctrl", "hdcp";
			phys = <&hdmi_phy>;
			phy-names = "phy";
			pinctrl-names = "default";
			pinctrl-0 = <&hdmi_pins>;
			status = "disabled";

			ports {
				#address-cells = <1>;
				#size-cells = <0>;

				hdmi_in: port@0 {
					reg = <0>;

					hdmi_in_tcon_top: endpoint {
						remote-endpoint = <&tcon_top_hdmi_out_hdmi>;
					};
				};

				hdmi_out: port@1 {
					reg = <1>;
				};
			};
		};

		hdmi_phy: hdmi-phy@6010000 {
			compatible = "allwinner,sun50i-h6-hdmi-phy";
			reg = <0x06010000 0x10000>;
			clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>;
			clock-names = "bus", "mod";
			resets = <&ccu RST_BUS_HDMI>;
			reset-names = "phy";
			#phy-cells = <0>;
		};

 

As gpu includes various blocks, e.g. hdmi, the gpu itself e.g. Mali and panfrost drivers, and DMA, more may be at hand to get display working.

The clocks are also important as in these SOCs we may need to enable/setup clocks to the various modules (e.g. HDMI, GPU, DMA etc) to 'turn them on'.

And there can be a lot more such as video sync clocks etc, which probably is less relevant to HDMI, but that it is likely the geometry related setup (e.g. the W x H pixels, color depths and refresh rates for the frame buffers needs to be configured.

There are very little docs out there about these in that regard.
The sram blocks are probably there in h6 but likely not relevant to h616, h618. H6 has a separate processor within the SOC which accordingly is intended for various PMIC functions. e.g. turn off power.

In Orange Pi Zero 3, that is probably adequately replaced by the AXP313A PMIC chip.

 

There is also this thing about AC200 which apparently is relevant to H6 as well as H616, H618

https://linux-sunxi.org/AC200

But I think AC200 is mainly relevant to ethernet as the EPHY is there. The other 2 functional blocks in the AC200 is audio and composite video is probably different from HDMI.

It is a bit strange as in H618 there is a separate motorcomm YT8531C Gigabit ethernet PHY, it is likely AC200 functionality is not used.

 

 

 

[pixdrift]

I created a patch to bring across all the HDMI elements in the Orange Pi SDK dtsi to support the configuration in the dts/dtb file for the zero3.

This took a fair bit of effort (cascading dependencies), and the dtb builds cleanly, but still no display.. but I do now get display_connector showing up in lsmod.. so I suspect it's slightly closer again

 

root@orangepizero3:~# lsmod
Module                  Size  Used by
sunrpc                290816  1
lz4hc                  12288  0
lz4                    12288  0
zram                   28672  3
binfmt_misc            20480  1
polyval_ce             12288  0
polyval_generic        12288  1 polyval_ce
panfrost               69632  0
gpu_sched              32768  1 panfrost
fuse                  126976  1
dm_mod                131072  0
motorcomm              24576  1
dwmac_sun8i            24576  0
mdio_mux               12288  1 dwmac_sun8i
display_connector      16384  0

Now I have the following 'hdmi' lines mentioned in dmesg:
 

root@orangepizero3:~# dmesg | grep -i hdmi
[    0.025260] platform 6510000.tcon-top: Fixed dependency cycle(s) with /soc/hdmi@6000000/ports/port@0/endpoint
[    0.029227] platform connector: Fixed dependency cycle(s) with /soc/hdmi@6000000/ports/port@1/endpoint

 

will look for mentions of sun8i-dw-hdmi and sun4i-drm that show up in the hdmi messages in dmesg of the Orange Pi SDK image.

Edited December 13, 2023 by pixdrift

[Gunjan Gupta]

Its not just dts changes you need. You are also going to need changes for sun4i-drm module. I have tried to get sun4i-drm patch for h616 in. It conflicts with few other drm patches that I had to disable, but I got the display and wifi working with 6.6 kernel on Orange Pi Zero2w. Code can be found here - https://github.com/viraniac/armbian_build/tree/zero2w

 

PS: I don't have a zero2, Zero2w or Zero3 device, changes were tested by a friend on his zero2w. 

[pixdrift]

Thanks for the information and the repo link @Gunjan Gupta, I have  Zero2 here and will be able to test it.

I am assuming you went down this route (getting video working on Zero2) because the current configuration in Armbian only provides serial for the Zero2?

I will build off your repo for the Zero2 and see what results I get.

Thanks again, great information!

[Gunjan Gupta]

@pixdriftI didn't do it for Zero2, I did it for Zero2w. A friend of mine has got that device asked my help to get alpine running on it with6.6 kernel and getting hdmi and wifi working. We used armbian build framework to ease kernel compilation efforts.

[pixdrift]

Thanks @Gunjan Gupta, I hadn't taken a look at the Zero2w, I thought it was a basic variant of the Zero2, but it's an H618 with DDR4, basically the same as the Zero3.. which makes this information very relevant.

The Zero2W is a pretty amazing board with the expansion.. I just ordered one 
 

Rather than testing this on Zero2, I will take a closer look at your patches for Zero3.. thanks!

[pixdrift]

Success!

Will post more details soon, but combining my u-boot mainline config, dts config and the work from @Gunjan Gupta it built a clean working image. Don't have time at the moment to get all the details posted, but here is the lsmod showing it using panfrost. It's built against 6.6.4, was having issues with the sun4i-drm on edge (6.6.7 now), will dig through that later.
 

root@orangepizero3:~# uname -a
Linux orangepizero3 6.6.4-edge-sunxi64 #1 SMP Sun Dec  3 06:33:10 UTC 2023 aarch64 GNU/Linux
root@orangepizero3:~# lsmod
Module                  Size  Used by
rfkill                 24576  1
sunrpc                290816  1
lz4hc                  12288  0
lz4                    12288  0
binfmt_misc            20480  1
zram                   28672  3
sunxi_cedrus           49152  0
v4l2_mem2mem           28672  1 sunxi_cedrus
videobuf2_dma_contig    20480  1 sunxi_cedrus
videobuf2_memops       16384  1 videobuf2_dma_contig
videobuf2_v4l2         20480  2 sunxi_cedrus,v4l2_mem2mem
polyval_ce             12288  0
videodev              221184  3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem
snd_soc_hdmi_codec     20480  0
apple_mfi_fastcharge    16384  0
videobuf2_common       45056  5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops
panfrost               69632  0
polyval_generic        12288  1 polyval_ce
mc                     57344  5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
gpu_sched              32768  1 panfrost
drm_shmem_helper       16384  1 panfrost
dump_reg               20480  0
fuse                  126976  1
dm_mod                131072  0
hid_apple              24576  0
motorcomm              24576  1
dw_hdmi_cec            12288  0
dw_hdmi_i2s_audio      12288  0
dwmac_sun8i            24576  0
mdio_mux               12288  1 dwmac_sun8i
display_connector      16384  0

Massive thanks @Gunjan Gupta, the sun4i patch was the missing piece.
 

[Gunjan Gupta]

Happy to help. I am waiting for my Zero3. It should be delivered in 10-15 days. Once its here, will integrate the changes into Armbian.

[pixdrift]

Thanks @Gunjan Gupta I have forked your github zero2w repo and will add everything I have (patches/config) to get zero 3 working so it's based off your existing work with minimal changes... hoping we can then work to get both boards into the mainline Armbian

https://github.com/pixdrift/armbian_build/tree/zero3

I will post back here when I have all the changes tidied up, merged in, and building cleanly.

[ag123]

I think zero 2 w is quite similar to zero 3, it seemed to be a 'zero 3' less the onboard ethernet

https://www.cnx-software.com/2023/09/09/orange-pi-zero-2w-raspberry-pi-zero-2w-alternative-4gb-ram/

hopefully that these 2 boards can work on a same/similar setup.

But that I only have the zero 3

[pixdrift]

I have added the required patches so this will now build cleanly for the Orange Pi Zero 3 for anyone that wants to build images for testing (still have testing of other components)

To build your own image (Debian 12 tested so far)
 

git clone https://github.com/pixdrift/armbian_build.git
cd armbian_build
git checkout zero3
./compile.sh

Then select orangepizero3 from the menu, and then select your image build options.

Now that we are at this stage, wonder if it's worth moving this into a forum thread rather than the current 'question' format? and we can then work on testing/validating the build. I am happy to build/host some images if that would be testing easier for others who may not have the build environment setup. I think this would be better in a forum thread now though.

I also saw @Stephen Graf mention Zero2 in another thread (not to be confused with Zero2W). I have a Zero2 here so can take a look at getting the HDMI working on there too (I don't believe it's currently enabled, but can discuss that in a separate chat.. it shouldn't be too difficult now all the 616 groundwork is in)

[Gunjan Gupta]

@pixdriftCould you please test wifi on Zero2 using my orangepizero2 branch? Once confirmed, I would be able to get this merged - https://github.com/armbian/build/pull/6040

[pixdrift]

Hu @Gunjan Gupta,

 

I would prefer to fix/text HDMI first (or at the same time) if we can.
 

For some reason the Zero2 configuration in Armbian doesn't include video, likely because it was built from the original zero configuration that doesn't have HDMI? It also defaults the console to serial... I guess there is also the point that the H616 dtsi hasn't had HDMI configuration until about now
https://github.com/armbian/build/blob/8da1805f9081e85dc3016e3e357e5f4836374e6a/config/boards/orangepizero2.conf#L8-L9

With your changes to the H616 dtsi, this should be a simple case of adding the GPU/HDMI configuration to the DTS, I was planning to test this next.. keen to hear your thoughts on that.

Regarding wifi on the zero2 board (and testing in general), is there a test harness/test script you want to run on it to validate it? Should we take this opportunity to formalise a few tests for this and the zero3? Not sure how testing/CI is currently carried out on updated board configuration and images (other than they build cleanly!). 'bats' is my go to for this usually.
https://github.com/bats-core/bats-core

I don't know the ins and outs of getting wifi working (keen to understand all the components), so I haven't included it in the current zero3 config in my repo.. not sure if it's just a copy of the zero2w config? (it's lower down my list as it's not my primary use case tbh).

Also, interested to know where you get details on the ehci/ochci devices, and the physical devices they map to on the board. I notice that the zero2 config mentions two are on the expansion board.. so I am deducing that there is one on the board, one via the GPIO pins and then two on the zero expansion board.. interested to know how I can map this configuration to the physical layout on the different boards (if anyone can explain it, or send docs I would appreciate it!)

[Gunjan Gupta]

49 minutes ago, pixdrift said:

 

For some reason the Zero2 configuration in Armbian doesn't include video, likely because it was built from the original zero configuration that doesn't have HDMI? It also defaults the console to serial... I guess there is also the point that the H616 dtsi hasn't had HDMI configuration until about now

The sun4i-drm patch needs a lot of work before it can merge into Armbian and without it there will be no HDMI support. It conflicts with a lot of other patches. I am planning to work on it next week.

 

52 minutes ago, pixdrift said:

Regarding wifi on the zero2 board (and testing in general), is there a test harness/test script you want to run on it to validate it?

All thats needed is building an image for current and edge kernels, flash it on sdcard and boot on zero2. See if you are provided an option to connect to wifi and if you are able to connect to it.

[Stephen Graf]

Both the wifi and HDMI work should be common to both the zero2 and zero3 and possibly the zero2w.  Would it be possible to work in an environment that supports both?

[Gunjan Gupta]

The changes in the PR is done in the way so that wifi should be working on both zero2 and zero3 on edge kernel. Its just there is no board config file for zero3, and as zero3 is not currently a supported board I only need confirmation for zero2.

[pixdrift]

I can confirm the wifi is working @Gunjan Gupta in the Zero2 image in your pull request. It prompts on initial configuration.. and works out of the box..
I tested both 2.4 Ghz and 5 Ghz, got DHCP address, connected to the Internet etc. all good.

Only odd things I have noticed about the image (not likely introduced by these changes)

1. The image doesn't like rebooting and appears to get stuck waiting.. not sure if wifi related (once again, unlikely to be kernel change). I have had this every time I attempt to reboot it, and have to hard power cycle it.
 

[  OK  ] Finished systemd-reboot.service - System Reboot.
[  OK  ] Reached target reboot.target - System Reboot.
[  820.749967] systemd-shutdown[1]: Failed to set timeout to 10min: Invalid argument
[  830.901508] systemd-shutdown[1]: Waiting for process: 788 (armbian-hardwar), 771 (lscpu), 828 (lscpu)
[  920.929626] systemd-shutdown[1]: Waiting for process: 828 (lscpu), 788 (armbian-hardwar), 771 (lscpu)
[ 1000.964547] (sd-remount)[2373]: Failed to remount '/' read-only: Device or resource busy
[ 1000.978516] systemd-shutdown[1]: Failed to finalize file systems, ignoring.


2. The load average seems to remain pretty constant at 1.00 when it's idle.. it does drop and go up occasionally..  not sure what's going on there.. doesn't appear to be in process time or iowait
 

top - 14:42:06 up 41 min,  1 user,  load average: 1.00, 1.00, 1.00
Tasks: 193 total,   1 running, 192 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.7 us,  1.0 sy,  0.0 ni, 98.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    919.2 total,    631.5 free,    183.6 used,    173.2 buff/cache
MiB Swap:    459.6 total,    459.6 free,      0.0 used.    735.6 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1837 root      20   0   11540   4864   2816 R   1.3   0.5   0:06.05 top
      1 root      20   0  169416  12384   8416 S   0.0   1.3   0:04.42 systemd
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.02 kthreadd
      3 root      20   0       0      0      0 S   0.0   0.0   0:00.00 pool_wo+
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
      5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
      7 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
     12 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
     13 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tas+
     14 root      20   0       0      0      0 S   0.0   0.0   0:00.04 ksoftir+
     15 root      20   0       0      0      0 I   0.0   0.0   0:00.28 rcu_sch+
     16 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migrati+
     17 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0

 Happy to provide feedback in the PR that it's all good.. I will try and drag these changes across into the Zero3 config I have.

[Gunjan Gupta]

33 minutes ago, pixdrift said:

The image doesn't like rebooting and appears to get stuck waiting.

Hmm, interesting...Not sure why that happened.

 

33 minutes ago, pixdrift said:

The load average seems to remain pretty constant at 1.00 when it's idle.

This is caused by sprd_ng module aka uwe5622 wifi driver. Same thing happens on Orange Pi 3 LTS as well.

[pixdrift]

30 minutes ago, Gunjan Gupta said:

This is caused by sprd_ng module aka uwe5622 wifi driver. Same thing happens on Orange Pi 3 LTS as well.

Interesting, well at least it's a known issue!

 

I have updated my zero 3 branch with the Ethernet stability patch (this also impacts zero 2).
https://github.com/viraniac/armbian_build/commit/6af178324c8b4f2407f263f3f2b35d8b1e977da9

 I should probably raise a PR back to your zero2w branch soon.. was thinking of adding wifi to the zero 3. Is your patch for zero 2 that I just tested the same as what you have in zero 2w?

Edited December 15, 2023 by pixdrift