pixdrift

This is testing I have done on PR6106 builds @Gunjan Gupta, it's great to see Zero2 HDMI working, well done.. I was optimistic with CPU Frequency on Zero 3 but it's still not working for some reason, will take a closer look when you post an updated PR. Board / Variant HDMI Console WiFi CPU Frequency Orange Pi Zero 2 / 1GB Yes Yes Yes Orange Pi Zero 3 / 4GB Yes Yes No

Hi @Stephen Graf, This is the best method but take note that the branch in the repository that is being merged may change depending on the PR, which would require changing the branch in your locally cloned copy before running ./compile to test it. It appears @Gunjan Gupta has closed the 6106 PR because of issues, but when the repo is updated, you can pull again from it to get the updates and then rebuild. Depending on your hardware setup and build caches, it's a pretty quick process. Please note: That Orange Pi Zero 3 has been added as 'WIP' so it won't be available in the default device menu in compile.sh, you need to select 'Show CSC/WIP/EOS/TVB' from the device menu (after choosing kernel options). The menu will turn red and you need to select 'I understand and agree' and then orangepizero3 will be available in the menu to build.

I have Orange Pi Zero 3 builds for @Gunjan Gupta's PR6106 built here for testing (prefixed with the PR number). If you have a Zero3, please check that these images are working, specifically HDMI, as this is a big first step to getting the Orange Pi Zero 3 into Armbian. https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/ @Gunjan Gupta you're expecting Zero2 HDMI will also work with these changes? If so, I can build some zero2 images for testing also. Edit: I also just added a Zero 2 image here for testing if anyone has a Zero 2. https://armdev.pixeldrift.net/orangepi/zero2/pr_testing/

Hi everyone, Apologies, have been away for Christmas.. and still not completely back on deck. My Zero2W with expansion and expansion boards for Zero2 and Zero3 arrived during the break so I will also have those to test. Welcome to the new people in the forum! @johndo100 and @Mako, can you let us know which boards and which variants you have (ie. memory configuration) and if you have IO boards? would be great to get some more testers with hardware contributing feedback here Regarding testing for @Gunjan Gupta I am happy to create builds of his pull request efforts into mainline Armbian to make it easier for others to test, all I ask is that when people are posting feedback for different images they provide a link to the image they have downloaded/flashed so we can keep track of which feedback relates to which build. I will also include the PR (pull request) and commit ID in the builds I do. I will try and get a build / image of the 6106 PR that @Gunjan Gupta is requesting testing for.. out today. I am interested in what people prefer to test as there is a large number of combinations. I will build Bookworm and Bookworm + XFCE initially, and happy to take feedback if people have trouble with Debian.

Great information, thanks again @iun cuim! I have had a quick look through the full patch set in the github repositories and it's not too dissimilar to the patches we've already got working (CPU Frequency appears to be an omission, but I may not have found it yet ). I will go through what else is there for comparisons sake, and now I have a link to the images I will take a look at those too, cheers! Also, thanks for your kernel contributions to sunxi.

I just warned against wasting time on work that has already been done. Having a reference that already works and has been tested is also useful. Hi @iun cuim and welcome to the forum! Thanks for taking the time to create an account here and link to the development branches from warpme. I'm not too familiar with minimyth (and only new here) so hadn't come across this effort myself. I think it's great to see so many people showing enthusiasm for these boards, and it's always good to have more information so we aren't doubling up on work as you mention This is very much a learning journey for me, but having a working reference for many of the same upstream patches will be a great help! Do you know if there is similar forum discussion around the development for the attached github repository? and do you know if anyone is building full Orange Pi images using this modified/patched kernel? It would be great to compare capabilities of different images when we identify issues in development builds. Thanks again! -edit- correct reference to repo

@Gunjan Gupta the changes for zero3 CPU Frequency are all bundled into this commit https://github.com/pixdrift/armbian_build/commit/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0 It's on my branch zero3_cpufreq https://github.com/pixdrift/armbian_build/tree/zero3_cpufreq Changes of interest are are https://github.com/pixdrift/armbian_build/blob/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2-dtsi.patch#L98-L141 Thanks for the offer to take a look

Hi @fizban thanks for this information and taking the time to post! Some of your feedback is a bit high level for current development (userspace applications such as Firefox/VLC are above where we are working at the moment) but it's all good information we can refer to in future. When referring to the images you are testing, could I ask you to provide the link you used to download the image? that will make it easier to marry up to a commit. Speaking of which, I will try and improve my method of naming the downloads so they have a commit or another consistent feature because even I am losing track at times as there are several fronts of development The HDMI information is interesting. I did have display issues with output on one of my monitors, but another monitor I had handy was able to handle the signal ok, so HDMI may still have some quirks on this board. I didn't think to disconnect/reconnect the monitor after the initial detection, this may help with some of the Zero2 troubleshooting. Great that you were able to validate expansion USB port, WiFi and Bluetooth.. they have been the key things we've been working through. One thing I don't currently have any feedback on is audio, did any of your tests confirm audio out works on the expansion board or HDMI? I haven't really devised a simple test for this yet. Thanks again!

Great find, an Orange Pi with a H618 would be a great addition to their lineup :).. I will keep an eye on AliExpress to make sure we have one to test as soon as it's released!

That not needed. Are your changes in your git branch? May be I can take a look I will get the CPU Frequency changes up into a branch in my repo tonight, realise that would have made troubleshooting a fair bit easier.. it was getting late here.. thanks for taking a look, and I will post when I get a minute

Sorry @Stephen Graf I didn't miss your message. Good news about the cellphone pairing.. not so good news about the gpio messages in dmesg. I don't recall seeing that on the zero2 but I could have a closer look. No doubt something with the gpio configuration that needs investigation. I am currently trying to get CPU Frequency scaling fixed on the zero3, but I will add these error messages (and checking if zero2 is the same) to my list. @Gunjan Gupta regarding the CPU Frequency scaling on the zero3.. I modified the arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling patch as discussed to add the sun50i-h616-cpu-opp.dtsi include to the shared zero dtsi, that all worked well. The &cpu configuration had to be in the separate zero2 and zero3 .dts files because the regulator for vdd-cpu differs for each (zero2 is dcdca, zero3 is dcdc2). All that worked fine and compiled fine, but still not getting any results from the cpufreq-info command. Upon closer inspection of the patch, I suspect I may need to add references for the h618 SoC to this patch: https://github.com/pixdrift/armbian_build/blob/c519c355d83f2588c1b0442420f6cdf184b4bc40/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2.patch#L127-L130 and several other references in the file will need the h618 configuration added to the check. Would you be able to run your eye over this and see if this looks like I am on the right track? If so I will try to put together a patch to resolve it (if a working version doesn't exist elsewhere).

Hi @Ivan Sy thanks for your interest in our Zero3 work and welcome to the forum! I won't speculate on timelines for official support, but a PR with everything necessary (that @Werner alludes to) shouldn't be far off and we have most of the pieces working to different degrees which is what you will see in some of the testing and discussion in this thread. The biggest challenge with merging to mainline is really getting the HDMI patch working for the zero2 as the zero2 and zero3 share a lot of similarities in their SoC. @Gunjan Gupta has done some incredible work to wrangle patches for the Zero2 to get everything working, and that is why you will see some Zero2 discussion here which may seem out of place. Unfortunately the most recent Zero2 test for HDMI still has some challenges, and I have given as much feedback as possible to @Gunjan Gupta but unfortunately @Gunjan Gupta doesn't have a physical Zero2 to test on (yet). Once this patch is merged into the mainline Armbian, I think there will be some effort to move the remaining pieces that are common for both Zero2/Zero3 into a consolidated .dtsi file so both boards can benefit, then it will only take a small amount of effort to add Zero3 configuration (because it's almost identical). The Zero3 fork I am maintaining, and posting here doesn't take into consideration anything other than the Edge branch and making the Zero3 work, where @Gunjan Gupta has put incredible effort into the Zero2 specifically and I have been porting/testing those changes on Zero3 as we go. I think the Zero3 is a great board and I am confident that if we maintain momentum with the people who are contributing feedback and assistance from the community here, combined with the amazing patching work form upstream.. we will be able to put together a PR of the quality the project will approve of Also, if you do buy a Zero2 or Zero3 board, please hang around and help us test and to anyone else browsing this thread that has a Zero2/Zero3 board, create an account and say hi

Sorry @Gunjan Gupta not having much luck with these images unfortunately. I did a quick test of both kernel versions on a Zero2, and neither had HDMI output, although interestingly after the kernel boots it appears to send an HDMI signal (monitor detects it) but doesn't have any output. I tested both kernel versions using Bookworm as the OS. I noticed in your branch, you haven't enabled console output 'both' or marked display as 'yes', so I rebuilt after updating the configuration and unfortunately I still didn't get anything displaying on HDMI out. https://github.com/viraniac/armbian_build/blob/h616-hdmi/config/boards/orangepizero2.conf#L7-L8 I did test CPU Freq though and that appears to be working correctly. Here is some debugging output from the 6.1 Bookworm build. root@orangepizero2:~# uname -a Linux orangepizero2 6.1.69-current-sunxi64 #1 SMP Wed Dec 20 16:00:29 UTC 2023 aarch64 GNU/Linux root@orangepizero2:~# 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 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 1: 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 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 2: 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 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 3: 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 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) root@orangepizero2:~# lsmod Module Size Used by algif_hash 16384 1 algif_skcipher 16384 1 af_alg 24576 6 algif_hash,algif_skcipher bnep 28672 2 hci_uart 135168 1 btqca 24576 1 hci_uart btrtl 28672 1 hci_uart btbcm 20480 1 hci_uart btintel 40960 1 hci_uart bluetooth 724992 29 btrtl,btqca,btintel,hci_uart,btbcm,bnep ecdh_generic 16384 2 bluetooth ecc 32768 1 ecdh_generic sprdwl_ng 352256 0 sunxi_addr 20480 1 sprdwl_ng cfg80211 376832 1 sprdwl_ng sunrpc 290816 1 snd_soc_hdmi_codec 24576 0 lz4hc 16384 0 lz4 16384 0 polyval_ce 16384 0 sunxi_cedrus 45056 0 polyval_generic 16384 1 polyval_ce v4l2_mem2mem 36864 1 sunxi_cedrus videobuf2_dma_contig 24576 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig dw_hdmi_cec 16384 0 dw_hdmi_i2s_audio 16384 0 videobuf2_v4l2 24576 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 49152 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops videodev 204800 4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem panfrost 69632 0 mc 53248 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem gpu_sched 28672 1 panfrost dump_reg 24576 0 apple_mfi_fastcharge 20480 0 drm_shmem_helper 20480 1 panfrost display_connector 20480 0 cpufreq_dt 20480 0 zram 28672 3 binfmt_misc 24576 1 sprdbt_tty 36864 2 uwe5622_bsp_sdio 208896 2 sprdbt_tty,sprdwl_ng rfkill 36864 7 sprdbt_tty,bluetooth,cfg80211 fuse 126976 1 dm_mod 131072 0 hid_apple 28672 0 realtek 32768 1 dwmac_sun8i 28672 0 mdio_mux 16384 1 dwmac_sun8i root@orangepizero2:~# dmesg | grep -i hdmi [ 1.444604] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.445267] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.445657] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008ea4d48) [ 96.336072] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 96.336102] sun8i-dw-hdmi 6000000.hdmi: read_hpd result: 1 [ 103.529860] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 189.979691] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin It seems very close, just not displaying anything. I will do some more testing and let you know if I get something to work. If anyone else has a Zero2 and wants to validate my testing, I have posted the images built from @Gunjan Gupta's HDMI testing branch here https://armdev.pixeldrift.net/orangepi/zero2/viraniac/

Another day another update I merged in the Bluetooth fixes from @Gunjan Gupta's pull request to Armbian main branch into my zero3 fork, this includes moving to the extension pattern for the wifi driver. I did a quick build and tested Bluetooth (pairing to a BT speaker) and the pairing worked, but I didn't test past this. If you have some tests you can do with Bluetooth, I would appreciate the feedback (USE AT YOUR OWN RISK etc.) https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.bt.fixed.tar.xz I have looked at the CPU Frequency patch @Gunjan Gupta mentioned and I will look at modifying this patch to write to the shared .dtsi as suggested so both zero2 and zero3 benefit, I think that is a great suggestion.. this update doesn't include any CPU Frequency fixes yet unfortunately. Thanks to everyone here that is providing feedback from their testing! The github repo isn't updated with the BT fixes yet, I will try and get to this tonight so everyone can build updated images. -edit- GitHub fork for zero3 is now up to date with BT fixes https://github.com/pixdrift/armbian_build/tree/zero3

The 'most complete' testing build at time of writing is this version, USE AT YOUR OWN RISK! https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.tar.xz There are elements that we know aren't working (Bluetooth, CPU Frequency scaling) and items that are currently untested (audio output via HDMI and the expansion board). I understand you are looking for a working image, but the Zero3 Armbian image is still in early development and depends heavily on people testing and providing feedback with identified issues. If you do run this image, please provide feedback on specific items you have tested and let us know. It is too early in the development at this stage to provide any advice or assistance for third party user space programs/applications that may produce errors or not work.

This is a really nice PR @Gunjan Gupta, the move to using an extension is so much cleaner and it's a great consolidation and clean up... very impressed by your work! and learning a lot about Armbian along the way Looking at this code it should work for the zero3 as well, so thanks as always for posting and I will work on merging this into the zero3 fork so it can stay as consistent as possible. Is anyone able to provide (or devise) a simple test for Bluetooth on these boards? I am heavily in the server space, so don't play much with BT on Linux I was thinking of building out a test script so that people who download the image can run the tests and confirm results so we can get a consolidated summary of feedback from people who are assisting with testing and perhaps feed this into a CI process for validation later down the road.

Thanks for the feedback. This is interesting, looking at the kernel config for the build, the following is configured, and I assumed this is correct for this board. If anyone has any feedback/advice on this it would be appreciated.. happy to update the image if we can find a fix. I will do some reading myself │ Symbol: ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM [=y] │ │ Type : tristate │ │ Defined at drivers/cpufreq/Kconfig.arm:32 │ │ Prompt: Allwinner nvmem based SUN50I CPUFreq driver │ │ Depends on: CPU_FREQ [=y] && (ARM || ARM64 [=y]) && ARCH_SUNXI [=y] && NVMEM_SUNXI_SID [=y] │ │ Location: │ │ -> CPU Power Management │ │ -> CPU Frequency scaling │ │ -> CPU Frequency scaling (CPU_FREQ [=y]) │ │ (3) -> Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM [=y]) │ │ Selects: PM_OPP [=y] -edit- Your output appears to be an improvement over the current state of the Zero2 (my recent build from Armbian main branch at least). When I run the cpufreq-info command, the Zero2 appears to lock up and never recover ___ ____ _ _____ ____ / _ \| _ \(_) |__ /___ _ __ ___|___ \ | | | | |_) | | / // _ \ '__/ _ \ __) | | |_| | __/| | / /| __/ | | (_) / __/ \___/|_| |_| /____\___|_| \___/_____| Welcome to Armbian-unofficial 24.2.0-trunk Bookworm with bleeding edge Linux 6.6.6-edge-sunxi64 No end-user support: built from trunk System load: 26% Up time: 0 min Memory usage: 12% of 919M IP: XXX.XXX.XXX.XXX CPU temp: 41°C Usage of /: 4% of 58G RX today: 146.6 MiB Last login: Fri Dec 15 18:29:24 AEDT 2023 on ttyS0 root@orangepizero2:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0:

I started going through this patch and updated the failed hunks, and managed to resolve all of them except the failures in sun8i_ui_layer.c as it appears to have changed significantly. Not sure how to approach that. I can share my diff to the patch if you're interested (to save some work), but unfortunately I think sun8i_ui_layer.c fixes will need significant work (with understanding of the code base / patches) to resolve... which is beyond me currently.

Hi @0ka, I have seen this behaviour in SSH when UseDNS is set to yes, and there are DNS issues. The behaviour is essentially a hang during initial login as it attempts to reverse DNS the client's IP. This will then work for a period (because the response is cached) and then be slow again after the local DNS cache expires. A test would be to set UseDNS to no in the sshd_config, restart SSH and see if the issue still exists? If changing UseDNS resolves it, I would double check DNS configuration and network connectivity to the DNS servers it has configured. Sorry, can't comment on why this may have changed between images.

Unfortunately these images aren't from Armbian, or related to this thread so I think your best option for support is to raise this request on the site that you downloaded these images from. Yes this board is new, and as a result it's not fully supported so not all components are currently working.

Thanks. I did see these patches were patching the same file and likely causing the conflict, I wasn't aware that megous directory refereed to a different kernel tree, I will go read up on that, thanks for the information. The hdmi patch only has a couple of hunks that fail, I will try and find some time to take a closer look too... I didn't want to start unpicking the patching failure if I was missing something obvious Ahh, this is good to know, thanks again for the information

I have updated the Zero 3 image with a few minor updates 1. The build now uses the u-boot upstream repository tag v2024.01-rc5 instead of the specific commit for the merge of the zero3 defconfig 2. The default configuration now includes the bluetooth tools installation to match zero2 in mainline armbian repository (if someone could test bluetooth and provide feedback it would be appreciated) 3. Kernel bumped from 6.6.4 to 6.6.7 and all patches apply cleanly and build works as expected (and CLI bookworm version has been tested). I have built some new images (bookworm cli and xfce) with this configuration using 6.6.7 here that you are welcome to use at your own risk https://armdev.pixeldrift.net/orangepi/zero3/ Source repo with the changes is here, use zero3 branch for latest stable of these changes.. I will try and make sure that this branch remains deployable https://github.com/pixdrift/armbian_build/tree/zero3 I think the next step is really to look at getting Zero 3 into the mainline Armbian repository, even if it's in a reduced state of configuration due to patch issues.. this would at least set the ground work for when the components included in these builds mature. @Gunjan Gupta as you have been through this before for other boards, I was hoping to get some of your time to assist (I will see how far I get first ) Speaking of which, @Gunjan Gupta I had a quick look at adding HDMI for the Zero 2 (to the main Armbian repo, not your fork) based off a conversation you had in another thread, but unfortunately I am having issues with the HDMI patch when adding it to the main branch in the armbian repo (fails to build/patch). Have you had any success building with this patch on the current main Armbian branch? I was going to have a closer look at it tonight, but thought I'd ask if you had already looked at it. Failing patch is the main HDMI driver patch: drivers-wip-H616-hdmi-video-output

I have updated zero3 branch in my fork so it's up to date and you should be able to build Zero 3 images from it for testing: https://github.com/pixdrift/armbian_build/tree/0f9820ff2238ab15fdbfef9adfefca47b031a757

My apologies @Gunjan Gupta I have only been living in 'edge' so didn't even think to check that. Thanks again for this work

I moved my Armbian build setup to an M2.. and it's much quicker to iterate now! It only needed to be included in the dtsi. I think I will also attempt to move the HDMI and USB configuration back up into the sun50i-h616-orangepi-zero.dtsi file (only) as this is then common to both zero2 and zero3 and will remove the double handling and add zero2 HDMI support for free. Everything now working together, I have built the following image if people want to test (THAT HAS NO WARRANTY WHATSOEVER!, USE AT YOUR OWN RISK). Please provide any feedback here (even if it's "works for me", and please include any details on your device etc.) https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.4.everything.tar.xz What _should_ be working: - HDMI video output - Gigabit wired networking - WiFi (with the known load issue with the driver) - USB ports on the expansion board What may not be working (need ways to test/validate this): GPIO IR Receier Anything to do with sound.. haven't looked at this yet I will update the GitHub fork I have for the zero3 with the latest wifi patch and post a link soon (want to clean it up a little) Thanks to @Stephen Graf and @wast3d55 for their assistance in testing different parts of the image, and for their detailed feedback. Thanks to everyone else in this thread that has helped me get to this stage, it's been quite the learning experience.. and appreciate all the assistance I have received so far