pixdrift

It seems I have confused legacy.. when I built 'current' it's 6.6.12, not sure if 6.1 is still used? as 'legacy' build for zero2 was 4.9.318 I will need to take another look at how patches are done for legacy, or if we just don't support it.

Thanks @Stephen Graf, my branch has been updated with mainline and I have added the patches for both 'legacy' (6.1) and 'current' (6.6) kernels, although I haven't yet created test builds. I will create builds and test zero2, if you can cover off zero3? https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix In unrelated updates, I also received some mail so I now have the HDMI audio splitter for potentially testing the HDMI audio patch (but the size of the patch is a little daunting), and the Sipeed Longan (not related to this thread other than it's also H618) looks like a great board!

Hi sander, welcome to the forum! Thanks for introducing yourself, always good to know there are others around willing to assist with testing I'd say you're in the right place as I think Zero2W is where (at least my) focus will shift to next, just a bit early as we don't have anything to test. As has been discussed in the thread, @Gunjan Gupta did some preliminary work in his own repo to get the Zero2W working, but I haven't had time to go through it and prepare a more formal patch for Armbian. https://github.com/viraniac/armbian_build/tree/zero2w This repo is provided with no support, as it's in heavy development, but if you wanted something to work with, this may help.

Agreed to leave the LEDs as they are for now. As for the PR, given that Zero2 is a supported board, we should probably also add this change to the other kernels the Zero2 supports (and test), ie. legacy and current. https://github.com/armbian/build/blob/e73c0b6514db5c55d896e62112f578214e7f30cb/config/boards/orangepizero2.conf#L7 We can use the merge request I have and stage it as a PR, or you're more than welcome to create your own (even off mine if you like), let me know how you want to proceed.

Possibly, but the USB end isn't touching anything, and it's consistent/reliable (ie. it impacts every boot). I assume it's something to do with the design of the converter. Anyway, it's a known quantity now so I can rule out those issues. From my perspective, everything is testing successfully on the Zero2 so wondering if we should discuss merging or is there more you want to focus on? I was thinking as I was working with the Zero2 that it might be nice to have an LED enable/disable (or function change) in the hardware menu? Not sure if others would find that useful.

Well.. after some extended testing.. I finally got to the bottom of the issue. It wasn't related to the SD cards at all after all, and it also wasn't related to the heat (managed to push it to 84c+ and then reboot), it is my serial USB converter. So I have discovered that if my serial/USB converter is plugged in to the Zero2 serial pins, but not connected to a PC, the Orange Zero2 fails to boot, and gets 'stuck'. When I plug the serial converter in when it's in this state (just a red LED) I get a u-boot prompt. From here if I issue 'reset' with the serial converter plugged in to the PC (to issue the command) the board reboots cleanly, no issues. This is the same behaviour for mainline and my SPI fix branch in github, so it looks to be strange behaviour if it can see the USB serial converter on the line and it doesn't appear to have anything to do with the patches (apologies for the confusion). The USB serial converter (I have a few, but this is the most reliable) is a 'CP2102 USB to UART Bridge Controller' Not sure what to make of this information, but hoping others may have some thoughts?

I will try and re-create the issue today, and get a serial log. Hoping the summer heat is on my side.

So after much troubleshooting I could get reliable results on a much slower MicroSD card (I was using fast MicroSD cards). My theory is that the faster cards result in the Zero 2 board becoming CPU bound during initial configuration causing it to overheat, or there is a weird race condition during shutdown. I did manage one reboot with a faster card and the CPU temps looked quite high. What led me to this conclusion was after a re-flash it would still not boot (too hot). So after that troubleshooting exercise, I am now using my slowest MicroSD card, and have ordered a Zero 2 (and Zero 1!) heatsink So here are the results after turning on all the options in the armbian-config menu. ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 264 bytes read in 1 ms (257.8 KiB/s) 32033 bytes read in 6 ms (5.1 MiB/s) Working FDT set to 4fa00000 344 bytes read in 5 ms (66.4 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-i2c3.dtbo 339 bytes read in 5 ms (65.4 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-ir.dtbo 608 bytes read in 6 ms (98.6 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-otg-host.dtbo 699 bytes read in 4 ms (169.9 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-spi1-cs0-spidev.dtbo 644 bytes read in 5 ms (125 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-uart5.dtbo 620 bytes read in 6 ms (100.6 KiB/s) Applying kernel provided DT fixup script (sun50i-orangepizero2-3-fixup.scr) ## Executing script at 45000000 18403342 bytes read in 762 ms (23 MiB/s) 23169032 bytes read in 958 ms (23.1 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41890000 root@orangepizero2:~# sudo i2cdetect -l i2c-0 i2c DesignWare HDMI I2C adapter i2c-1 i2c mv64xxx_i2c adapter I2C adapter root@orangepizero2:~# sudo i2cdetect 2 Error: Could not open file `/dev/i2c-2' or `/dev/i2c/2': No such file or directory root@orangepizero2:~# sudo i2cdetect 1 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-1. I will probe address range 0x08-0x77. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizero2:~# lsusb Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@orangepizero2:~# usb-devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5101000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5200000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5310000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5311000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5101400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 musb-hcd S: Product=MUSB HDRC host driver S: SerialNumber=musb-hdrc.4.auto C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5200400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5310400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=09 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5311400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms root@orangepizero2:~# mode2 -d /dev/lirc0 Using driver devinput on device /dev/lirc0 Trying device: /dev/lirc0 Using device: /dev/lirc0 Keep in mind I have nothing plugged into USB, GPIO, and don' have an IR remote.. but can possibly test these given some more time (if it's critical). From my perspective everything looks good, my only concern was the i2cdetect differences to zero3, not sure if it's to be expected that we have one less than zero3. I have this image running stable now so if any other testing is required, let me know.. looks good to me.

I did some troubleshooting last night, and it appears that the boot issue isn't related to the overlay configuration, but appears to be a bug/issue with the Zero2 image. I can replicate it consistently 1. Flash Zero 2 image and boot 2. Configure root/user through prompts, configure Wifi, locales etc. 3. As soon as I am provided a command prompt issue `systemctl reboot` The board then reboots to only a red LED illuminated.. and doesn't boot again. I have removed power, waited for extended periods of time.. it just doesn't seem to come back. This is all without making any changes in the armbian-config menu. I am going to build a clean mainline image and confirm I can replicate this bug/issue there. In summary, I don't think I have a solid foundation for testing this change on Zero2 at the moment, will try and narrow it down when I have some more time.

@Stephen Graf I have put the patch in the following branch in my github repo: https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix You had a typo in your patch of 'opangepi' which may have been why you had filter issues with your prefix (late night development will do that to you!), but it was a quick fix.. and I updated the patch and then the prefix for zero2 and zero3 to use the correct prefix. I booted the image on zero2, and the armbian-config menu looked correct, I enabled everything in the list and rebooted and for whatever reason it failed to boot (red light, no disk activity). Not sure what is wrong, and if it's a one off or more significant issue, but I will hopefully have time to look at it tomorrow. I expect the above branch to have SPI fixes for Zero2 and Zero3 (using edge kernel) for anyone interested in testing.

Thanks I will try and get a build of this out tonight, can you detail some basic tests to verify this is working correctly?

This is the output from the orangepizero2 with all Hardware overlays turned on, using the latest build from Armbian mainline repo. So the overlays don't look to be in a particularly good state for either zero2 or zero3. # Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 299 bytes read in 1 ms (292 KiB/s) 32033 bytes read in 7 ms (4.4 MiB/s) Working FDT set to 4fa00000 268 bytes read in 6 ms (43 KiB/s) Applying kernel provided DT overlay sun50i-h616-ir.dtbo 512 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun50i-h616-light.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 339 bytes read in 5 ms (65.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-mcp2515.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 6 ms (107.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev0_0.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 6 ms (107.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev1_0.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 6 ms (107.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev1_1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 6 ms (107.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev1_2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 808 bytes read in 6 ms (130.9 KiB/s) Applying kernel provided DT overlay sun50i-h616-spi-spidev.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 616 bytes read in 5 ms (120.1 KiB/s) Applying kernel provided DT overlay sun50i-h616-tft35_spi.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 272 bytes read in 5 ms (52.7 KiB/s) Applying kernel provided DT overlay sun50i-h616-ws2812.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ Error applying DT overlays, restoring original DT 32033 bytes read in 7 ms (4.4 MiB/s) 18403742 bytes read in 763 ms (23 MiB/s) 23169032 bytes read in 960 ms (23 MiB/s)

It's definitely a hefty (large) patch, which makes me nervous when bringing it in.. as I expect (hope) the effort will be deprecated in the near future with the mainlining effort. What's the best way to determine if this is being worked on in mainline and it would be easier to wait for that? The sunxi mailing lists?

I agree with this approach and it was what I was promoting earlier in the thread, an overlay for each board (or maybe combined in the very specific zero2/zero3 use case). The SoC itself should be the same, but there are minor differences in implementation and peripherals that will want to give us the flexibility to add/remove items at a board specific level and not have that show up for other boards as this would potentially confuse end users of armbian-config. This was the reason I went looking for other h616 and h618 boards and found the Sipeed Longan Pi 3H, and there is also the Mango Pi MQ-Quad, and Banana Pi M4 Zero that share h61x SoCs. The bigtreetech looks to be a very different board, with different components/peripherals that will be unique to those boards. I think cloning the current overlay into orangepizero (similar to how the dtsi is done) or orangepizero3, and just work to get the single board correct would be a great next step. In terms of testing on the zero2, I am happy to do that and provide the output, let me know specifically which boot logs you need after enabling components, and I can send it to you in a PM. -edit- A potentially a very basic question, but on the Zero2/3 board diagrams it shows GPIO pins as PC<num>, PI<num>, and PH<num> and I haven't found a clear explanation for these prefixes.. is someone able to decode this for me?

@Gunjan Gupta I was looking at this patch here (which unfortunately combines thermals etc. with HDMI audio) and was referenced earlier in this thread: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.6/files/0630-arm64-dts-allwinner-h616.dtsi-add-ths-audio-hdmi.patch This appears to only modify the dtsi, but you're suggesting the underlying kernel code needs patching in too because it's not ther? (I will admit I haven't had a look yet)

You have given a pretty good summary. The main bits still missing: Main board: - HDMI audio output Expansion board: - Infrared receiver - Analog audio output - Microphone isn't supported on Zero 3 (hardware limitation) There are HDMI audio patches available, and have been linked from here, it just hasn't been a focus. To be honest, I am not sure how to test this as I don't have anything that supports HDMI audio handy, can anyone advise if the following would be a good box for testing? (plug headphones in to verify HDMI audio), if so I will buy one for testing. https://www.aliexpress.us/item/1005005630394541.html Not sure what is required for analog audio to be honest, I will need to check if they actually have that working on the Zero2. The other thing that would be good would be any suggestions/recommendations for a basic test that can be run to confirm both the audio components are working, ie. look for certain devices in device tree, attempt playback/volume control etc. The simpler the test, the easier it will be to be able to get people on board and testing.

Well.. one small line for orangepizero3.wip, one giant leap for Orange Pi Zero 3 The overlay PR fix from @Stephen Graf has been merged into Armbian.. thanks for sticking with it.. awesome to have more people contributing https://github.com/armbian/build/commit/08623d0e37dc02cb728b264f1e64771ddaba8025

Not wanting to side track this thread off the Orange Pi, but I found some info about an upcoming h618 board from Sipeed, the Longan Pi 3H, which is similar to the Orange Pi Zero2W. From the news I have read and the store, it's in early production and appears to have limited availability. https://www.aliexpress.us/item/3256806204597847.html?gatewayAdapt=glo2usa The reason it may be useful in this thread, is the mainlining effort they have undertaken may have some crossover with what we are looking at for the Orange Pi Zero 3, so their repository may be a good point of reference for patches/changes etc: https://github.com/sipeed/LonganPi-3H-SDK -edit- Couldn't help myself, I have ordered one

Absolutely. @Gunjan Gupta has outlined the GitHub process, but it can be a bit obtuse the first time through. That process aside, I was thinking the configuration change (PREFIX) and the overlays you are working on could all go in with a single PR, but if you prefer, we can do just the config update in a PR first. I want to make sure people here have what the need to do the PR with some assistance. To break down the steps @Gunjan Gupta has summarised I have given a quick set of more detailed steps. Sorry if it's simplified too much, I am hoping others reading this thread may benefit from it if they are new to Armbian and github. 1. Create a github account, will use the example 'ArmbianHacker' 2. Browse to the main Armbian project https://github.com/armbian/build 3. At the top right there is a 'Fork' drop down, select this and then select 'Create a new fork', this is to essentially create a working copy of the code in your own namespace (account) 4. You can name the repository whatever you like, but I have used 'armbian_build' and I notice @Gunjan Gupta did the same because 'build' looks a bit too generic without the armbian context 5. You will now have a repository 'fork' of Armbian build in your own namespace, eg. ArmbianHacker/armbian_build 6. The next step is my personal workflow, but I prefer to work on a branch in my own fork of the repo, so it doesn't get mixed up with your copy of the 'main' branch that is tracking the same branch in 'Armbian/build', so in your own copy of the repository, drop down the branch dropdown box that will say 'main' and create a new branch by typing 'zero3_overlay_fixes' or similar, when you type out a branch name the dropdown menu then gives you the option to 'Create new branch zero3_overlay_fixes from main', click this to create your new branch 7. Now you have your new branch, make sure it's selected in the branch dropdown, and you can make the updates/modifications in that branch that you would like to include in your PR. If you are using git command line, clone your copy of the repository (ArmbianHacker/armbian_build) and switch to the 'zero3_overlay_fixes' branch to make your changes, then push them back up. This branch is where we can collaborate on the changes 8. Once you are satisfied with the changes in this branch, the PR process is fairly straightforward (but can discuss that further along). With the the 'zero3_overlay_fixes' branch selected in the repository view, you will drop down 'Contribute' and then click 'Open pull request', and select 'Armbian/build:main' as the target. This will then show you a diff between your changes and the Armbian project, and allow you to raise the PR back to the main project, where it will go through the Armbian review process and be merged if it meets their requirements/standards. If anyone has any concerns with these instructions please give me feedback.. or if I have missed something obvious that may help others reading this, please let me know!

It sounds like just a matter of giving you some time to work through this? if you want a hand preparing a PR and reviewing.. or generating/hosting test builds for others, let me know Based on this, we shouldn't promote my i2c3 changes (which enables in the base dts) as it is optional and should be in your overlay work. Let me know how you go, and if you need anything... appreciate your efforts on this!

What are your thoughts on splitting the overlay files out to be board specific? they will be some duplication, but will give the flexibility to configure the boards exactly as needed, without potential impact to current/future boards? I think the overhead/duplication is worth the trade off, but maybe that isn't a decision we have the luxury of making. @Gunjan Gupta do you have any thoughts on making the overlay configuration board specific for these boards? zero2, zero2w, zero3?

Yeah I was looking at the zero2w layout yesterday.. I think the overlay work may trip us up when we get to the zero2w, as it is also H618. I am keen to get the single line OVERLAY_PREFIX into the configuration in mainline Armbian, but also wonder if we should just break out the overlays to be board specific given the complexity with zero2w? what will we use as an OVERLAY_PREFIX when we hit zero2w? If nothing else, this would be a good fix to get in and thanks to @Stephen Graf for digging through this, it has been good to read your various attempts and progress through getting it working

Thanks for this feedback @jokakilla, are you running a heatsink? Interested in CPU temps, uptime, and cpufreq-info output if you have it? would be good to confirm that is working reliably over the longer term.

Hi @TechX and welcome to the forum. The current state of the images is that they are in heavy development, so they can't be expected to be reliable. That being said, they won't get to a state of being 'reliable' without adequate testing, so you've arrived at the right time to contribute to that if you are interested, and the result at the end may well be a reliable image The latest build I have done for testing is available here (USE AT YOUR OWN RISK) https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.i2c3.test.tar.xz By all means, test this image and see what kind of results you get and provide feedback here. We're more interested in the lower level feedback on network/wifi/bluetooth etc, rather than application and userspace feedback that applications don't work as expected on the image. Hopefully with more feedback we can get to the point of a reliable image. Cheers for your interest

I have only really known about overlays for 24 hours, but this sounds like a good plan to me. My only question is (as I don't play in this space much), what's the issue with having these enabled by default? and what benefit are you getting by making this disabled with a toggle? From a user experience perspective, there is then an additional step (armbian-config) to make this 'work', but I assume there is a benefit such a memory or power efficiency perspective for having these off if they aren't in use? I would really like the overlays to be named h61x if they apply to both 616 and 618.. but I haven't thought too deeply about that. As long as we are happy with h618 always matching the h616 due to the fact that they are pin compatible as @Gunjan Gupta says, I guess we stay with h616 to avoid changing thing unnecessarily. @Stephen Graf I am happy to take up your offer of you figuring it out, as you seem well versed in this part of the board. If you would like me to do a rebuild where those components are removed from the base configuration (so you can move them to overlays), I can do that on my i2c3 branch in github if you like, based on the list you have provided, just let me know.. as I am keen to assist where I can. As always, thanks to the assistance and feedback everyone, it's been an excellent help in gaining understanding of the board and Armbian and I am sure others following along will also get value out of this information.