ag123

- dup -

I *think* some pins / IOs etc are disabled in dts, in part as these days pins has multiple (alternate) functions (e.g. gpio / i2c / uart / spi / usb etc). I'm not too sure if say the same pin is enabled for gpio and i2c that if they'd conflict with each other as in that in practice it would only be one of the function i2c or gpio that is valid. the device tree compiler dtc has become pretty common and used these days it shouldn't be too difficult for anyone to edit the dts file (e.g. change that status from 'disabled' to 'okay' and re-compile that into its dtb file, then reboot. some non-armbian examples are like: https://mjoldfield.com/atelier/2017/03/rpi-devicetree.html ^ in fact even without the dts file, it is possible to take the dtb file and convert that to a dts file, make the edits and recompile that back to the edited dtb file. other examples: https://www.udoo.org/forum/threads/manually-editing-device-tree-dts-files.21600/ https://www.emcraft.com/som/vf6/controlling-gpio-from-linux dtsi are includes, so that those common things get included as common templates, and the differences changes are updated in the final dts file for the board. I think boot loaders like uboot may be possible to choose different dts/dtb file etc on the boot prompt command line, but I'm not sure how nor have i tried that. more interesting reading about device tree, https://elinux.org/images/a/a3/Elce2013-petazzoni-devicetree-for-dummies.pdf it is invented originally for the beagle bone black, in fact it exist earlier, subsequent to that these days device tree has become a linux standard practice especially for single board computers. Computers used to have standard features e.g. drives, keyboard, mouse, usb and that practically they are 'all the same'. then came single board computers 'revolution' and there are 'capes' and FPGAs (hardware is software ! change the program and hardware changes !), and that GPIO pins are pin-muxed, so today hardware is *configurable*. e.g. if you place a led on a board, it can be physically wired to any of the gpio pins, and you can further wire it as LOW = ON (sink), or HIGH = ON (source). but that as an 'alternate' function e.g. a led, you may even configure PWM and blink patterns and/or events for the leds. that that is still a gpio pin, but that the function changes by simple virtue of the context. it is a led. https://elinux.org/images/1/19/Dynamic-dt-keynote-v3.pdf https://cdn-learn.adafruit.com/downloads/pdf/introduction-to-the-beaglebone-black-device-tree.pdf https://elinux.org/images/e/e2/Engaging_Device_Trees_0.pdf https://ofitselfso.com/BeagleNotes/AboutTheDeviceTree.pdf https://elinux.org/Device_Tree_Usage

@pixdrift thanks, I tried PR6127_20240103_919ec9a62_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.tar.xz from 2024-01-04 on a 2GB OrangePi Zero 3 board cpufreq-info works, thanks for the dts patches: armbian@orangepizero3:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:85.58%, 600 MHz:1.60%, 792 MHz:0.08%, 1.01 GHz:0.26%, 1.20 GHz:0.22%, 1.51 GHz:12.26% (173) analyzing CPU 1: ... armbian@orangepizero3:~$ armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:13:16 1512 MHz 1.08 5% 1% 2% 0% 1% 0% 41.3 °C 0/5 18:13:21 480 MHz 1.08 0% 0% 0% 0% 0% 0% 41.3 °C 0/5 18:13:26 480 MHz 1.07 0% 0% 0% 0% 0% 0% 40.9 °C 0/5 other stuff looks good the login: ___ ____ _ _____ _____ / _ \| _ \(_) |__ /___ _ __ ___|___ / | | | | |_) | | / // _ \ '__/ _ \ |_ \ | |_| | __/| | / /| __/ | | (_) |__) | \___/|_| |_| /____\___|_| \___/____/ Welcome to Armbian-unofficial 24.2.0-trunk Bookworm with bleeding edge Linux 6.7.0-rc7-edge-sunxi64 No end-user support: built from trunk System load: 26% Up time: 3 min Memory usage: 7% of 1.94G IP: 192.168.1.173 CPU temp: 37°C Usage of /: 7% of 29G RX today: 72.6 MiB armbian@orangepizero3:~$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:00:6c:53:f7:f9 brd ff:ff:ff:ff:ff:ff 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT mode DORMANT group default qlen 1000 link/ether 80:a0:53:73:a3:89 brd ff:ff:ff:ff:ff:ff Ethernet / Wifi works as prior, only tested in console (e.g. serial) as well as ssh over ethernet.

I made some progress to run armbian build *compile.sh* in a systemd-nspawn container https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35 It did create the loop devices in systemd-nspawn, but it still fail subsequently in accessing the partitions in the loop device. -- I'd try out the test binaries from @pixdrift for the time being

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

@Werner is right, there is no Armbian images currently for Zero 2W and Zero 3. But that if you are willing to play with *experimental* stuff i.e. no assurance of anything or if it even works, you may like to try an Zero 3 *wild experimental totally unsupported use at your own risk* image If anything works as a result, which presumbly shouldn't work, do feedback in that thread or this about your findings

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

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

@pixdrift Thanks, I tried: https://rpmbuild.pixeldrift.net/armbian/orangepi/zero3/ the file from 2023-12-17 22:14 427M https://rpmbuild.pixeldrift.net/armbian/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.4.everything.tar.xz it boots to the prompt (monitored from serial console) and I've got both ethernet and wifi up. 5ghz I got a throughput at about 90 Mbps running hostapd on OrangePi Z3 this armbian build as a WiFI hotspot. The hostapd.conf is like such: https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 I found out something about selecting frequencies at 5ghz: first run sudo iw list, it'd give a pretty big report with in addition frequencies at 2.4ghz and 5ghz, the available channels are given in [] (square brackets). selecting a channel in the [] (square brackets) do work in hostapd.conf Ethernet is running at 100 Mbps partly due to my upstream hub i'd guess, but otherwise, network seemed good both ethernet and wifi. I'd think if you have ethernet at 1 Gbps, the wifi hotspot can operate at throughput higher than 100 Mbps. I've not tested other stuff (display etc). Need to work on my own build environment as well, to fix it so that i can build it from source. a small blurb though, it seemed the cpu-frequency drivers are not built into the kernel? root@orangepizero3:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.

@pixdrift yes dtsi are dts includes while dts alone are device tree source. and i think dts would override the includes e.g. dtsi can have a status = "disabled" while dts have a status = "okay" https://elinux.org/Device_Tree_Linux#disabled_nodes but i think it is probably unnecessary to include the full template if it is defined in the include I think after it is compiled into the binary using dtc , the resulting dtb file would be the net single definitions

have been caught out in other matters hence have not caught up with the progress. as for the Wifi driver with a load of 1, I'd think it is partly a problem in the design of the driver. Which practically means it may take a re-write of the driver at least those parts that causes it to do away with the constant load of 1. But guess is that rather then being 'event' or 'interrupt' driven, it resorts to polling lets just say go into an infinite while loop doing the poll e.g. while(pin_has_not_changed()); that in itself may be good enough to keep it at a load of 1, but that I'm not sure if that is after all a possible cause. note that those codes are actually *spinlocks* https://en.wikipedia.org/wiki/Spinlock which may not necessarily cause a load. But that indefinite spinlock say monitors a change in state of a pin / bit can be trouble. the alternatives are to place delays between the polls or switch to an event or interrupt driven design. as in your post, i'm not too sure if the codes literally disabled interrupts while staying in an indefinite spinlock, i.e. it goes in a perpetual busy loop and cannot be interrupted. that is really bad design. I think interrupts is another thing that is poorly documented for these SOCs, and the devices. for the time being, I think we'd 'ignore' it, it is good enough that 'it works' for a start

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

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.

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

I'm not sure if this is after all relevant https://linux-sunxi.org/Display https://linux-sunxi.org/Fex_Guide https://github.com/linux-sunxi/sunxi-tools https://linux-sunxi.org/Script.bin My guess is script.bin is now replaced by device tree implementation for the same

saw that cedrus keyword, hence googled and stumbled into this: https://linux-sunxi.org/Sunxi-Cedrus H6 Supported (5.1) Supported (5.0) H616 Untested Untested if we made an assumption that H616, H618 is a 'simplified' H6, there is a chance it may work. However, while reading that I'm nore sure if that is after all part of mainline etc. e.g. can we find an option to select 'cedrus' in the make config, at least as a module? but that beyond just the kernel, some support may be needed in u-boot as well. But that if u-boot doesn't have display support, it may mean having to go the uart console route, until it loads and start the kernel, then for the kernel to initialize and start the display i really dislike those 'arbitrary' register writes, but I'd guess there is little choice if after all it is undocumented. and after GPU is 'enabled', how do the kernel knows where is the framebuffer etc? I'd think there'd need to be a 'driver' of some sort. cedrus is an astonishing effort 700 thousand commits https://github.com/bootlin/linux-cedrus https://linux-sunxi.org/Cedrus

it seem for H616, H618, video (i.e. the gpu, hdmi video) isn't supported yet in mainline https://linux-sunxi.org/Linux_mainlining_effort there is a driver called panfrost https://github.com/hexdump0815/imagebuilder/blob/main/systems/allwinner_h616/readme.md But that I've not researched how to get that

thanks for the update, as for myself, I'm still caught in a bind trying to build armbian as I'm using a systemd-nspawn container. it has to do with loop devices, systemd-nspawn do not allow loop devices, so it breaks the build and stop at the step where it builds the images. I've found some ways to get around the loop devices issue, but i hit further bummers as I don't just need a single loop device but loop control as well. And that is done with some pretty large workarounds so that I attempt to patch loop devices in systemd-nspawn container manually. -- But your attempts with 6.6 kernel is really good progress, hope I can reproduce that with 2GB boards. I think we'd 'focus' on 6.6 and above 'edge' builds for Orange Pi Zero 3 as I think this would most likely succeed, possibly 'easiest'. 6.1 if it is 'ever' done would be a 'back port' and I think it may not be that simple after all. There is a marginal chance that the same group of kernel developers may attempt that backport themselves, then it would make it possible to 'support' 6.1 with the developments at 6.6+ 'edge'. Orange Pi zero 3 requires LPDDR4 support and the new AXP313A PMIC support, for that alone, I don't think it'd work out of box in 6.1 as this 2 things has been developed (including the DTS) mainly for 6.6 kernel. This is gathered from reading the various posts and commit messages posted in comments earlier.

this is an 'off-topic' and an interesting blurb: for *ancient* people who understands what is BASIC (programming language) and PEEK and POKE https://en.wikipedia.org/wiki/PEEK_and_POKE it is given a modern twist, in a modern times in our modern Arm 32 / 64 bits SBC landscape, with gigabytes of memory, in full blown *Linux*, on the *shell* : https://github.com/apritzel/peekpoke ^ look who did it I think it has to do with mmap() , which likely does: map those registers into this window of memory, and now those *registers* GPIO (or any memory mapped hardware registers) etc, is right there at your disposal. This is similar but far more 'advanced' (light years) from those BASIC PEEK and POKE days. But that these days we are even more spoilt and asked for *device drivers* and/or /proc and /sys file system so that *everything is a file*, without even needing peek and poke. GPIO ? just peek and poke. how about 'bare metal linux', well we are close, right down to the metal

@pixdrift I'm thinking we'd need to try to start from the mainline u-boot https://source.denx.de/u-boot/u-boot as there are some changes as related Orange Pi Zero 3 H618 And as well with 6.6 mainline kernels and upwards. if you noted Andre Przywara's (likely from arm.com ! He has been pretty active in Linux sunxi https://linux-sunxi.org/H618 https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3which is an independent effort by open sourced developers separate from Orange Pi I think) commit in the *mainline kernels 6.6* about the Orange Pi Zero 3. i think that it is 'independent' as if you look carefully this git is the 'upstream', 'bleeding edge' of developments on linux-sunxi https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/ those changes developed in this repository, eventually get merged back into https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ the 'enterprise' of which the whole universe of Linux (imagine the millions of cloud containers, linux distributions, (debian, ubuntu, redhat (ibm), opensuse, Intel, AMD, Micsosoft, Nvidia, Arm, RISC-V etc and users running it) runs on I'm learning the ropes on building Armbian https://docs.armbian.com/Developer-Guide_Build-Preparation/ And I think this is a good starting point. The main point is to start with the 'edge' i.e. 6.6 and above kernels build which is supported by the Armbian build process (you can choose 'edge' kernel during the interactive setup for the build which is the 6.6 kernel (currently)). In that way, we can have a look at where are the gaps between mainline kernels and mainline u-boot vs getting it to run on Orange Pi Zero 3 H618. I'm of an opinion that if those commits in mainline are after all for Orange Pi Zero 3 H618, it probably means that someone has succeeded running it (the mainline kernel) on Orange Pi Zero 3. if you read this, the instructions are *very precise*, it practically means if you try that, you get Linux running on Orange Pi Zero 3. https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3 edit more news: https://lore.kernel.org/u-boot/20231114013106.31336-1-andre.przywara@arm.com/ (this is getting exciting, if you want to know what wizards@work practically means review that thread in the link, patching up usb, fixing up memory dram issues, clocking up dram speeds, hacking spi flash, putting uboot in SPI flash ! who needs bios these days (this is the *ultimate*, start from the beginning cpu cold start run 1st instruction and it is uboot ! ) -- Hence, this is a good starting point. But that as noted by Andre Przywara, the UWE5622 Wifi driver isn't yet in mainline, we'd probably graft that in back from Armbian which already has the codes. While building Armbian from the sources, start by selecting and building for Orange Pi Zero 2 H616 board and with 'edge' 6.6 kernels. This is the best base as H618 is an improved H616 but that on Orange Pi Zero 3, it uses LPDDR4 ram and has a different PMIC as noted in the above 2 references. This line of thought is 'rather important' as starting from mainline and integrating mainline is much more sustainable in the long run. Because after successful integration, and possibly tipping off linux-sunxi about these efforts, they could probably merge more codes into mainline and who knows Orange Pi Zero 3 may be 'supported' in mainline without needing to graft patches. And we may reach a point 'supporting' the board is basically setting up a 'config' file for the build and it 'just works' with mainline codes.

this topic is interesting and I delved a little into this rabbit hole for a little. the conventional KVM started in Intel's X86 and subquently AMD's X86_64 architecture https://linux-kvm.org/page/Main_Page then along the way came ARM virtualization extensions https://genode.org/documentation/articles/arm_virtualization https://developer.arm.com/documentation/102142/0100/Virtualization-host-extensions but that technically, this is running ARM instructions in a hardware enabled virtualization container. Hence, if one is thinking about emulating X86 codes that may be another universe on its own and another layer of complexity. So for that matter we consider the idea of running different ARM OS in ARM hardware virtualizations. So here are some links https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine#cite_note-7 https://systems.cs.columbia.edu/projects/kvm-arm/ https://web.archive.org/web/20130310052146/http://columbia.github.com/linux-kvm-arm/ https://github.com/columbia/linux-kvm-arm well that is KVM but have you also taken a look at Xen? https://xenproject.org/developers/teams/xen-hypervisor/ ^ I never fully understand the difference between Xen vs KVM until I reviewed the slides https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview#Host_and_Guest_Install https://help.ubuntu.com/community/Xen the details are quite complicated but hopefully it provide options, and I'm uncertain how well would that Xen hypervisor run on Allwinner H6.

agree with @Igor, supporting a board is a long term commitment and no easy feat. Those who are reading this thread should take it that there is no official Armbian release (not even 'community' nor 'unsupported') for this board (yet). The images tested prior to these comment includes: vendor's images some images created by 3rd parties (possibly including Armbian derivative) These are 'community efforts', attempts to run it on Orange Pi Zero 3 and is purely 'experimental'. But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here. Note that for a supported board, it would call on the community for continuous maintenance and integration, as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all. It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian. -- I've been (*messing*) experimenting with this board and I learned something, while one is messing with 'experimental' software, and 'experimental' boards e.g. this board. It is easy to think of it as a software problem. After all the experiments, it turns out some of my network woes I encountered are simply due to a defective network cable. But that said, there are 3rd party images or some such images there are broken in the software. issues with other (e.g. network) hardware are after all quite common e.g. in this case a problem with network hub, and in my case a defective network cable https://forum.armbian.com/topic/29954-sd-card-corrupt-after-hard-power-off/?do=findComment&comment=176561 i.e. there are so many blind spots when something doesn't work, and your hardware (including like cables, other hardware etc) should be in the checklist for troubleshooting.

I did one thing, changed the ethernet cable. Maybe I should have done that earlier now it looks different: I’ve just completed an Android apps update, Orange Pi Zero 3 is my Wifi hotspot, Orange Pi’s official ubuntu images released in Oct 23: orangepi@orangepizero3:~$ vnstat rx / tx / total eth0: today 413.90 MiB / 5.22 MiB / 419.12 MiB wlan0: today 4.24 MiB / 417.69 MiB / 421.93 MiB But that I only managed to configure a 2.4Ghz 802.11g wifi hotspot in the official images with hostapd. that is 40 Mbps. Throughput is decent, though i’m running at 100 Mbps at the ethernet end. 1 link drop, recovers on its own - it’s a new cable ! uptime 1 hour After replacing the cable with a new cable, link has been up 20 hours without ethernet completely freezing out, I'm still able to connect to the hotspot and use it normally after 20 hours. The above confirms that my ethernet woes are simply due to ethernet cable defect and not onboard hardware nor software. I’ve previously manually set the Ethernet to run at 100 Mbps via ethtool -s eth0 speed 100 , but that it is unknown why it sticks to 100 Mbps even across reboots. But for now I don’t think this is a defect, e.g. it could be due to my up stream hub etc. Hope that this paves the way towards eventually being supported in Armbian as well.

the SBC (single board computers) landscape is littered with *undeclared ethernet and wifi chips* (not given in specs when the boards are sold) they only tell you the SOC like H616, and that's it ! after you buy the board *undocumented ethernet and wifi chips* after you made a best effort attempt to find drivers *unsupported* spaghetti codes, that patches *undeclared hexidecimal commands that access *unknown* chip registers* for *unknown purpose* and *unknown functionality* with *unknown binary blobs* of *unknown versions* for *unknown hardware matches* it is a lottery if anything works at all

it is known that some boards may have defective ethernet PHY chips or possibly shorts on the PCB (e.g. pcb defects during soldering) say where the ethernet PHY are located. it is 'useless' to try to fix it in software if indeed it is a *hardware problem*, i.e. that the ethernet phy simply *won't work*. no amount of codes or fixes will fix that, one may need to 'throw the board away' and get a new one or get a different board with a different chip. https://github.com/MichaIng/DietPi/issues/6594#issuecomment-1827683215 ^ for the record in this test with the defective ethernet PHY chip. tested in 3 different distributions from 3 different sources did not fix the problem, each distribution is gigabytes of binaries in 3 different sd cards. after none stop round the clock days of different sets of tests and fixes, including like using 100 Mbps instead of 1 Gbps none of that fix the problem (of the defective ethernet PHY chip, to get the point across.