What about the step of selecting the uboot?

Step 1. Downloaded "Armbian_community_26.2.0-trunk.606_Aml-s9xx-box_trixie_current_6.18.18_minimal.img.xz" again. Step 2. Opend it with balenaEtcher on 24.04.4 LTS and flashed successful to 16GB Sandisk SD Card. Step 3: Edited extlinux.conf Step 4. I shutted down the Optiplex 3000 TC and removed the SD-Card. Step 5. I inserted the SD-Card into the SD-Card Slot of my Wetek Play 2 (of course WeOS 3.2 is on internal eMMC). Step 6. I press and hold the Power Button of the Wetek Play 2 to initiate the SD-Card Boot. Result: After unexpected long time the WETEK Play.2 Logo disappears and WeOS starts and NOT armbian.

if I understand it correctly, LT8619C is responsible for extracting the audio from HDMI output, and the kernel doesn't have support for it. here's the closest thing that I could find: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/lontium-lt8912b.c the original Bigtreetech firmware has the sound, will try their image again tomorrow.

Thanks Werner, Unfortunately I have to halt this project. Though I can now create an booting Neo3plus Armbian image based on the Zero2, it does not fit my initial requirements. Obviously u-boot requires an android partition scheme. The current version as used by the nanopi zero2 cannot be used for my own purposes. So it will need to wait until the board can boot without a vendor u-boot version.

> Is there a way to test different DTS without physical meddling with our SBCs? Using armbian-config from Armbian-unofficial_25.05.0-trunk_Transpeed-8k618 image says I cannot edit DTS at all, but even if I could, wouldn't it simply soft-brick the SBC if DTS is incompatible? > Would it be feasible to have uboot + dts + maybe a kernel + some utils, so that we could boot any standard ARM ISO ever produced? Armbian would become standardised, then "firmware" layer is up to the user - whether their device has real UEFI, my proposed environment, or the current all-in-one blob solution seen in all ARM distros. > I found zero actionable information on how to create DTS for given device, is it arcane information for electronics lovers? Do I need to compile specific kernel for it? Given our SBCs have 100% working DTS for Android, couldn't LLMs work out the difference between how Android expects it and how Armbian does? It's awful this division exists, but c'mon this doesn't seem like intelligent problem requiring solutions, but a machinistic mapping of boring register addresses and the corresponding syntax? These seem like standard groundwork that needs to be laid out before any work on any project starts, but in embedded world these lacks in operational hygene consume 99.99% of work focus, don't they? and in the end nothing really works as it should.. Yes, I'm worthless here, but aren't these problems hurting literally everyone to ever use any SBCs, including raspberries, oranges etc. I wish I could help, but the entry seems steep.