Thank you a lot, my Dragon Q6A now has audio

Hey just checking in. I haven't forgotten about this yet, I want to make sure everything is repeatable and possible to do on multiple versions of armbian before I write a guide and confuse a lot of people. Noticing that mpv doesn't work, I tried to do what jock suggested to Harleyyyu and update to a newer kernel version. So far... no luck. Seems like the problem boils down to having to write u-boot.bin to the eMCP before burning the actual OS onto it. I'll write again if anything goes.

If this is AW869A chip then it uses the AIC 8800 Linux Driver. My X98H TV box has a AIC8800 chip in it. https://linux-sunxi.org/Wifi#AW869A AW869A The AW869A is a highly integrated module with Dual band WiFi6 combination solution to support 1 × 1 IEEE 802.11b/g/n/ac/ax WLAN standards It uses the aic8800 firmware. A driver can be found at AIC 8800 Linux Driver. You'll need to compare the GPIO settings. Your Android dts uses HEX the mainline kernel is using DEC. https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=12 rfkill { compatible = "allwinner,sunxi-rfkill"; status = "okay"; chip_en; power_en; pinctrl-0 = <0x63>; pinctrl-names = "default"; phandle = <0xcc>; wlan { compatible = "allwinner,sunxi-wlan"; clocks = <0x0e 0x04>; clock-names = "osc32k-out"; wlan_busnum = <0x01>; wlan_power; wlan_regon = <0x23 0x06 0x12 0x00>; wlan_hostwake = <0x23 0x06 0x0f 0x00>; wakeup-source; phandle = <0xcd>; }; bt { compatible = "allwinner,sunxi-bt"; clocks = <0x0e 0x04>; clock-names = "osc32k-out"; bt_power; bt_rst_n = <0x23 0x06 0x13 0x01>; phandle = <0xce>; }; }; btlpm { compatible = "allwinner,sunxi-btlpm"; status = "okay"; uart_index = <0x01>; bt_wake = <0x23 0x06 0x11 0x00>; bt_hostwake = <0x23 0x06 0x10 0x01>; wakeup-source; phandle = <0xd0>; }; Mainline dts: https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L87-L95 https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L182-L200 https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L278-L297 The specific values <0x23 0x06 0x12 0x00> generally map to: 0x23: The controller or bank ID: pinctrl@300b000 { phandle = <0x23>; 0x06: The specific GPIO pin number: In Allwinner's pinctrl driver, banks are 32 pins wide. The formula is: (Bank_Letter_Index * 32) + Pin_Number 1. The Bank Index Map Bank Index PA 0 PB 1 PC 2 PD 3 PE 4 PF 5 PG 6 PH 7 PI 8 0x12: The active-high/low flags or drive strength. In the 3-cell GPIO format used by Allwinner (sunxi), the third cell (e.g., 0x12) is a bitmask that defines the electrical properties of the pin. To decode 0x12 (which is binary 0001 0010), you break it down into bits: 1. Bitmask Breakdown for 0x12 Bit 0 (0x01): Active Polarity. 0 = Active High. 1 = Active Low (Our bit 0 is 0, so this is Active High). Bit 1 (0x02): Open Drain / Open Source. 0 = Push-Pull. 1 = Single-ended/Open-Drain (Our bit 1 is 1, so this is Open-Drain). Bit 4 (0x10): Internal Pull-up. 0 = No pull-up. 1 = Pull-up Enabled (Our bit 4 is 1, so this is Pull-up Enabled). Summary of 0x12: This pin is configured as Active High, with an Open-Drain output and an internal Pull-up resistor enabled. 0x00: Reserved or additional configuration. In Allwinner-based systems (like the H6 or H616), this value is defined in the GPIO controller's device tree binding documentation within the Linux kernel source code. The structure is documented in the kernel under Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml

@jock I figured out why the cursor doesn't show and it's not an armbian issue, the issue is more on how i implemented ffmpeg (previously Kmssink) on openauto and also the same reason why i can't use eglfs for the gui is that i had set ffmpeg to use plane 31 (primary plane, zpos 0) when streaming Android Auto. Since I am forcing the video stream directly onto the Primary Plane (Plane 31) via DRM, the hardware VOP (Video Output Processor) stops scanning out the Linux Framebuffer (/dev/fb0). This means that while Qt is still technically "running" and drawing the mouse cursor to the framebuffer in software, that buffer is simply never sent to the screen. The video stream completely overrides the UI layer. I did manage to fix it tho, since the RK322x SOCs support Tri-Plane, I had to patch ffmpeg to utilize the Cursor Plane (plane 41). Now when AA starts ffmpeg initializes the video on the Primary plane as usual, but simultaneously commits the ARGB cursor buffer to Plane 41 using the shared DRM file descriptor. This allows the VOP to hardware-composite the mouse cursor directly on top of the video stream, finally making it visible without breaking the zero-copy pipeline. As per CMA=256M, ffmpeg was throwing buffer allocation warnings. Interestingly, these warnings persist even with CMA set to 256MB—so the larger CMA didn't actually silence the logs as I initially thought. ffmpeg benchmarks actually run successfully on both 16MB and 256MB despite the warnings. However, I decided to keep the requirement at 256MB purely as a precaution. Given that a 1080p NV12 pipeline with multiple buffers can eat up memory quickly, leaving it at the default 16MB felt risky for long-term stability in a car environment, even if it 'technically' runs. PS: i haven't posted the build with the cursor patch

Needs testing; https://github.com/armbian/build/pull/9323