No clue… You are using a totally different kernel and operating system.
I’ve been building an image for R4 from this kernel: https://github.com/ericwoud/linux/commits/mt7988-for-next-rtl/
I have added the patch for your aocclink module.
It is here: https://www.woudstra.mywire.org/images/
It runs archlinuxarm on the R4. I haven’t tested this particular kernel/image yet myself, but it should be ok.
sounds logical … but if the issue “waiting for phy” is not succeeding, how do I find out what’s missing? I tried compiling with soft and hard lockups, hung tasks etc, but that didn’t show anything. I tried top to see whether that would reveal where it was stuck, but nothing either. how can I find out at which function it gets stuck when the “detect hung tasks” doesn’t work?
You could try to debug the loop where the message is generated
As you see state is ENoDev from here:
yes, but before I’m starting to hack around in a kernel which is supposed to be stable one day or another … what are the consequences of “no phy detected”? if the impact is pretty minimal, it may simply not be worth it waiting for the phy to get detected; the link works perfectly
If no phy is detected it maybe has issues with different speeds because a phy can adapt the rate and report host system to limit data. Without phy detected you may have packet loss which needs to be resent (tcp).
@ericwoud : what am I supposed to see here?
i2cdump -y 4 0x56
do you have a i2c address specification document somewhere I could use?
Sometimes the id of the phy chip, sometimes just 0xff…
Did you try the image I prepared? It may give us some more insights…
I’d love to, do you accidentally have a tftp compatible initrd image I can fetch from u-boot? Emmc isn’t empty + I already used my sdcard for something else
EDIT: for what it’s worth:
mdio
fixed-0
i2c:sfp1
i2c:sfp2
mdio-bus
mt7530-0
r8169-1-300
r8169-1-400
root@OpenWrt:/# mdio fixed-0
DEV PHY-ID LINK
root@OpenWrt:/# mdio i2c\:sfp2
ERROR: Unable to read status (-95)
root@OpenWrt:/# mdio i2c\:sfp1
ERROR: Unable to read status (-95)
I’ll backup the emmc contents + install your image
I haven’t tried emmc on R4 myself, but should be ok.
It wouldn’t hurt to get an extra 32GB sd card for a few euros, just for some experimenting. SD installation is simpler then emmc. Get a sandisk sd card from a respectable IT store, minimizing chances it is not a fake.
To me this sounds like an invitation to end up with a fake. I would never buy microSD from any third party. I often had to, because there was no time. Went to the mall, to large consumer electronic outlets, FNAC, Worten, RadioPopular are the biggest in Portugal where I live. I’ve bought both Kingston and Sandisk high-end microSD there – and ended up with fake (vendor id: 1234, very slow, corrupted data after first time format, …) many times.
Honestly, the only thing I can recommend to everyone: Go to samsung.com and buy directly from there. Don’t even trust Amazon. It may sound crazy, but what I’ve seen is crazy, and everyone with a bit of bad luck can confirm that. Supply chains even of major consumer electronic outlets are all fundamentally broken when it comes to microSDs and pendrives, prone to be selling counterfeit goods without knowing it themselves. F**k retail.
There are many websites which do microSD forensics. It is scary what you see there.
I remember again why all 0xff at address 0x56.
Bring up the interface first, then read at 0x56.
Here you go:
i2cdump -y 4 0x56
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
10: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
20: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
30: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
40: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
50: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
60: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
70: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
80: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
90: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
a0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
b0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
c0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
d0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
e0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0 ?y???A...?.....?
f0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00 ...........?....
I ordered a few (high-speed)microsd cards. I’ll let you know when they arrive.
Was 4 the correct bus numbrr?
Yes, when I remove those sfp cages, the output is different (al xx instead of whatever hex number you may see above), i got 2 of those modules, they are at bus 3 and 4, the output does not change when inserting a RJ45 cable
EDIT looks like I was wrong. This is with a cable attached:
i2cdump -y 3 0x56
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
10: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
20: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
30: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
40: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
50: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
60: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
70: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
80: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
90: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
a0: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
b0: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
c0: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
d0: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
e0: 11 79 01 0c 0d cd 00 00 00 02 78 00 00 00 00 a0 ?y????...?x....?
f0: 00 bc 00 00 00 00 00 00 00 00 00 82 00 00 00 00 .?.........?....
Wan-sfp uses sfp1 which is channel 1 (2nd because of counting from 0) from i2c-mux and lan-sfp is sfp2 which is channel 2 (3rd).
Then these modules behave differently then the other Rollball modules…
Anything I can do for you to clarify it? Some mdio command revealing dark secrets? Waiting for the high-performance microsd stuff will take a few days
This confuses the detected numbers, is it possible the mt65xx is supposed to be AFTER the i2c muxer?
i2cdetect -l
i2c-0 i2c i2c-mt65xx I2C adapter
i2c-1 i2c i2c-mt65xx I2C adapter
i2c-2 i2c i2c-1-mux (chan_id 0) I2C adapter
i2c-3 i2c i2c-1-mux (chan_id 1) I2C adapter
i2c-4 i2c i2c-1-mux (chan_id 2) I2C adapter
i2c-5 i2c i2c-1-mux (chan_id 3) I2C adapter
If you are sure about the bus number, then there is nothing to do anymore.
I’m afraid then my patch-set is not going to work on your modules.
But you can try if the output changes, when rollball is enabled on the module, probably not.