c0rnelius

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/

sudo groupadd gpio sudo adduser wollik gpio

I rarely use an SBC with a head. I suspect packages need to be created to bring in proper GUI support.

They were custom built. I suspect the issue is: https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch

@dnwhoop02 sudo dd if=u-boot.bin of=/dev/mmcblk1 bs=512 seek=1

Find the /dev/node `lsblk` Flashing options: eMMC: sudo dd if=u-boot.bin of=/dev/mmcblkX bs=512 seek=1 SDCARD: sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=1 count=442 sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=512 skip=1 seek=1 u-boot.bin u-boot.bin.sd.bin

https://github.com/armbian/build/pull/7694 patrick@rpi4b:~$ dmesg | grep brcmfmac [ 3.443168] brcmfmac: F1 signature read @0x18000000=0x15264345 [ 3.444363] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 3.444650] usbcore: registered new interface driver brcmfmac [ 3.673499] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 3.673793] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2 [ 8.815477] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled

I just maintain a few boards here and help out where I can.

The kernel checks a few places for firmware blobs. https://docs.kernel.org/driver-api/firmware/fw_search_path.html You can also set a firmware path in cmdline. This usually isn't needed though. firmware_class.path=/lib/firmware/updates/brcm The kernel checks /lib/firmware/updates before /lib/firmware, allowing us to be able to test new firmware without removing the old.

yes

Does this resolve it? sudo git clone --depth=1 https://github.com/pyavitz/firmware.git /lib/firmware/updates/brcm If so we should be able to resolve this for future builds.

Try adding auto to it. UUID=<output-of-bklid-for-sda1> /media/USB01 ext4 defaults,noatime,auto 0 1