c0rnelius

The RTW88 driver was included for this; https://github.com/armbian/build/pull/7634 Prob needs to be ticked on in the defconfig for RK. Unless RK opted out of RTW88. patrick@potato:~$ uname -a Linux potato 6.12.21 #1 SMP PREEMPT Sat Apr 5 10:17:54 EDT 2025 aarch64 aarch64 aarch64 GNU/Linux patrick@potato:~$ lsmod | grep rtw88 rtw88_8821au 12288 0 rtw88_8821a 40960 1 rtw88_8821au rtw88_88xxa 32768 1 rtw88_8821a rtw88_usb 28672 1 rtw88_8821au rtw88_core 172032 3 rtw88_88xxa,rtw88_8821a,rtw88_usb mac80211 655360 2 rtw88_core,rtw88_usb cfg80211 438272 2 rtw88_core,mac80211 patrick@potato:~$ lsusb Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 005: ID 31b2:0010 Bus 001 Device 004: ID 0bda:a811 Realtek Semiconductor Corp. RTL8811AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I'm waiting for the HDMI part of the audio patch to drop. There is currently discussion going on about the Audio in a private chat, concerning 6.12.y and up, but I haven't seen consensus yet. Once its reached, I will drop in the nodes. This could take time.

There was no official audio routing for the h616 until recently and still none yet for HDMI. As far as I know? https://lore.kernel.org/linux-arm-kernel/20241023075917.186835-1-ryan@testtoast.com/T/ I believe there is unofficial patching for it available in Armbian for 6.6.y, but I never added the required nodes to test it. This would be why there is no functional audio on the unit as of yet.

Last I checked PBOOT looks for a BOOT partition. By default Armbian uses a ROOTFS, which is probs why it can't find it.

https://github.com/armbian/build/pull/7951

If it's detecting more or less dram than it should, its U-Boot related. Depending on the version of u-boot there are two remedies as far as I know. Put a delay on it; https://github.com/armbian/build/blob/main/patch/u-boot/v2024.04/board_bananapim4zero/006-mach-sunxi-dram_helpers-add-delay-to-steady-dram-detection.patch For v2025.01 and above; https://lore.kernel.org/linux-sunxi/20250309063143.62859-1-jernej.skrabec@gmail.com/T/#t

Is the armbian firmware package installed? This error means the firmware is missing or not found: [ 6.382883] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-compute-module.bin failed with error -2 [ 6.382928] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.bin failed with error -2 What carrier board are you using? If not using the RPI carrier, you may need to adjust pins to get Wifi to work. Also, make sure your eeprom is up to date.

If it should get it accepted; https://github.com/armbian/build/pull/7900

Yes. So instead of this patch; https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.12/board-odroidc4-reset.patch which only patches the C4 DTS, create a new patch, that patches against the "meson-sm1-odroid.dtsi". Problem solved. An example can be found in my personal repo; https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/6.12/007-ODROID-general-patch-set.patch#L281

The solution here would be doing a PR and instead of adding the node to the DTS, it should be added to the DTSI "meson-sm1-odroid.dtsi" which both units "C4/HC4" would pick up. + reboot: meson64-reboot { + compatible = "meson64,reboot"; + sys_reset = <0x84000009>; + sys_poweroff = <0x84000008>; + + sd-vqen = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>; + sd-vqsw = <&gpio_ao GPIOAO_6 GPIO_ACTIVE_HIGH>; + sd-vmmc = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; + }; +

Yes. The builds are identical, which is why the rpi5b conf was removed.

https://github.com/armbian/build/pull/7845/files

`sudo modprobe i2c-dev` ?

@hvedemelsbof What the patch is doing is changing the boot targets. Normally SD/MMC would take priority and USB, NVMe and SCSI would be the fall back. With SPI onboard, you could still achieve USB boot by enabling PREBOOT in the u-boot defconfig, along with `usb start`. So in that case the patch wouldn't be required. Same goes for NVMe and SATA boot. In my testing, this also works if you treat the SD or MMC as just a boot mech. Flashing u-boot to it and installing the OS directly to the USB, NVMe or SATA drive. In my opinion those patches should no longer be used, as cleaner methods are available. But that's not my call. I've never messed with this boot_target variable. Looks to me, if you set that var in the boot.cmd/scr, you can change the hard coded targets. Whether or not it will work on AML units, I have no clue.

My guess is, the bulk of the GUI issues stems from the version of Mesa being used. Try the one in their repo; https://gitee.com/bianbu-linux/mesa3d/tree/bl-v2.0.y/