c0rnelius

@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

Sweet. Let me know in a few days and if it's a go I'll do a PR.

@vimal try this patch with the github driver. 0001-sdio-wifi-fixups.patch

@vimal I can't say for sure; but my guess is that the dts being used was based on this https://github.com/armbian/build/blob/v23.02/patch/kernel/archive/meson64-6.1/add-board-bananapi-m2s-initial-support.patch There was no official CM4 DTS in mainline on 6.0.y and the two boards have a lot in common. I've messed around with &sd_emmc_a node, but I'm personally not seeing any improvements. 0001-sdio-fixups.patch

Sorry. Both of my CM4's have a heatsink+fan combo on them, making it pretty tough to attach the antennas without removing the setup. I use them both wired. I do have other units with the same SDIO and yes, they all get the same speeds using rtw88. It has been a complaint since day one as far as I know. This was the last discussion we had about the driver: https://github.com/armbian/build/pull/6703#issuecomment-2154619094 which goes into other problems. One option would be; figure out why the github driver doesn't work on the unit and do a PR on the repo. https://github.com/jethome-ru/rtl88x2cs

The build comes with both rtw88 and the github variant. rtw88 gets loaded first "it has priority", so blacklist rtw88 and see if you get better performance. I seriously doubt it's the DTS. But ur more than welcome to go that route. If you find edits to the DTS are beneficial in this department please let us know. EDIT: I just remembered something. During the bring up process, I found the github variant didn't work on this unit. This was the main motivation for backporting rtw88 into Armbian when it was still on 6.1.y.

This is the important part here. Use an antenna. What that ancient kernel is running is an old github driver.

Well you are more than welcome to use what you want from the patches for S905X3. I've only run tests on the ones I have of course, but the SPDIF and ANALOG are identical on both. I suspect they are probs generally the same on most of those BOXES.

Nah. I haven't submitted them. I've considered doing a PR to Armbian, but just never did as I'm honestly not sure what the state of things are on the Armbian front when it comes to TVBOXES.

This can be done on S905X3 boxes "tested on the X96AIR-GBIT and H96MAX", but it would require patching the DTS files and applying the correct mixer settings. amixer -c 0 set 'TOHDMITX' 'on' amixer -c 0 set 'TOHDMITX I2S SRC' 'I2S B' amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' amixer -c 0 set 'FRDDR_A SRC 3 EN' 'on' amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 3' amixer -c 0 set 'SPDIFOUT_A SRC SEL' 'IN 0' amixer -c 0 set 'ACODEC' '85%' alsactl store Can also boot with mainline u-boot on them, but you would lose the ability to easily go back to Android. The patch I use for linux 6.6.y; 004-arch-arm64-dts-amlogic-meson-sm1-ac2xx-tv-boxes.patch

I think the problem is Pine and not Armbian here. But I understand your point of view.

Trixie is what the next official release will be. So it will stay rolling until it hits a freeze point and shortly after which released. If you really wanna stay rolling; testing, unstable and sid is where you wanna be. But I wouldn't use any for a daily or production unit.

> As a result m2s always boots from emmc with Armbian ignoring SD card with official images, that is ok. This is probably a result of the binary being used to boot from the SD card, which is the default bin flashed to the IMGs. u-boot.bin: eMMC u-boot.bin.sd.bin: SD In practice the u-boot.bin should be flashed to eMMC and u-boot.bin.sd.bin flashed to SD. Otherwise it will screw up the boot order. But that is neither here nor there. You got it working and that's what matters.

I understand. It is for sure a problem that needs to be resolved in Armbian. Not being able to easily input USER information and WIFI cred into a file before first boot is not ideal. Unless I'm missing something and someone knows of way to easily accomplish this? As far as minimal installs, it does seem it leans towards using netplan.io. One option would be to `sudo apt install -y armbian-config network-manager` followed by `sudo apt purge netplan.io --autoremove` and reboot. Once rebooted you can use either `sudo nmtui` or `sudo armbian-config` to setup WIFI with a bit more ease.

I don't have that baseboard, but my guess is, it's the same issue that has been reported before. Basically HOST mode needs to be enabled via overlay using `armbian-config`.

I suspect the issue is the version of U-Boot currently on the eMMC. When the board boots, if U-Boot is found on the eMMC, that is what will be used to do the initial boot. If an SDCARD is detected with a viable OS, it will then attempt to load it. It may be that the version of U-Boot "BSP?" on the eMMC is not compatible with Armbian and needs to be dd'd off. I just flashed this to SD to test. Came up fine. ____ ____ _ __ __ ____ ____ | __ )| _ \(_) | \/ |___ \/ ___| | _ \| |_) | | | |\/| | __) \___ \ | |_) | __/| | | | | |/ __/ ___) | |____/|_| |_| |_| |_|_____|____/ Welcome to Armbian 24.5.3 Bookworm with Linux 6.6.36-current-meson64 System load: 10% Up time: 1 min Memory usage: 4% of 3.69G IP: CPU temp: 37°C Usage of /: 4% of 29G [ Menu-driven system configuration (beta): sudo apt update && sudo apt install armbian-config ]

Your welcome.