I am reading the comments of the 5.15 PR and Ansuel said there is something going on with PPPoE. Maybe I am experiencing that?
Well, it actually can be that as I did not try PPoE
Maybe a test with fw4 and without the kernel change revert would makes sense?
If you tell me how to swap fw3 to fw4, I will give it a try.
Basic support is already there and:
"https://github.com/openwrt/openwrt/pull/4642#issuecomment-980477493"
There are 4 commits for firewall4 in stintels staging tree + the mentioned luci feed.
And after that switch in menuconfig from firewall to firewall4
I'm also trying to build this.....
2 Likes
I’m just lurking around and waiting 
but my understanding is even with 5.15 there is no ax support right? Only ac?
It’s there any other features missing from the stock firmware? How about mesh?
AX support is there for a long time. Read the thread more carefully. Mesh as well.
Thanks for the quick response. I just saw a post from 5 days ago about ax. Great news that everything coming together
Great I will wait until the new 5.15 branch is a little bit matured to do the switch
@robimarko
On the AX9000 switch/ssdk is not working:
2.221382] mdio_bus 90000.mdio-1: MDIO device at address 0 is missing.
[ 2.225485] mdio_bus 90000.mdio-1: MDIO device at address 1 is missing.
[ 2.231801] mdio_bus 90000.mdio-1: MDIO device at address 2 is missing.
[ 2.238411] mdio_bus 90000.mdio-1: MDIO device at address 3 is missing.
9.961270] ssdk_phy_driver_init[327]:INFO:dev_id = 0, phy_adress = 0, phy_id = 0xffffffff phytype doesn't match
[ 9.964474] ssdk_phy_driver_init[327]:INFO:dev_id = 0, phy_adress = 1, phy_id = 0xffffffff phytype doesn't match
[ 9.974606] ssdk_phy_driver_init[327]:INFO:dev_id = 0, phy_adress = 2, phy_id = 0xffffffff phytype doesn't match
[ 9.984784] ssdk_phy_driver_init[327]:INFO:dev_id = 0, phy_adress = 3, phy_id = 0xffffffff phytype doesn't match
9.994933] qca808x_phy_api_ops_init[2208]:INFO:qca probe qca808x phy driver succeeded!
Only the qca8081 is recognized.
Do have an idea?
On what branch?
Cause I have been testing on the AX9000 the 5.15 branch and all PHY-s work fine
1 Like
5.15, strange.
I'll do a git reset and build again.
Then its really strange, even used it today to see whats going on with FW3
I just switched to fw4, but that's can't be be reason.
No, that's not the cause for sure
It's getting more weird. If running from initramfs all of the phy's working, but not if running from flash (I've also ubiformated both of the rootfs partitions with the factory.ubi)
We already had this problem for the qca8081, maybe it's again caused by the resets?
But why is it not happen on your ax9000?
Hmm, I also just tried initramfs, not as it should matter.
I will try flashing
1 Like
Testing a build from your ipq807x-5.15 branch, thanks for all the hard work.
Saw this warning in dmesg that I hadn't seen on previous builds:
[ 1.144397] nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xaa
[ 1.145959] nand: ESMT GD9FS2G8F2A
[ 1.152565] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 1.156011] 16 qcomsmem partitions found on MTD device qcom_nand.0
[ 1.163330] Creating 16 MTD partitions on "qcom_nand.0":
[ 1.169578] 0x000000000000-0x000000100000 : "0:sbl1"
[ 1.176079] mtdblock: MTD device '0:sbl1' is NAND, please consider using UBI block devices instead.
[ 1.180168] 0x000000100000-0x000000200000 : "0:mibib"
[ 1.189782] mtdblock: MTD device '0:mibib' is NAND, please consider using UBI block devices instead.
[ 1.194084] 0x000000200000-0x000000500000 : "0:qsee"
[ 1.205707] mtdblock: MTD device '0:qsee' is NAND, please consider using UBI block devices instead.
[ 1.208231] 0x000000500000-0x000000580000 : "0:devcfg"
[ 1.217541] mtdblock: MTD device '0:devcfg' is NAND, please consider using UBI block devices instead.
[ 1.222234] 0x000000580000-0x000000600000 : "0:rpm"
[ 1.232011] mtdblock: MTD device '0:rpm' is NAND, please consider using UBI block devices instead.
[ 1.236191] 0x000000600000-0x000000680000 : "0:cdt"
[ 1.245755] mtdblock: MTD device '0:cdt' is NAND, please consider using UBI block devices instead.
[ 1.250016] 0x000000680000-0x000000700000 : "0:appsblenv"
[ 1.259520] mtdblock: MTD device '0:appsblenv' is NAND, please consider using UBI block devices instead.
[ 1.264491] 0x000000700000-0x000000800000 : "0:appsbl"
[ 1.274936] mtdblock: MTD device '0:appsbl' is NAND, please consider using UBI block devices instead.
[ 1.279008] 0x000000800000-0x000000880000 : "0:art"
[ 1.288783] mtdblock: MTD device '0:art' is NAND, please consider using UBI block devices instead.
[ 1.292994] 0x000000880000-0x000000900000 : "bdata"
[ 1.302499] mtdblock: MTD device 'bdata' is NAND, please consider using UBI block devices instead.
[ 1.306777] 0x000000900000-0x000000980000 : "crash"
[ 1.316313] mtdblock: MTD device 'crash' is NAND, please consider using UBI block devices instead.
[ 1.320594] 0x000000980000-0x000000a00000 : "crash_syslog"
[ 1.330107] mtdblock: MTD device 'crash_syslog' is NAND, please consider using UBI block devices instead.
[ 1.335063] 0x000000a00000-0x000002dc0000 : "rootfs"
[ 1.348885] random: fast init done
[ 1.372780] mtdblock: MTD device 'rootfs' is NAND, please consider using UBI block devices instead.
[ 1.372942] mtd: device 12 (rootfs) set to be root filesystem
[ 1.380899] mtdsplit: no squashfs found in "rootfs"
[ 1.386543] 0x000002dc0000-0x000005180000 : "rootfs_1"
[ 1.418672] mtdblock: MTD device 'rootfs_1' is NAND, please consider using UBI block devices instead.
[ 1.418848] 0x000005180000-0x000007040000 : "overlay"
[ 1.450515] mtdblock: MTD device 'overlay' is NAND, please consider using UBI block devices instead.
[ 1.450707] 0x000007040000-0x0000070c0000 : "rsvd0"
[ 1.459353] mtdblock: MTD device 'rsvd0' is NAND, please consider using UBI block devices instead.
1 Like
Thats fine, they added that as soon as anything other than UBI is used on NAND
2 Likes
Hi robimarko,
I think the mdio config is wrong. The reset should be a property of the mdio node, not of the ethernet-phy:
ethernet-phy@0 {
reg = <0>;
reset-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>;
reset-deassert-us = <2000>;
};
I've moved the reset back to the mdio and removed the reset delay as well and then all of the qca8075 phy's are working again.
Is there just a single reset GPIO?
Cause if so, then it should be the MDIO property but if there is more than one then it should be the property of the PHY.
But the trick then is that you must declare the PHY compatible so the PHY subsystem starts probing it and then it will dessert the reset, that is why it's not working.
What's the board, AX9000 or?