ag123

if you browse the thread above, this is still in *testing* *alpha* stage, *use at your own risk* , *unsupported* and review the prior comments and you may find the images from pixdrift. if you do *test* them feedback on your findings here, and provide details about your board, ram size, image used etc. There is one thing about these chips/boards e.g. H618, I *cannot find* the reference manual / user manual for H618, after searching in several search engines google, bing, yahoo (altavista), you.com, and all the developers simply *assume* that it is the same as / similar to H616. Hence, it is practically *reverse engineered*. This may practically mean that *use at your own risk* probably would always apply even if this become 'community' supported, i.e. it is some wild near blind attempts to make it work, and it is an accident that various things works by virtue of pure *wild tries*. the chip manufacturer has thus far not provided *public* reference doc nor support any of these and the codes are *wild tries* and they just happened to work with our collective guesses.

@Gunjan Gupta agreed about that opinion, in general it is *risky* to configure device tree in a running kernel as it can lead to (all sorts of) unexpected problems with all the kernel threads running on all multiprocessing cores. I think there may be some serious synchronization issues, e.g. would the kernel running simultaneously on all cores 'know' about the changes? And I'd guess it could lead to *kernel panic* when the device tree is updated at runtime as another kernel thread running on another core could be accessing the in memory kernel device tree when it is changed form another. but that as the idea is still attractive / 'seductive' , I'd guess those interested can try out this repository https://github.com/ikwzm/dtbocfg my guess is that *certain* ops is 'possibly safe' e.g. to tweak the status of a particular device say gpio from 'disabled' to 'okay', but the thought about synchronization still applies, simply changing the device tree at runtime can lead to *kernel panic* and even possible data corruption for that 'simple' change. The safe way is probably to only load the overlay from uboot. https://docs.armbian.com/User-Guide_Allwinner_overlays/ oh configFS is actually mentioned in this slide https://elinux.org/images/1/19/Dynamic-dt-keynote-v3.pdf hence, those keen on that may want to try out that at your own risk. if you review the slides, it seemed there are functions within the kernel to support such 'configFS' changes. but that it is likely 'experimental', i.e. it isn't 'proven beyond doubt' it is risk free, but the slides documents some mechanisms for synchronization etc, which is necessary to update the in memory device tree at run time. these days gpio / i2c / spi etc is just a pin mux away, a single register change muxes it differently. 'big' computers and/or notebooks/laptops etc are deemed to be 'fixed', but for SBC practically all the pins on the headers can be 'hot swapped' with a cape/hat etc. note that the implementation as is relevant to the slides seemed to be this specific fork, different implementations would likely have different behaviour/bugs: https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/configfs-overlays.txt https://lore.kernel.org/lkml/1414528565-10907-4-git-send-email-pantelis.antoniou@konsulko.com/ the slides specifically mentioned using a mutex to lock the whole tree when changes are taking place (changesets) that is a minimum necessary. But I think that won't prevent possible deadlock situations, because device tree is heavily accessed when devices are referenced, some of the (old) references may be stored away in apps say in variables, which could mean the change could at least crash the app and the kernel is running concurrently *in parallel* on all cores so kernel panics , or simply *hang* would likely be still a thing, but that at least find a 'safer' implementation, one would need to review the codes and do so accordingly.

accordingly device tree overlay may have to be loaded by uboot https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ https://docs.kernel.org/devicetree/overlay-notes.html I'm not sure how uboot is setup if it loads a single fixed dtb or that it loads the dtb for the board followed by a device tree overlay (e.g. dtbo ?) following a naming convention for boards. Note that there is an Armbian document for device tree overlays https://docs.armbian.com/User-Guide_Allwinner_overlays/ But I'd guess most users wanted it 'dynamically' e.g. to load it at runtime from a linux shell, hence I did further googling: it turns out there is something called configfs which is intended for this purpose https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/guides/dt-overlays.md.html > mount -t configfs none /sys/kernel/config > mkdir -p /sys/kernel/config/device-tree/overlays/tsys01 > cd <bin directory under DT-Overlays> > cat tsys01.dtbo > /sys/kernel/config/device-tree/overlays/tsys01/dtbo I'm not sure about that tsys01 folder how it relates here https://github.com/ikwzm/dtbocfg note that apparently there seem to be a few different implementations of configfs dtbocfg is one of them and only that the above quote applies I'm not too sure if configfs is a feature of specific forks, e.g. here is another https://elinux.org/R-Car/DT-Overlays there is a documentation for this and it seemed for this particular fork https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/Documentation/devicetree/configfs-overlays.txt?h=topic/overlays if you look at mainline, apparently configfs is not mentioned https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree off-topic: some other unrelated fun stuff here https://github.com/ikwzm/udmabuf ^ I think this is driver for a particular SOC and *not* likely to be universal https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html don't think DMA controllers are 'standard' across socs.

- dup -

- 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.