<rmilecki>
that PHY is attached to MDIO bus available over "mediatek,mt7988-eth"
<rmilecki>
i'm wondering if there is some MDIO access detail in Ethernet driver
<Ansuel>
mhhh they also use phy_write_mmd so i don't think... maybe some mtk fixup that speedup the mdio bus are missing from upstream?
<Ansuel>
I would bench the single mmd write
<Ansuel>
OR maybe there is direct mmd read/write and we are missing that? is aqr c45 ?
<rmilecki>
AQR113C
<Ansuel>
no i mean the phy type c22 or c45 ?
<rmilecki>
how can I tell?
<rmilecki>
ah, I see _mtk_mdio_write() differs for C45
<rmilecki>
i still don't know which one is it ;)
<Ansuel>
should be written in documentation... one idea might be that the aqr phy supports special function for mmd access
<Ansuel>
and they use that instead of doing extra read/write
<Ansuel>
(for mmd you need 2 extra mdio access for every call)
<Ansuel>
aside from this the problem with dual aqr was with the probe defer? (i read the mail you sent upstream)
<rmilecki>
yes, a race
<Ansuel>
(just to make sure the loading code is O.K. and we are not missing some special regs)
<rmilecki>
with my workaround made of waiting for probe to finish, both PHYs work
<Ansuel>
good hope russel or andrew can think of solution for it
<Ansuel>
do we think we can use an hack patch while a proper solution is found?
<Ansuel>
we plan on dropping the usage of the aqr driver from ssdk
<Ansuel>
and we have the same problem on some ipq807x devices
<rmilecki>
i'm not sure how bad effects may have my hack
minimal has joined #openwrt-devel
jeff___m has quit [Remote host closed the connection]
KGB-2 has quit [reticulum.oftc.net helix.oftc.net]
h01ger has quit [reticulum.oftc.net helix.oftc.net]
[mbm] has quit [reticulum.oftc.net helix.oftc.net]
PaulFertser has quit [reticulum.oftc.net helix.oftc.net]
mark22k has quit [reticulum.oftc.net helix.oftc.net]
SwedeMike has quit [reticulum.oftc.net helix.oftc.net]
owrt-images-builds has quit [reticulum.oftc.net helix.oftc.net]
Lechu has quit [reticulum.oftc.net helix.oftc.net]
Obi-Wan has quit [reticulum.oftc.net helix.oftc.net]
lucenera has quit [reticulum.oftc.net helix.oftc.net]
\x has quit [reticulum.oftc.net helix.oftc.net]
vulpes2[m] has quit [reticulum.oftc.net helix.oftc.net]
karlp has quit [reticulum.oftc.net helix.oftc.net]
<rmilecki>
OpenWrt: [ 0.942059] mtk_soc_eth 15100000.ethernet: MDC is running on 2500000 Hz
mark22k has joined #openwrt-devel
SwedeMike has joined #openwrt-devel
Obi-Wan has joined #openwrt-devel
\x has joined #openwrt-devel
owrt-images-builds has joined #openwrt-devel
lucenera has joined #openwrt-devel
h01ger has joined #openwrt-devel
vulpes2[m] has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
[mbm] has joined #openwrt-devel
KGB-2 has joined #openwrt-devel
Lechu has joined #openwrt-devel
Obi-Wan has quit [Remote host closed the connection]
<rmilecki>
SDK: [ 1.534222] mtk_soc_eth 15100000.ethernet: MDC is running on 8333333 Hz
PaulFertser has quit [Read error: Connection reset by peer]
Lechu has quit [Quit: changing servers]
owrt-images-builds has quit [Ping timeout: 486 seconds]
vulpes2[m] has quit [Ping timeout: 486 seconds]
SwedeMike has quit [Read error: Connection reset by peer]
[mbm] has quit [Ping timeout: 484 seconds]
mark22k has quit [Ping timeout: 484 seconds]
lucenera has quit [Ping timeout: 484 seconds]
owrt-images-builds has joined #openwrt-devel
schmars[m] has quit [Ping timeout: 480 seconds]
skorpy[m] has quit [Ping timeout: 480 seconds]
Sbeach92 has quit [Ping timeout: 480 seconds]
<robimarko>
That would explain it
<Ansuel>
well as i tought... just to quote the message "maybe some mtk fixup that speedup the mdio bus are missing from upstream"
<robimarko>
On ipq807x its definitively faster in the kernel then U-Boot
<robimarko>
Though I seriously need to debug why the hell everything works perfectly if booted from initramfs
<robimarko>
And then falls apart when booting from flash
<rmilecki>
SDK does have this:
<rmilecki>
clock-frequency = <10500000>;
<Ansuel>
the mtk mdio driver needs to be checked... if nothing is there then there is probably something bad in some clock devider or mux
<rmilecki>
well, i just found it, didn't i/
<rmilecki>
I need to copy that clock-frequency to my .dts
<rmilecki>
compiling right now
<robimarko>
Ansuel: Its something due to U-Boot, because if you interrupt autoboot then it initializes networking
<robimarko>
And then it magically works
<rmilecki>
I think I noticed my PHY working once on warm reboot from SDK to OpenWrt, before I got firmware loading
<Ansuel>
yep i know... should we try to dump the entire regs of the aqr?
<Ansuel>
but you said that with the ssdk it does work correctly right?
<robimarko>
SSDK is irelevant
<robimarko>
Things it does happen way later
<robimarko>
It only tweaks the USXGMII autoneg bit, some IRQ and stuff like that
Rondom has quit [Remote host closed the connection]
<Ansuel>
thing is that afaik uboot doesn't touch the aqr phy if the boot is not interrupted
<robimarko>
Yes, indeed
<Ansuel>
so if uboot does a fix... and is skipped if boot is not interrupted... then the same fix must be done on kernel
<robimarko>
I know, but I stared at the U-Boot driver
<robimarko>
And nothing really screams out
<Ansuel>
oh so we do have uboot source?
<robimarko>
Its just a plain QSDK U-Boot
<robimarko>
That is public
<Ansuel>
my idea is that they put fixup directly in the uboot init phase
<Ansuel>
and they are specific for that device
<robimarko>
Nah, I seriously doubt that
<robimarko>
Even more so because stock FW doesnt use U-Boot to load the FW
<rmilecki>
FWIW, with OpenWrt + clock-frequency in DT: [ 0.941999] mtk_soc_eth 15100000.ethernet: MDC is running on 8333333 Hz
<Ansuel>
thank god it was that easy
<Ansuel>
robimarko remember me the device?
<robimarko>
Qnap 301W
<Ansuel>
and they didn't provide gpl tar :(
<robimarko>
I only have AX89X with AQR but that one has a SPI NOR attached so it loads the FW from it directly
<robimarko>
There is a GPL tarball
<Ansuel>
can you link so i can waste some time checking the codeflow of uboot
<robimarko>
But U-Boot is irrelevant
<Ansuel>
(of the qnap)
<robimarko>
Its not used for AQR-s in the stock FW
<Ansuel>
but it's used when boot is interrupted and then it works so maybe i can catch what they do in that codeflow
<robimarko>
They dont include u-boot in GPL tarball
<robimarko>
Even if they did it would be 99% the QSDK one
<Ansuel>
sorry if i made you repeat... this happen only on dual phy or it should happen also on my nbg?
<robimarko>
No idea, as I only have Qnap to test
<robimarko>
And it has 2 PHY-s
<robimarko>
But it should happen on a single PHY most likely
<Ansuel>
let me try...
<robimarko>
Hope it happens there as well, that would mean its a generic issue
<Ansuel>
but i remember it working
<Ansuel>
ok lol i never flashed the thing so i think i never tested it...
<robimarko>
I got bit by that as it all magically perfectly works via initramfs
<Ansuel>
better make a backup of the partition... i notice OEM are gatting fancy with making the firmware hard to download (i had to contact linksys for the mr7350 firmware)
<mrkiko>
downloaded ipq807 nbg7815 snapshot image and expected - a snapshot. Got an image with 6.1.33 kernel. Is buildbot for ipq807xsomehow broken or am I being broken ? :D
<robimarko>
Let me guess, you downloaded an image from the "ipq807x" target?
<robimarko>
It would be great if somebody who has acess can remove the ipq807x folder completey
<mrkiko>
robimarko: agreed
<mrkiko>
ynezz: maybe you can help?
<rmilecki>
Ansuel: robimarko: with faster MDIO mode I don't hit that PHY subsystem race anymore
<rmilecki>
so that's how both PHYs work with SDK
<Ansuel>
just LUCK
<rmilecki>
they use faster clock and don't hit race issue ;)
<rmilecki>
right
<robimarko>
That sounds like a proper vendor way to do it :)
<Ansuel>
imagine them overclocking the MDC just to fix the race ahahah
<Ansuel>
race present? JUST MAKE IT FASTER !!!!!!!!
<Ansuel>
robimarko maybe i manage to repro...
<mrkiko>
on the nbg7815 I have 3 phys apparently - 2 5ghz and 1 2.4 ghz. I am not able to use the "second" 5G one, trying if the first work. Wondering if they're somehow tangled to each other at this point
<mrkiko>
trying to use them in STA mode
<mrkiko>
auto-answer - no, I am doing something else wrong :)
<mrkiko>
ok, all works great :D
<Ansuel>
robimarko wth is the size of the aqr firmware for the nvmem cell...
<robimarko>
Ansuel: For me it was 0x5fc02
<robimarko>
But it depends on the actual FW for your device
<robimarko>
But the same issue was present if just loading from filesystem
<Ansuel>
0x5f42a
<Ansuel>
wasted all this time instead of dumping the damn partition... no idea they were all custom
<Ansuel>
btw looking at uboot code they write lots of regs for clock and have fun with the aqr gpio
<Ansuel>
nothing more
<Ansuel>
unless we are missing some bit to set in the provision regs
<Ansuel>
as always... full of comments with "these clk init will be moved to sbl later"
<Ansuel>
later = NEVER
<robimarko>
Well, you cant say that never is not later than now
Obi-Wan has joined #openwrt-devel
<mrkiko>
Ansuel: I have my nbg alive now, in case you need something feel free to ask
<mrkiko>
Ansuel: guess you've got the mail with flash dump - if not i can dumpanother unit
jeff___m has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
<Ansuel>
robimarko extra sanity check idea... we can check if the passed size match the one expected from the firmware
jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
DonkeyHotei has quit [Ping timeout: 480 seconds]
<Ansuel>
well nice i wasted 3 hours on the fking mbn header -.-
<jeff___m>
I am wondering if someone can help me identify why a compile error is happening. I have a modified version of the backports package with the ath12k code updated to the latest "ath12k-pending" branch. There was a recent commit that enables firmware-2.bin. It references fw_data and fw_sz to the mhi_controller struct. To add those fields, mhi.h was modified to introduce them. However when I build, I get a compile error "struct mhi_cont
<jeff___m>
roller has no member named fw_data" (and the same for fw_sz). I'm going crazy here..