c0rnelius

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

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

I would think it just being there is good enough.

I'm told the bluetooth doesn't work, which is why I haven't submitted it. The patch was also done quick and dirty and I'm sure needs some clean up. 0001-arch-arm64-dts-allwinner-sun50i-h618-bananapi-m4-zero-v2.patch

I'm honestly not sure about the specs. I only know they have a new REV out, as someone has already approached me about WiFi not working. One way to tell would be looking at the WiFi module on the unit. If it isn't REALTEK, than its the new REV. Attached was the chipset on their unit.

I have tried it "post-power-on-delay". With and without it, I didn't see any difference. So I opted to just remove it. If for sure its needed on ur end, I can add it back in. My current theory is that it was caused by the increase in the freq. As for diff revs of the unit? I'm not sure. The current unit I am using to run the wifi tests on is attached to a Waveshare CM4-IO-BASE-B. As that's the only one I could easily attach an antenna to. I wouldn't think the baseboard would create any wifi hiccups though? The one interesting thing I did notice; is wifi was faster when running from SDCARD. One of my units run via NVMe and the other from SATA. Maybe the extra power draw when running from NVMe is effecting the wifi?

When did you purchase the unit? The new BPI-M4-ZERO has SDIO WiFi and uses BRCM. The older units have WiFi over USB and use REALTEK. Unfortunately I don't have the newer unit.

Adding it doesn't seem to bring anything to the table. After messing around with it further the key changes / additions appear to be: max-frequency = <100000000>; vqmmc-supply = <&vddao_1v8>; /delete-property/ amlogic,dram-access-quirk; Booting the board. I suspect it's the freq being at 200000000, as I haven't seen it happen since I lowered it. As for adding an overlay to change the max freq, sure I can do that when i submit the final patch.

This patch seems to be more stable when using rtw88. I removed a few bits that shouldn't be required and dropped the freq down a bit. 0001-BananaPi-CM4-improve-SDIO-WiFi-speeds.patch