Hello @RadxaYuntian,
Thanks for the dtb file that fixed issue with my devices. Will this be incorporated in to a new image soon ? Also, I am seeing the pulseaudio mixer issue as well.
i.e. fe.dai-link-0: ASoC: no backend DAIs enabled for fe.dai-link-0strong text
Cheers,
Charles
Hi @gnlkrmz, I reread this entire thread focusing on your posts. Your dmesg output is the same as mine whether or not wlan0 loads and connects.
Given your other working board and clear competence in troubleshooting, sounds like you are down to it being a hardware issue.
Sorry to not be more helpful. Perhaps as a last ditch sanity check, you could remove the brcmfmac module then reload it if you haven’t already.
I had run that as a matter of course and @SKRSKR mentioned doing that in this thread a few weeks ago: https://forum.radxa.com/t/my-zero-wi-fi-is-not-working/8923/2
Either way, here’s to the replacement being good to go 
Hi @linuxlion
yes, i do agree.
I did try and still trying to solve the issue. But the allnetchina side and return process isnt smooth or helpful compare to this forum or developers who are taking their time to resolve issues and helping alot.
I’ve been chatting with allnetchina for weeks and it is getting very difficult to get a replacement or even just a simple refund.
They still believe and saying “developers are trying to solve it” no matter how much i direct them to this topic…
I did send them one last email yesterday and still waiting to hear back. looks like they are having difficult time covering the cost of shipping back too, But, i did offer them to share the cost of shipping too. (which i dont have to)
I wish i just bought the board from ameridroid (they didn’t have it in stock at that time) instead of directly from allnetchina. At least i would have more smooth and not time consuming conversation for days…Because i got my other board from ameridroid, and never had issue with communication.
We’ll see how it goes after latest email.
But it should be much more smoother to return, specially for a person who is been on forum and troubleshooting to resolve the issue. I clearly told them that i did not came out of blue, you can see my postings and developers trying to help, and on top of it, i do have a perfectly working board which i can compare with.
I apologize for offtopic / “little bit of complain” posting. But i do think it needs to be reflected at this point. Because there might be other people might have the same problem, and these processes should be more smoother and clear on allnetchina side.
We may very well have to so people can have working albeit slower Wi-Fi. The workaround reduces the performance, but if we can’t identify the root cause then we might have to swallow the bitter pill.
As for the amixer issue can you check if this helps? This one we are looking to add to the image soon. The fix is already merged in Armbian.
Hi @gnlkrmz, bummer to hear that Allnetchina isn’t stepping up on this. I wonder if there’s the possibility for Radxa to credit a board to Ameridroid to send to you?
Then all things being equal, they could reduce Allnetchina’s next order by one board for the replacement.
There may still be a question of getting the old board to Radxa to diagnose if that’s of use to them.
However things go, I think it’s helpful for the community to document the outcome.
Best of luck!
Hi @RadxaYuntian, thought it worth mentioning with the fix in place I noted 6.2 MB/s over scp while backing up a docker tarball via 2.4Ghz wifi on the same LAN. The backup system is on gigabit ethernet, so other than some encryption overhead it’s a good representation of realworld network speed. It would be trivial to test over nfs or smbfs as well. All things considered, that’s about 50Mbps.
The Zero shows a max connection of 72Mbps while that band with other devices is capable of over 100Mbps.
I haven’t tried the Zero on the AC band. I’ll run some iperf profiling on that as time allows and post results here to document if the wifi fix is much of a pill.
I can confirm seeing the error @kalkocz indicates regularly in virtual terminals:
fe.dai-link-0: ASoC: no backend DAIs enabled for fe.dai-link-0
Cheers!
I wouldn’t involve Ameridroid at this point. Because the board i got from them is working perfectly. To be honest why would i fiind solution for allnetchina right ? thats their job to come up with simple solution.
and Yes allnetchina would like to investigate the board, but i wouldn’t wanna pay the price for them to investigate.
It only makes sense to me; for them to cover the cost of delivering the board to them + make the refund to me. If i dont send they told me no refund…lets see if they’ll be willing to cover the cost of shipping (which is almost half price of the board - and cheapest quote i can get)
I like to just buy one more board and move forward with my project. But I’m basically stuck with this board and don’t wanna let it go.
Honestly, if they approached me in a more helpful manner, i would actually tell them to send me a replacement and i will send them the board by covering the cost myself…but of course too late for that. Specially my chat with them was pretty bad (who ever is that, didn’t wanna disclose that too) At this point, Email is little more polite in this manner, we’ll see what they say when they get back.
Instead of dropping the frequency, I’ve had success doing the following.
diff -Naur a/arch/arm64/boot/dts/amlogic/meson-g12a-radxa-zero.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-radxa-zero.dts
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-radxa-zero.dts 2022-03-20 16:14:17.000000000 -0400
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-radxa-zero.dts 2022-03-27 07:44:01.636737819 -0400
@@ -310,7 +310,7 @@
bus-width = <4>;
cap-sd-highspeed;
- sd-uhs-sdr50;
+ cap-mmc-highspeed;
max-frequency = <100000000>;
non-removable;
This can also be tested using an initramfs post update script. It depends on: device-tree-compiler
sudo mkdir -p /etc/initramfs/post-update.d/
sudo wget -cq https://raw.githubusercontent.com/pyavitz/debian-image-builder/feature/files/boot/99-sdio-speed -P /etc/initramfs/post-update.d/
sudo chmod +x /etc/initramfs/post-update.d/99-sdio-speed
sudo chown root:root /etc/initramfs/post-update.d/99-sdio-speed
sudo /etc/initramfs/post-update.d/99-sdio-speed
Depending on where your dtb is located one may need to adjust the FDTDIR= variable at the top of the script.
Hi @c0rnelius, nice work and sweet bash code!
Some context for the rest of us, I found it interesting to see the entry in situ:
https://github.com/radxa/kernel/blob/617a45dd0fce8a4e63693d62578ef720941f9784/arch/arm64/boot/dts/amlogic/meson-g12a-radxa-zero.dts#L343
Cheers!
Some additional details on wifi issues. I’ve had a Radxa Zero running as the controller for a multi-zone smart heating system.
The system has been running for a couple weeks, however after about 5.5 days without any changes or reboots, wifi became non-responsive.
Connecting a monitor and keyboard showed errors to the console indicating the wifi module was unable to return from sleep, namely:
[495167.523518] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[495167.532223] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[495167.534935] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[495167.537791] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[495167.540588] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[495167.543293] brcmfmac: brcmf_sdio_dpc: sdio ctrlframe tx failed err=-100
[495167.545856] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
[495167.545869] ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[495167.551001] ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[495167.928131] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -100
[495167.931032] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
which was repeating ad nauseam. Logging in and unloading the related modules with rmmod brcmfmac cfg80211 brmutil ended the error output, however reloading the modules and restarting the networking daemon with systemctl restart networking still offered no wlan0 device accessible via ifconfig or iwconfig.
While typically my last resort, a reboot returned the wlan0 connection. Looking at the current settings via
iwconfig wlan0 showed among other things:
…
Power Management:on
…
Disabling this is simply a matter of running:
iwconfig wlan0 power off
Making this permanent can either be via adding that command to /etc/rc.local or updating the NetworkManager powersave default config.
Hope this helps somebody else 
If using NetworkManager you can turn off power save mode by doing the following:
sudo sed -i 's/wifi.powersave = 3/wifi.powersave = 2/g' /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
If using ifupdown, add the following to the /etc/network/interfaces file
allow-hotplug wlan0
iface wlan0 inet dhcp
wireless-power off # <-- turn off power save mode
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Hi @c0rnelius, well done on the find & replace one liner!
Even tho I’m using NetworkManager, I didn’t have a
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
file or actually anything in that directory.
For those in the same boat, a command like this would create the file if it does not exist and ensure powersaving is off:
NMPSCONF=/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf \
if [ -f "$NMPSCONF" ]; then \
sudo sed -i 's/wifi.powersave = 3/wifi.powersave = 2/g' "$NMPSCONF"; else \
echo -e "[connection]\nwifi.powersave = 2" | sudo tee -a "$NMPSCONF"; fi
Or it can be saved as a shell script minus the backslashes and executed or simply create & edit the file.
Cheers!
Have you ever tested if performance changes with this solution? Can you explain how you came up with this idea (I’m trying to understand what mmc highspeed means but I’m not familiar with this embedded interface/controller)?
I just checked upstream linux kernel and it does not have this fix applied, so if anyone has this weird itch to run the latest kernel… maybe this is something to keep in mind.
This sd-uhs-sdr50; was removed from the upstream dts. Its kind of mute now as most people probs have a 1.5 rev, than a 1.4 or lower.
How I came to the conclusion? I noticed Radxa made changes HW wise between 1.4 and 1.5. The 1.5 had probs connecting to wifi and would spit out sdio errors. I reviewed the DTS and after trial and error came to the conclusion that removing sd-uhs-sdr50 and replacing it with the mmc bit solved the problem for me. I guess they did further testing and decided the mmc bit wasn’t needed “which makes sense” and just purged sd-uhs-sdr50 completely.
This change isn’t needed for 1.4. It actually hampers performance in my testing.
Thank you for the explanation c0rnelius on this old thread!
Where? This is upstream 5.19 and it still has it, am I referring to the wrong “upstream”?
Ah my bad. I could have sworn I checked that the other day and it was gone. Guess I was looking in the wrong place at the time. Anyway, essentially what this is doing is suggesting the speed; https://elixir.bootlin.com/linux/v5.19/source/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
I also noticed the LED doesn’t work properly because of the GPIO being switched from 8 to 10. Which can also be fixed by adjusting the dts.
1.5 Minor adjustment
Switched to a different USB Configuration Channel controller due to part shortage
The Power LED now can be controlled by GPIO_AO10
So it would appear one or both of those changes created the initial issue or I’m just lucky and my 1.4 came off the line rock solid. 
Hello, I’ve got bad news. This issue is not solved, I’m now seeing the same
brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
errors in dmesg, with a recent kernel (5.19) from arch linux arm. I’m using radxa dtbs, so I have the current workaround that reduces max-frequency to 80’000’000. It happened after about 2 days of uptime, maybe during the night.
Right now I can not do anything to access the system, so I’ll have to power it down. But if any developer wants to, I can try to setup something to get them remote access via serial to try to understand what this is.
Board is radxa zero v1.51 with 512MB RAM (no eMMC), HDMI connected to a display.
Had this exact same issue on Rock 5B SD and EMMC cards on an EERO network. Disabling 5GHz did not work but this did. Using rock-5b-debian-bullseye-xfce4-arm64-20221031-1558-gpt.img.xz This fixed me so thank you! I am using the RADXA M.2 WiFi 6 BT5 Module A8
Any update on wifi working on android?