c0rnelius

@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

Yes. It's already ticked on in the defconfig.

Should be available in future kernel builds. https://github.com/armbian/build/commit/db3fdc74117392d3d0c0ec02811c8939769fe6da

Both Bluetooth and i2c2 use GPIOX_17 and GPIOX_18, so we need to disable Bluetooth for those HEADER PINS to function. Basically, if you need i2c2 than you are going to lose Bluetooth support.

@jak Try this one. /dts-v1/; /plugin/; / { fragment@0 { target = <&i2c2>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&uart_A>; __overlay__ { status = "disabled"; }; }; }; Result in my case: bananapi: ~ $ sudo i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --

@jak Something is a-mis. I'll need to investigate and get back to you. The working IMG you are referring to is using an old BSP kernel, which is not used here.

Create an overlay and enable it. /dts-v1/; /plugin/; / { fragment@0 { target = <&i2c2>; __overlay__ { status = "okay"; }; }; };

I have this issue with the Le Potato from time to time. I use a service and script to run `ethtool -r eth0`.

The current github drivers for this dongle are a mess. Hopefully by the next LTS this will have been merged; https://lore.kernel.org/linux-wireless/435af284-0794-48e0-81a5-5a88b3c454bf@gmail.com/T/#t For the time being use: https://github.com/lwfinger/rtw88 If needed and isn't installed already the latest firmware can be found here; https://github.com/armbian/firmware/tree/master/rtw88

Read the post and check the PR link and or follow the fellas post below. The IMGs need to be updated, so currently that's the only remedy as far as I know.

Normally out of the gate Samba doesn't just work. You need to setup up the /etc/samba/smb.conf file and add a user to it. sudo smbpasswd -a yourusername Here is an example conf file smb.conf EDIT: That smb.conf file I pulled off a NAS I have running on a bullseye install, on my newer ones I set both client and server to NT1. client min protocol = NT1 server min protocol = NT1 I can't recall the reasons why now, but pretty sure it had something to do with functionality. You can google the client and server options and set it to whatever best suits ur needs.

Scroll to the bottom of the page and try a rolling release IMG. https://www.armbian.com/bananapi-m4-zero/ We are in the middle of sorting out the BT, but WiFi should work VIA overlay. My notes are here; https://github.com/armbian/build/pull/7332

@Eloy Bote Falcon Try this pre-compiled binary. I'm gonna need to re-write some of that patch to work with armbian. sun50i-h618-bananapi-m4-zero-v2.dtb