mentalow has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
gch981213 has joined #openwrt-devel
mentalow has joined #openwrt-devel
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
<gch981213> jeff___m: Does the affected module come from kernel or backport? You might try patching the in-kernel version instead of backport.
skynet2 has quit [Ping timeout: 480 seconds]
<jeff___m> @gch981213: how do I tell where the module is coming from? Probably in kernel, its /include/linux/mhi.h and /drivers/bus/mhi/host/boot.c
<jeff___m> That's a good point I just assumed since those files existed in the backports package it was getting headers from there, I shall patch them in the kernel as well and try that.
<gch981213> jeff___m: A quick check is to see if the used kmod- package is defined in package/kernel/mac80211. If it's not, the module used is from the kernel.
jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
jeff___m has quit [Remote host closed the connection]
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
DonkeyHotei has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rmilecki> Ansuel: in my case PHY driver uploads 124384 B (0x1E5E0) and 247104 B (0x3C540)
<rmilecki> Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld is 393218 B (0x60002)
goliath has joined #openwrt-devel
robimarko has joined #openwrt-devel
DonkeyHotei has joined #openwrt-devel
Tapper has joined #openwrt-devel
SwedeMike has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
parazyd has joined #openwrt-devel
<Ansuel> robimarko i can totally say the -110 problem is a real PITA
<robimarko> I can agree on that
<Ansuel> rmilecki just to confirm you also suffer from the timeout error with the aquantia phy or yours works correctly?
<rmilecki> Ansuel: my board has 2 x AQR113C
<rmilecki> first one gets initialized fine
<rmilecki> second one suffers from race and I get -110
<robimarko> I have exactly the same issue with 2xAQR113C
<rmilecki> i've two working workarounds: 1. wait for completion patch 2. speed up MDIO bus
<robimarko> But even weirder, in my case it doesnt even probe the second one
<robimarko> for a long time
<Ansuel> so at least the first PHY load the firmware correctly and works?
<Ansuel> (from a correctly flashed image not initramfs)
<robimarko> It loads the FW, but then later it fails as well
<rmilecki> Ansuel: without any changes, yes, first PHY works well with upstream code
<rmilecki> oh, in my case firsr PHY seems fine
<Ansuel> we are missing some funny settings so i wonder if keeping the default values cause problem on the other aqr PHY
<Ansuel> there is one settings for MDIO broadcast that is set to 1f by default and should be changed to the PHY address (this is what is done in the firmware load)
<Ansuel> (original code)
<Ansuel> (upstream doesn't have this)
<robimarko> Is MDIO broadcast even enabled by default in the PHY
<robimarko> That should be disabled for sure
<robimarko> Any sane PHY doesnt enable it by default
<robimarko> Bit 14 in Global General Provisioning 2 enables/disables that
<Ansuel> they enable that
<robimarko> But datasheet says its disabled by default
<robimarko> I guess they are using it to load the FW on multiple PHY-s at once
<Ansuel> also after the load they sed bit 4 to 1
<Ansuel> open drain mode
<robimarko> Yeah, that is MDIO drive configuration
<robimarko> Now, it would be awesome to print that register MMD 1E, 0xC441 after U-Boot does network init
<robimarko> As then it magically works
<Ansuel> thing is that on nbg the thing doesn't even work o.O
<Ansuel> i tried to apply the same exact regs the uboot implementation does
<Ansuel> the damn thing doesn't accept the fw...
<Ansuel> (dumping the FW_ID always returns 0)
<robimarko> Reset has been disabled?
<Ansuel> you mean remove the entry in dts?
<robimarko> No, I mean has the reset GPIO been disabled?
<robimarko> AKA PHY put out of reset?
<Ansuel> yes i also made some experiment with that
<robimarko> Though you wouldnt even be able to communicate if it wasnt
<Ansuel> if it's in reset those regs returns 0xffff
<robimarko> Yeah
<robimarko> I used mdio tool to verify the reset pin
<Ansuel> we are also missing the 100ms delay for reset to complete from documentation but that is unrelated it seems
<robimarko> Then you can manually trigger it and see if it dissapears
<robimarko> 100ms?
<robimarko> That is way too much
<Ansuel> page 119
<Ansuel> 3.3 Reset
<robimarko> Where the hell did you get page 119?
<robimarko> AQR113 datasheet is only 93 pages
<Ansuel> i have a random vertical datasheet for aqr405 that is 688 page
<robimarko> AQR405 is a completey different generation
<robimarko> I guess they include registers as well in that
<Ansuel> everything matched currently
<robimarko> But yes, 100ms is the full reset time
Tapper has quit [Ping timeout: 480 seconds]
<Ansuel> starting to think there is something bad in the mdio configuration...
<robimarko> Hopefully I wrap up this U-Boot DHCP nightmare at work and can poke around again
<robimarko> Have you tried flashing the image
<robimarko> Then interrupting U-Boot and booting the flashed image from it?
<robimarko> That made it work for me
<Ansuel> btw with the delay even from initramfs you can trigger the fw load
<Ansuel> and with that it does work
<Ansuel> i guess this is something you did't try?
<Ansuel> (gpio reset should cause the firmware to be wiped correct?)
<robimarko> Hm, I guess it should
<robimarko> So, its rather a good question why it doesnt
<robimarko> I can only guess that the reset pulse is too short
<Ansuel> cause we didn't had the delay
<Ansuel> i notice this while checking what was done on gpio 63
<Ansuel> adding a debug print was enough to introduce enough delay for the PHY to correctly reset
<Ansuel> (in initramfs load)
<robimarko> Yeah, I only tried adding assert and deassert delays for the flashed image
<Ansuel> so my theory is that there is nothing wrong in the phy itself
<Ansuel> but something somewhere else... and not even gpio
<Ansuel> or maybe the gpio config?
<robimarko> I can only guess that the reset length is too short
<Ansuel> what they do in uboot is
<robimarko> And that assert delay doesnt really change the pulse length
<Ansuel> writel(0x203, aquantia_gpio_base);
<Ansuel> gpio_direction_output(aquantia_gpio, 0x0);
<Ansuel> wait 500ms
<Ansuel> and then
<Ansuel> gpio_set_value(aquantia_gpio, 0x1);
<robimarko> Yeah, that gives it a lot of time to reset
<Ansuel> writel(0x203, aquantia_gpio_base); any idea about this?
<robimarko> No idea
<Ansuel> btw the interrupt boot and manually load the thing is interesting
<robimarko> We can decode the exact bits that sets
<Ansuel> let me try
<Ansuel> it's tlmm + offset of gpio 63
<robimarko> It sets bits 0,1 and 9
<robimarko> So, that means that in_bit, out_bit and oe_bit are set
<robimarko> No idea why they need that
<Ansuel> Aquantia AQR113C 90000.mdio-1:08: FW 5.4, Build 4, Provisioning 1
<Ansuel> it's 100% something in uboot...
<Ansuel> i just tested and booting from emmc + interrupt boot works correctly
<robimarko> Yeah, for me its the same
<Ansuel> I'M VERY TEMPTED TO GET THE SPI CLIP AND DEBUG BY REMOVING STUFF FROM UBOOT AT THIS POINT -.-
<robimarko> But resets really scream out to me to look in that direction
<Ansuel> well yes can't think it's something in the clock settings (there is like 30 lines of them setting gcc clocks with all magic values)
<robimarko> Nah, its not clocks
<Ansuel> mhhh quick and dirty hack... make tlmm a syscon and write 0x203 at the thing directly
<Ansuel> i'm setting gpio directly in the tlmm regs and removing gpio property from dts... lets seee...
<Ansuel> it's strange tho... the userspace tool works correctly right?
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<robimarko> It did last time I tried which was a long time ago
<Ansuel> do you remember how to use it?
<Ansuel> guess it's this
<robimarko> Yes, that is it
<robimarko> Just start it without arguments, it will tell you the required arguments
<robimarko> But they were ethernet interface, MDIO address and the fw path
<robimarko> As it uses IOCTL-s via the ethernet interface to do MDIO
<Ansuel> ok lets see... cause it's getting impossible... I need a starting point in this
<Ansuel> Primary Iram Address: 0x0 wat ???
<Ansuel> (crc is good so image is not corrupted)
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
xback has joined #openwrt-devel
<Ansuel> robimarko aaand i discovered the bad thing... why didn't i think of it
<Ansuel> it's the same race rmileki have... just it's worse on us...
<Ansuel> on my nbg loading the fw takes at least 100 seconds
<Ansuel> and in the meantime the PHY is tried to be probed again (I assume from ssdk) and that cause problems in the fw loading
<Ansuel> One solution might be moving the fw load in the config_init
goliath has quit [Quit: SIGSEGV]
<Ansuel> for sure it seems to me mdio is very slow... as uboot load is much faster than kernel
<robimarko> Well, I didnt really count that probe and config_init can race
<robimarko> Let me check docs, but I think that MDIO bus is already running at the highest clock by default
<Ansuel> moving fw_load to config_init is enough and should make it work
<Ansuel> from what i can see it's sourced out of pcnoc_bfdcd_clk_src
<Ansuel> running at 100000000
<robimarko> Not that clock, MDIO block has a clock divider
<Ansuel> oh so it's not gcc_mdio_ahb_clk ?
<robimarko> Its configurable but I think its configured for 100MHz input by default
<robimarko> That clock feeds the divider
<Ansuel> ok then i think we are totally running mdio slower than uboot
<robimarko> But how?
<Ansuel> uboot load of iram and dram is like 5 second...
<Ansuel> on our system it's at least 60
<robimarko> Hm, that is weird, it was definitively faster for me
<robimarko> Like couple of seconds per PHY
<Ansuel> are you sure the thing actually finished loading?
<robimarko> Yes
<Ansuel> do you have the clock name?
<robimarko> gcc_mdio_ahb_clk feeds the MDIO controller
<robimarko> Its configured to run at 100MHz by the driver
<Ansuel> it's very strange that loading is this slow...
<Ansuel> problem seems similar to rmileki so i wonder if it's the same for us
<robimarko> Bits 7:0 of the MDIO_MODE_REG control the MDC divider
<Ansuel> let me check with the clk-debug script
<Ansuel> maybe the stuff from clk_summary is fake
<robimarko> Can you dump register 0x90040 from Linux?
<robimarko> That will tell us what the divider config is
<Ansuel> let me renable devmem
<Ansuel> i can also dump it from uboot in theory
<robimarko> I want to know the linux value
<Ansuel> yep just to compare it
<Ansuel> from uboot it's 0001510f
<xback> hmz. looks like GDB 14.1 causes issue. stepping through code on mips r2 is impossible
<robimarko> Ansuel: 0001510f is good for 100MHz input
<Ansuel> 0x000151FF
<Ansuel> it's different
<Ansuel> and yes changing the value while the thing is loading makes it finish much faster
f00b4r0 has quit [Quit: bbl]
<Ansuel> can confirm
<Ansuel> adding writel(0x1510f, priv->membase + 0x40);
<Ansuel> to mdio-ipq4019
<Ansuel> makes the load in just 6 seconds
<Ansuel> well yes.... qsdk reset the value
<Ansuel> mdio-qca.c line 260
<Ansuel> writel(CTRL_0_REG_DEFAULT_VALUE, am->membase + MDIO_CTRL_0_REG);
<Ansuel> do we have documentation for those magic values?
<robimarko> Yeah, I have the docs
<Ansuel> found them also online
<Ansuel> please compare
<Ansuel> only the gphy are a bit confusing
<robimarko> For 100MHz input bits 7:0 should be 8'b0000 1111
<Ansuel> and bout be good to document all the values of the devider
<Ansuel> since ipq50xx have a mode with 125mhz
<robimarko> That I dont have docs for
<Ansuel> and the thing set to 0x7
<robimarko> But I think QCA sent a patch for it
<Ansuel> wonder who sets this value...
<Ansuel> ok no interesting
<Ansuel> it's probably shit SBL
<Ansuel> cause the mdio driver in uboot sets the default value to the correct devider
<Ansuel> and I won't flash a special uboot just to debug this so we will stay with "it's the SBL"
<Ansuel> anyway would be good to know also the other values of that to make the patch more "likable" (especialy the devider values) I guess 0xf is 1
<robimarko> I know, I am busy now but I can make a table with other values that I have documented
<robimarko> Nothing sets the original value, it defaults to 0xff for the divider
<robimarko> Which means MDIO clock/256
<Ansuel> okok np can wait... in the mean time I will add all the boilerplate for the clock-frequency property support
<robimarko> Sounds good, I will make a table today
<robimarko> The fastest it goes is divide by 16
<Ansuel> thanks with this thing I think we can finally use the aquantia loader
<robimarko> Yeah, now it makes more sense
<robimarko> QCA already submited it as part of IPQ5332 series, but it can be sent separately
<Ansuel> why the hell they set the value everytime...
<Ansuel> Think I will send a different version of that
<robimarko> Because QCA
<Ansuel> like they didn't notice your driver already used to do RMW instead of raw write with a default value....
<Ansuel> hence the devider is never touched after probe :/
<robimarko> These are the values for dividers that I have documented
<robimarko> Input is always supposed to be 100MHz
<Ansuel> ok
<Ansuel> i need to check with the frequency they say are supported (in the proposed patch)
<robimarko> The /16 one matches
<robimarko> I guess MDIO worked fast enough for regular C22 and C45 read/writes
<Ansuel> i think their rule is wrong
<Ansuel> also confirmed by copilot
<robimarko> So, once again they submited incorrect stuff?
<Ansuel> if 12.5mhz comes from setting 0x7 then the devider it's * 2 resulting in SYS_CLK/((DIV + 1) * 2)
<Ansuel> as 100mhz / 16 = 12.5
<Ansuel> or actually no i'm stupid ?
<robimarko> 100MHz/16 is 6.25
<Ansuel> i think your documentation is wrong
<Ansuel> 0xf is 8 not 16
<robimarko> 0xf is the register value
<robimarko> That gets you divide by 16
<robimarko> Its not wrong
<Ansuel> ok i read 7 instead of f...
<Ansuel> sorry
<Ansuel> very fked up today...
<Ansuel> ok so every added bit is double the div... it can goes lower to 1 LOL
<Ansuel> ok i got the logic nice
<robimarko> Yeah
<Ansuel> sooo /256....
<Ansuel> 390khz
<Ansuel> ....
<Ansuel> lovely...
<robimarko> Now wonder it was "fast"
<Ansuel> do we pass a clock on ipq40xx ?
<Ansuel> or we do that only on ipq807x ?
<robimarko> Only on newer SoC-s
<Ansuel> ugh... i loved to not hardcode the thing to 100mhz
<robimarko> Its meant to run at 100MHz, ipq40xx AFAIK just has it fixed
<robimarko> There is no separate MDIO clock
Spr0cket has quit [Ping timeout: 480 seconds]
<Ansuel> ok lets see if my logic works
Slimey has quit [Remote host closed the connection]
<Ansuel> ok good works correctly...
<Ansuel> now time to prepare the patch
<robimarko> Well, FFS it was just the slow MDIO bus all this time
<robimarko> With 0xf aka 6.25MHz as the MDC clock it works fine even when booted from flash.
<robimarko> I already have a branch ready for once you add the clock config to convert Qnap including fixing the reversed reset GPIO pins
<PaulFertser> Interesting tool to interact with U-Boot. Can be used to automate many things, including dumping big images with "md". https://github.com/nccgroup/depthcharge https://depthcharge.readthedocs.io/en/latest/scripts/index.html#depthcharge-read-mem
<Ansuel> ok
<Ansuel> i'm finishing the dt part
<Ansuel> will give a last test and submit
Spr0cket has joined #openwrt-devel
<Ansuel> wonder if also ipq40xx is broken and runs that slow
goliath has joined #openwrt-devel
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (95.9% images and 100.0% packages reproducible in our current test framework.)
<Ansuel> and all works correctly tada
<Ansuel> WHAT A JOKE -.-
<Ansuel> robimarko anything to add to the include?
<Ansuel> maybe you have better meaning for the ret ret1 and gphy bits?
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
soxrok2212 has quit [Read error: Connection reset by peer]
dangole has quit [Ping timeout: 480 seconds]
<robimarko> Ansuel: I would just drop MDIO_MODE_RES1, MDIO_MODE_GENPHY and MDIO_MODE_RES
<robimarko> They are all marked as reserved and shouldnt be touched anyway
<robimarko> Also, for the DTS change, its not 62.5MHz but 6.25MHz
<robimarko> Also, why do you need new compatibles?
<Ansuel> discrepancy between schema and actual driver
<Ansuel> the current dtsi have 2 compatible in the mdio node
<robimarko> And that is fine
<robimarko> So in case there is really a need to differentiate between ipq8074 and the default ipq4019 you can do it
<Ansuel> ok
<Ansuel> sad for the res res1 and genphy but if they are reserved that's fine by me
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
dangole_ has quit [Ping timeout: 480 seconds]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<robimarko> LGTM
robimarko has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
jeff___m has joined #openwrt-devel
jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
Grommish has joined #openwrt-devel
<Grommish> Well well well.. Howdy Folks
<Grommish> What's shakin'?
Slimey has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
gch981213 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Grommish has joined #openwrt-devel
rua has quit [Quit: Leaving.]
jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
Grommish has quit [Quit: No Ping reply in 180 seconds.]
jeff___m has quit [Ping timeout: 480 seconds]
Grommish has joined #openwrt-devel
DonkeyHotei has quit [Ping timeout: 480 seconds]
Grommish has quit [Quit: No Ping reply in 180 seconds.]
Grommish has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]