pixdrift Posted December 11, 2023 Posted December 11, 2023 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 0 Quote
ag123 Posted December 12, 2023 Author Posted December 12, 2023 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 0 Quote
ag123 Posted December 12, 2023 Author Posted December 12, 2023 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 0 Quote
Stephen Graf Posted December 12, 2023 Posted December 12, 2023 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 0 Quote
pixdrift Posted December 12, 2023 Posted December 12, 2023 (edited) @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 0 Quote
pixdrift Posted December 12, 2023 Posted December 12, 2023 (edited) @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 0 Quote
wast3d55 Posted December 12, 2023 Posted December 12, 2023 @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). 0 Quote
pixdrift Posted December 12, 2023 Posted December 12, 2023 (edited) 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 = <®_dldo1>; }; +&gpu { + mali-supply = <®_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 0 Quote
Stephen Graf Posted December 13, 2023 Posted December 13, 2023 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:~$ 0 Quote
Stephen Graf Posted December 13, 2023 Posted December 13, 2023 I also seem to have a video device. Unfortunately I am still waiting delivery of a micro HDMI adapter. 0 Quote
Stephen Graf Posted December 13, 2023 Posted December 13, 2023 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 0 Quote
ag123 Posted December 13, 2023 Author Posted December 13, 2023 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. 0 Quote
pixdrift Posted December 13, 2023 Posted December 13, 2023 (edited) 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 0 Quote
Gunjan Gupta Posted December 13, 2023 Posted December 13, 2023 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. 0 Quote
pixdrift Posted December 13, 2023 Posted December 13, 2023 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! 0 Quote
Gunjan Gupta Posted December 13, 2023 Posted December 13, 2023 @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. 0 Quote
pixdrift Posted December 13, 2023 Posted December 13, 2023 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! 0 Quote
pixdrift Posted December 14, 2023 Posted December 14, 2023 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. 1 Quote
Gunjan Gupta Posted December 14, 2023 Posted December 14, 2023 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. 0 Quote
pixdrift Posted December 14, 2023 Posted December 14, 2023 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. 1 Quote
ag123 Posted December 14, 2023 Author Posted December 14, 2023 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 0 Quote
pixdrift Posted December 14, 2023 Posted December 14, 2023 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) 0 Quote
Gunjan Gupta Posted December 14, 2023 Posted December 14, 2023 @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 0 Quote
pixdrift Posted December 14, 2023 Posted December 14, 2023 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!) 0 Quote
Gunjan Gupta Posted December 14, 2023 Posted December 14, 2023 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. 1 Quote
Stephen Graf Posted December 14, 2023 Posted December 14, 2023 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? 1 Quote
Gunjan Gupta Posted December 15, 2023 Posted December 15, 2023 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. 0 Quote
pixdrift Posted December 15, 2023 Posted December 15, 2023 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. 0 Quote
Gunjan Gupta Posted December 15, 2023 Posted December 15, 2023 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. 0 Quote
pixdrift Posted December 15, 2023 Posted December 15, 2023 (edited) 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 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.