openwrt
openwrt copied to clipboard
openwrt
No WiFi radio is detected in MR52 when running master snapshot images (kernel 6.6)
Describe the bug
With master snapshot images (kernel 6.6) for Meraki MR52, none of its WIFI radios is detected and no WIFI firmware is loaded.
OpenWrt version
r26199-0b0e3e22f8
OpenWrt release
SNAPSHOT
OpenWrt target/subtarget
ipq806x/generic
Device
Cisco Meraki MR52
Image kind
Official downloaded image
Steps to reproduce
No response
Actual behaviour
No response
Expected behaviour
No response
Additional info
No response
Diffconfig
No response
Terms
- [X] I am reporting an issue for OpenWrt, not an unsupported fork.
Attach Kernel Log. If you also have a log from the working version, that too.
@namiltd
Some other observations:
In 23.05.3, PoE port = WAN, non-PoE port = LAN. It's the reverse in master kernel 6.6.
In master kernel 6.6:
root@OpenWrt:~# uname -a
Linux OpenWrt 6.6.30 #0 SMP Tue May 7 20:26:10 2024 armv7l GNU/Linux
root@OpenWrt:~# opkg list-installed | grep ath10k
ath10k-board-qca9887 - 20240220-r1
ath10k-board-qca9984 - 20240220-r1
ath10k-firmware-qca9887-ct - 2020.11.08-r1
ath10k-firmware-qca9984-ct - 2020.11.08-r1
kmod-ath10k-ct - 6.6.30.2023.06.05~fadd0768-r1
root@OpenWrt:~# iw dev
root@OpenWrt:~#
mr52_23.05.3_boot.log mr52_kernel6.6.30_boot.log
I see that "Generic PHY" is loaded twice instead of "Qualcomm Atheros AR8031/AR8033". Under investigation. @vochong Does the problem also occur with kernel 6.1?
Sorry, I never tried any image with kernel 6.1 on MR52. It's quite time-consuming to disassemble and recover MR52 via USB-TTL so I'm careful with using master images.
Images with kernel 6.6 are only available from Fri, 26 Apr 2024. Maybe you uploaded older snapshots? I could also compile these images for April 25th and make them available for testing.
I've always used 23.05.x until recently when I decided to try the latest master build on MR52. At first I thought I totally lost access to the device after upgrading to the master build (wiping out all existing config). Fortunately, I still had access to the device via Ethernet port by connecting to the PoE port (which was actually the WAN port in 23.05.x) which turns out to be the LAN port in the master image.
Same WIFI radio problem with kernel 6.1. LAN/WAN ports are also swapped in master 6.1 vs. 23.05.x
Thank you. Now at least we know that it's not a 6.6 kernel issue, but an update from 5.15 to 6.1. Please remove "(kernel 6.6)" from title.
~~Try it: mr52.zip~~ Check interface LAN/WAN order and LED order. Attach log.
No change for r26289-61e8728d86
- No Wifi detected
- LAN port is still the PoE port. As a matter of fact, the PoE port must be the WAN port by default.
FYI, the same missing WIFI issue is seen in MR42 with master images.
This is strange because I swapped eth0 and eth1 in this image in the 02_network.
@robimarko @Ansuel Please take a look
Well, its obviously an PCIe issue since none of the 3 ports have a PHY linkup at the end of configuration.
Its hard to tell what it could be, but I find it extremely weird that this device uses no PERST GPIO-s at all
Hi @robimarko,
If MR42/MR52 don't use PERST GPIO-s, any reason why they work well in 23.05.x ? Thanks.
Without having the device or somebody at least doing a bisect in OpenWrt to see which commit in master breaks stuff it's impossible to say.
It could be a kernel bug, but its extremely weird that it would somehow only affect these devices
I looked at 6.1 DWC QCOM commits and there isn't anything screaming out but as you know it could literaly be anything
@robimarko @Ansuel
I did a hard reset to the commit 9a5b1af670185f07a797920f861a6033e61c5c61 (July 23 2023) around the time ipq806x was switched to 6.1. I saw the same failures.
[ 10.897510] pcieport 0002:00:00.0: Failed to create device link (0x180) with 0-0056 [ 10.902880] pcieport 0001:00:00.0: Failed to create device link (0x180) with 0-0056 [ 10.910417] pcieport 0000:00:00.0: Failed to create device link (0x180) with 0-0056
mr42_early_kernel6.1_dmesg.log
If MR42/MR52 don't use PERST GPIO-s, any reason why they work well in 23.05.x ? Thanks.
This device uses perst-gpio on kernel 5.15. https://github.com/gregkh/linux/blob/linux-5.15.y/arch/arm/boot/dts/qcom-ipq8064.dtsi "/delete-property/ perst-gpios;" in https://github.com/openwrt/openwrt/blob/openwrt-23.05/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8068-cryptid-common.dtsi will not delete perst-gpio property.
Because the older -gpio (Not -gpios) suffix was used in the SoC DTSI but /delete-property/ perst-gpios; in OpenWrt DTS so it was not deleted as there was no such property.
And then upstream got updated in: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm/boot/dts/qcom-ipq8064.dtsi?h=v6.1.90&id=a01bae600a0d07038ec686a18604bf86452633d8
So now they are removed.
That explains it as not using PERST GPIOs made no sense, I cannot find the stock DTS to see what they are doing but I suspect that all of those PCIE deletes are incorrect and the pinctrl was being set by U-Boot thus it "worked".
Looking at the MR42 U-Boot GPL, it doesn't seem to do PCIe init at all (If my assumption that its the device with codename Storm).
This is similar to usb being broken just cause they renamed the entry upstream...
Il Gio 16 Mag 2024, 09:44 Robert Marko @.***> ha scritto:
Because the older -gpio (Not -gpios) suffix was used in the SoC DTSI but /delete-property/ perst-gpios; in OpenWrt DTS so it was not deleted as there was no such property.
And then upstream got updated in:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm/boot/dts/qcom-ipq8064.dtsi?h=v6.1.90&id=a01bae600a0d07038ec686a18604bf86452633d8
So now they are removed.
That explains it as not using PERST GPIOs made no sense, I cannot find the stock DTS to see what they are doing but I suspect that all of those PCIE deletes are incorrect
— Reply to this email directly, view it on GitHub https://github.com/openwrt/openwrt/issues/15408#issuecomment-2114296561, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2ZMQSBBDSMGJVFFFASQF3ZCRPWBAVCNFSM6AAAAABHKEWUKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJUGI4TMNJWGE . You are receiving this because you were mentioned.Message ID: @.***>
Well, in this case our downstream DTS seems that it was wrong all of the time and it worked purely by luck (Or bad copy/paste).
@vochong Can you try and remove /delete-property/ perst-gpios; from:
https://github.com/openwrt/openwrt/blob/main/target/linux/ipq806x/files-6.6/arch/arm/boot/dts/qcom/qcom-ipq8068-cryptid-common.dtsi
And then flash that?
@Ansuel Yeah, in 23.05 DTB the perst-gpio is present for all of them so no wonder it works.
No idea why they remove that on original firmware... They probably don't trust the kernel pcie driver and lease U-Boot take the init... Not the case for us. Pretty sure with the property removed the thing will start working.
@robimarko @Ansuel
Yes, I already built images and tested both MR42 and MR52 after reading the comment by @rx78gp01. WiFi works perfectly on them now. Thank you everyone for the quick solution.
@vochong What about the port order? Do the LEDs indicate the correct ports?
@namiltd
Yes, both port order and their LED's are correct after removing these /delete-property/ fields. I don't see any relationship but everything works correctly thereafter.
Another problem with mr42/mr52: https://forum.openwrt.org/t/mr42-mr52-leds/198842
I don't think we should care about the exact system LED color scheme from the original OEM firmware because we can achieve much more with WiFi radios in OpenWrt. There's no one-to-one matching.
LED Indicators and Run Dark Mode
Your MR42 is equipped with a multi-color LED light on the front of the unit to convey information about system functionality and performance:
Orange - AP is booting (permanent Orange suggests hardware issue)
Rainbow - AP is initializing/scanning
Blinking Blue - AP is upgrading
Green - AP in Gateway mode with no clients
Blue - AP in Gateway mode with clients
Blinking Orange - AP can't find uplink