ag123

hi I've been using the flag compile.sh PREFER_DOCKER=no while building in a systemd-nspawn container: Building Armbian using Ubuntu (jammy) in a systemd-nspawn container This time I managed to make a complete successful build with my work arounds for loop devices in systemd nspawn. However, the flag PREFER_DOCKER=no Didn't seem to be documented in the build options https://docs.armbian.com/Developer-Guide_Build-Options/ can the documentation be updated to add PREFER_DOCKER=no flag (at least under 'advanced users') ? note that it isn't possible to run docker normally within systemd-nspawn or that it'd require all those workarounds such as patching and using the host docker server which defeats the purpose of using docker. rather systemd-nspawn is the container to at least decouple the build environment from the host os environment (which can be a different linux distribution, I'm doing so from OpenSuse https://www.opensuse.org/), with the unfortunate caveat that loop devices still requires a workaround.

I don't have this board, but hoping to help, I did a bit of googling and stumbled into the following: https://www.google.com/search?q=orange+pi+5b+ap6275+site:forum.armbian.com ^ from this : etc --- others http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5B.html https://www.cnx-software.com/2022/11/11/orange-pi-5-most-affordable-rockchip-rk3588s-sbc/ http://www.orangepi.org/orangepiwiki/index.php?title=How_to_use_AP6275P_PCIe_network_card&mobileaction=toggle_view_desktop https://datasheet.lcsc.com/lcsc/2203281730_AMPAK-Tech-AP6275P_C2984107.pdf hope it could provide some leads to a solution

some additional off-topic blurbs about NPU etc. https://www.intc.com/news-events/press-releases/detail/1663/intel-accelerates-ai-everywhere-with-launch-of-powerful https://arstechnica.com/gadgets/2023/12/amds-new-ryzen-8040-laptop-chips-look-a-lot-like-the-ryzen-7040-cpus/ https://www.amd.com/en/technologies/xdna.html https://coral.ai/ https://developers.googleblog.com/2022/05/coral-googles-platform-for-edge-ai.html https://www.nvidia.com/en-sg/ai-data-science/ https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78 https://wiki.t-firefly.com/en/ROC-RK3588S-PC/usage_npu.html https://semiconductor.samsung.com/news-events/news/samsung-electronics-to-strengthen-its-neural-processing-capabilities-for-future-ai-applications/ https://www.qualcomm.com/news/onq/2023/10/introducing-our-next-gen-intelligent-pc-platforms-the-snapdragon-x-series https://www.nxp.com/company/blog/introducing-the-nxp-eiq-neutron-neural-processing-unit-npu:BL-INTRODUCING-THE-NXP-EIQ-NPU https://blog.st.com/stm32n6/ erh, it is getting pretty crowded? and that one can likely be assured none of the offerings are the same in anyway. if one has a board and wanted to try those NPU stuff, one is most welcomed to go ahead and try and perhaps tell the world what you achieved. there would be many keen audiences who would like to look at what you did and at least 'wow' about it. And by the way all that 'neural' stuff can mostly run on the *CPU*, and that there are plenty of accelerators for that AVX2, AVX512, SSE2, NEON, SIMD, GPGPU etc and that *GPUs* (Nvidia) has been around and has been the *industrial workhorse* for 'AI' stuff. there is also some thoughts about the NPU cacophony as above, while one start developing say on an NPU, no sooner than one gets started, another 10 competitors released another 20 NPUs and AI accelerators for your to try, and even then while you gets started, your SOC company release a new chip and a *brand new* NPU, obseleting your 'old' NPU while you are just about to 'get started' with you NPU stuff.

here is some 2 cents comments, if you are meaning NPUs like these: https://github.com/rockchip-linux/rknpu2 - hardware interfaces are kept as trade secrets and not published anywhere 1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source) and there is no hardware documentation any where about the technical details, registers etc. if that at least those are published, one could possibly start coding something to test things on the NPU. then that for things like ethos-n78 https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78 you can find some info here https://developer.arm.com/Processors/Ethos-N78 but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them. - IO / cpu scheduling cpu frequency scaling / governors are well documented https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt https://docs.kernel.org/scheduler/schedutil.html https://www.kernel.org/doc/html/latest/scheduler/ and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain. but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer. and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well. Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate. and if one wants to do some manual scheduling there is the plain old "nice" command https://www.scaler.com/topics/linux-nice/ ---- well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues. The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them. You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions. This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling). And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.

thanks @Werner, then I'd guess it'd be good to leave 'legacy' as 'legacy' (e.g. don't replace with 6.1) my guess is it'd be ok (for most) if 'current' is simply 6.6, and all the stability fixes goes into 6.6, there is no need to insist on a 6.1 etc, but i'd guess it may be good/adequate if it (6.1) is kept somewhere e.g. say in git so that that particular version can be checked out for posterity in case that when moving to 6.6, 'something gets left behind'.

actually that in mainline, there are various dts changes e.g. zero 2w that are in versions > 6.6 e.g. 6.7, as 6.6 is LTS, I'm wondering how would those be merged into lts as well. would mainline backport those 6.7 etc patches say for zero 3, zero 2w into 6.6 lts? and that after all based on this announcement 'current' would after all be 6.6 LTS? and i'd suppose 6.1 would be 'legacy' ? lol as i got a little curious about this, i start looking at kernel git logs if we consider linux-sunxi as 'upstream' 6.6 https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-6.6 then that of course 'for-next' is 'edge' https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/for-next then that 'mainline' 6.6 (tag) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v6.6&qt=grep&q=h618 and that in 'mainline' 'master' (branch) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=h618 as i searched specifically for H618 as keyword, chances are that I missed out other related changes. But that the dts changes are found in the 'h618' keyword searches. it'd seem that Armbian 'edge' (e.g. 6.7) would be in line with around 6.7 where Zero 2W is added to the dts. but that 6.6 would only have Zero 3 dts. either way, I think we made some further changes here? or rather that for 'current' it would be 'frozen' at 6.6 and things on top of that added as patches ? e.g. possibly the dts changes? a curious situation is such that we are here currently possibly further 'upstream' of linux-sunxi lol

I've successfully made a workaround to build Armbian using Ubuntu (jammy) in a systemd-nspawn container. However, this approach require changing the armbian build scripts in addition to the prior to running compile.sh PREFER_DOCKER=no As the codes is quite verbose it is updated in the gist loop devices in systemd-nspawn (workaround) requires editing the armbian-build scripts this patch makes it possible to run compile.sh to completion successfully and produce the images. The patches work around the 'missing' loop device files by creating them in /dev. However, note that it does so by patching loop devices from outside the container, hence it isn't risk free to the host operating system. (use at your own risk) Running this with compile.sh requires root access in the container, as losetup connects the image files to the loop devices to build the images.

hi all a little 'off topic', but as we are doing quite a lot of works on device tree overlays, I did some googling and here are some random stumbles: Is it possible to get the information for a device tree using /sys of a running kernel? https://unix.stackexchange.com/questions/265890/is-it-possible-to-get-the-information-for-a-device-tree-using-sys-of-a-running /proc/device-tree or /sys/firmware/devicetree/base /proc/device-tree is a symlink to /sys/firmware/devicetree/base and the kernel documentation says userland should stick to /proc/device-tree: Userspace must not use the /sys/firmware/devicetree/base path directly, but instead should follow /proc/device-tree symlink. It is possible that the absolute path will change in the future, but the symlink is the stable ABI. You can then access dts properties from files: hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency The output format for integers is binary, so hexdump is needed. dtc -I fs Get a full device tree from the filesystem: sudo apt-get install device-tree-compiler dtc -I fs -O dts /sys/firmware/devicetree/base outputs the dts to stdout. See also: How to list the kernel Device Tree | Unix & Linux Stack Exchange https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/latest/exports/docs/linux/How_to_Guides/FAQ/How_to_Check_Device_Tree_Info.html https://elinux.org/Device_Tree_Reference several trials: armbian@orangepizero3:~$ ls /proc/device-tree '#address-cells' display-engine opp-table-cpu serial-number vcc33-wifi aliases interrupt-parent osc24M-clk '#size-cells' vcc5v chosen leds pmu soc vcc-wifi-io compatible memory psci __symbols__ wifi-pwrseq connector model regulator-usb1-vbus thermal-zones cpus name reserved-memory timer armbian@orangepizero3:~$ ls /proc/device-tree/soc '#address-cells' i2c@5002400 pinctrl@7022000 syscon@3000000 addr-mgt i2c@5002800 ranges tcon-top@6510000 bus@1000000 i2c@5002c00 rsb@7083000 thermal-sensor@5070400 clock@3001000 i2c@5003000 rtc@7000000 usb@5100000 clock@7010000 i2c@7081400 serial@5000000 usb@5101000 compatible interrupt-controller@3021000 serial@5000400 usb@5101400 dump_reg@20000 ir@7040000 serial@5000800 usb@5200000 efuse@3006000 lcd-controller@6515000 serial@5000c00 usb@5200400 ethernet@5020000 mmc@4020000 serial@5001000 usb@5310000 ethernet@5030000 mmc@4021000 serial@5001400 usb@5310400 gpu@1800000 mmc@4022000 '#size-cells' usb@5311000 hdmi@6000000 name spi@5010000 usb@5311400 hdmi-phy@6010000 phy@5100400 spi@5011000 video-codec@1c0e000 i2c@5002000 pinctrl@300b000 sunxi-info watchdog@30090a0 armbian@orangepizero3A:~$ ls /proc/device-tree/soc/spi@5011000/ '#address-cells' clocks interrupts phandle pinctrl-names resets status clock-names compatible name pinctrl-0 reg '#size-cells' armbian@orangepizero3:~$ cat /proc/device-tree/soc/spi@501 double tab spi@5010000/ spi@5011000/ armbian@orangepizero3:~$ cat /proc/device-tree/soc/spi@5010000/status okay armbian@orangepizero3:~$ cat /proc/device-tree/soc/spi@5011000/status disabled well it seemed /proc/device-tree is a good place to check device tree configurations at run time. hope that could help with 'debugging' device tree overlays. of course, the other place is probably in dmesg as well as during boot but that'd need a usb-uart (serial) connection (at least)

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.