My zero Wi-Fi is not working

Hi @RadxaYuntian
I’m getting comments from .allnet team that the Wi-Fi problem i was facing is a software issue on zero board ? and they told me that developers are working on it.
Do you have any information about it ?

Thank you

Your issue is weird and so far you are the only one reporting this specific issue (Wi-Fi listed but won’t connect). Allnet was talking about another issue where Wi-Fi device won’t properly initialize. We are working on the latter but we have no clue on your issue since we can’t reproduce it.

1 Like

Hi @RadxaYuntian,

I have six zero’s three of them demonstrate this behavior. I have tried multiple different images including the base android image. I have also tried different power supplies to see if it’s an under volt issue. I have also tried to update the AP6256 firmware images as well.

It seems to be some sort of timing issue on power up.

Here is the type of error I see on boot which prevents wlan0 from being created. The current workaround is to logon via serial console and do a “rmmod brcmfmac” and then a “modprobe brcmfmac”.

What is strange is that some time it boots correctly and will do that for multiple boots and then randomly start to fail again. So it seems to be some sort transient state and timing error.

Here is the dmesg output.

[Sat Feb 26 03:33:42 2022] systemd[1]: systemd 245.4-4ubuntu3.15 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[Sat Feb 26 03:33:44 2022] brcmfmac: F1 signature read @0x18000000=0x15294345
[Sat Feb 26 03:33:44 2022] brcmfmac: brcmf_chip_cores_check: CPU core not detected
[Sat Feb 26 03:33:44 2022] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed!
[Sat Feb 26 03:33:44 2022] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed
[Sat Feb 26 03:33:44 2022] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19…

Here is where I unload the module and reload it:

[Sat Feb 26 03:35:12 2022] usbcore: deregistering interface driver brcmfmac
[Sat Feb 26 03:35:12 2022] file system registered
[Sat Feb 26 03:35:12 2022] brcmfmac: F1 signature read @0x18000000=0x15294345
[Sat Feb 26 03:35:12 2022] brcmfmac: brcmf_of_probe: interrupt could not be mapped
[Sat Feb 26 03:35:12 2022] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[Sat Feb 26 03:35:12 2022] usbcore: registered new interface driver brcmfmac
[Sat Feb 26 03:35:13 2022] read descriptors
[Sat Feb 26 03:35:13 2022] read strings
[Sat Feb 26 03:35:13 2022] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[Sat Feb 26 03:35:13 2022] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01-a41d86bd es7.c5.n4.a3
[Sat Feb 26 03:35:14 2022] dwc2 ff400000.usb: bound driver configfs-gadget
[Sat Feb 26 03:36:13 2022] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

I have seen other SBC’s that use the AP6256 wifi module seem to have had similar issues. Please have a look at the Pine64 forums .

Finally, wireless and BT/BLE are all stable after doing the workaround. The devices have been up for days with no wireless issues.

Thank for taking the time look in to this for us.

Cheers,
Charles

Yes this is a known issue and we are looking into it. Currently there is a workaround for this issue: reduce SDIO’s frequency. You can (backup and) replace your dtb under boot partition (the exact location differs in different distros) with the following file: https://file.io/y3hjkOXKABAC

SHA256: f9a9fbfaae3ec29009941b13418a7bb88170e7a5951c3e06ea28e8ade5cb03f5 meson-g12a-radxa-zero.dtb

Thank you @RadxaYuntian Unfortunately the included link indicates the file has been deleted. Please advise?

The AP6256 on my Zero has displayed similar intermittent wifi/bt connection issues. Two observations:
a) It seems to happen less when I have the secondary usb-c and mini-hdmi connected.
b) When it does happen, switching to the initial virtual terminal via: Ctrl+Alt+F1 shows bluetooth isn’t able to start. I’ve been trying to grab a pic but since it’s intermittent, it’s been elusive.

When wifi does fail to connect, I’ve been logging into one of the virtual terminals to diagnose. ifconfig and iwconfig don’t show the wlan0 device. I’ve been saving the dmesg output when the device comes up and when it doesn’t. Both show similar errors with brcmfmac. I’m happy to share these if it is helpful.

From here, removing and reloading the module does typically load wifi, ie via:
rmmod brcmfmac
modprobe -i brcmfmac

The problem for me is my application for the Zero is in a utility closet, so disconnecting it and bringing it to a keyboard & monitor is toilsome.

Initially, my troubleshooting was on the OS config side, so I setup wpasupplicant but that provided no joy, since the hardware wasn’t loading.

Please let me know any other details or logs you would find helpful?

Thank you!

meson-g12a-radxa-zero.dtb.zip (13.8 KB)

Sweet, thanks! I’ll test tomorrow and report back…

I took my chances and replaced this file under dtb folder. [Distro = Dietpi]
No luck:(

Thank you @RadxaYuntian, I backed up the old dtb and placed the new file into the folder:
/boot/dtbs/$(uname -r)/amlogic/

And the Zero has reconnected quickly with reboots and shutdowns whether headless or connected via hdmi & usb peripherals.

Hi @gnlkrmz, did you check to see if the data blob is referenced in Dietpi’s /boot/uEnv.txt?

On Radxa’s Debian 10 image it has the line:
fdtfile=amlogic/meson-g12a-radxa-zero.dtb

I’ve not tried Dietpi, so I haven’t reviewed their standard boot settings or blob config.

I was surprised how lightweight the Debian build is. Logged into xfce, RAM usage is < 340MB and even after installing some additional packages emmc usage was just over 2GB. Granted I doubled that with docker setup and image installs but perhaps food for thought depending on your Zero config & use case…

1 Like

Yes i did check and line is there. Honestly, looks like i have a problem with my board. I did try Debian, Ubuntu, Manjaro, Dietpi.
It doesnt work at all.
I have another zero board which works perfectly.

uEnv.txt

verbosity=4
console=ttyAML0,115200
overlay_prefix=meson
rootfstype=ext4
fdtfile=amlogic/meson-g12a-radxa-zero.dtb
overlays=meson-g12a-uart-ao-a-on-gpioao-0-gpioao-1
rootuuid=0a23bd6c-0d3b-458f-9256-9a345cd0e89b
initrdsize=0xbbb9f6
kernelversion=5.10.69-7-amlogic-gfd159ba07d5c
initrdimg=initrd.img-5.10.69-7-amlogic-gfd159ba07d5c
kernelimg=vmlinuz-5.10.69-7-amlogic-gfd159ba07d5c
docker_optimizations=on

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 :upside_down_face:

1 Like

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.

1 Like