dansan has joined #openwrt-devel
jeff___m 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.)
parazyd has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
skynet2 has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
gch981213 has joined #openwrt-devel
gch981213 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
gch981213 has joined #openwrt-devel
torv is now known as Guest14814
torv has joined #openwrt-devel
Guest14814 has quit [Ping timeout: 480 seconds]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
jeff___m has quit [Remote host closed the connection]
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
jeff___m has joined #openwrt-devel
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
f00b4r0 has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
<mrkiko> Ok, definitely worrysome situation with Belking RT3200
<mrkiko> Wondering if my units boot again
robimarko has joined #openwrt-devel
<rmilecki> robimarko: Ansuel: i've a new problem:
<rmilecki> [ 27.209194] Aquantia AQR113C mdio-bus:08: aqr107_wait_reset_complete failed: -110
<rmilecki> it comes from aqr107_config_init()
<rmilecki> the most common reason for that error is missing firmware (not running)
<robimarko> That error means that the PHY is not ready
<rmilecki> it's the same case here BUT the difference is why firmware is not running
<rmilecki> in my case aqr107_config_init() was called BEFORE aqr107_probe() return
<rmilecki> is there some race in PHY subsystem?
<robimarko> Are you trying initramfs or flashed image?
<rmilecki> flashed
<robimarko> I have a similar issue when flashed
<robimarko> When initramfs is booted it all works fine
<robimarko> But flashed one of my 2 AQR-s is not found
<robimarko> And the other returns -110
<rmilecki> uh, so more debugging ;)
<robimarko> I have been scratching my head for a while against that
<robimarko> But havent got time to properly debug it
cation has joined #openwrt-devel
<rmilecki> i think it's a matter of how much time it takes to load aquantia firmware
<rmilecki> probing first PHY takes quite some time but it still happens before probing Ethernet driver/hardware
<rmilecki> now, probing 2nd Ethernet core hpapens during probing 2nd aquantia PHY
<rmilecki> and that seems like a problem
<robimarko> I am having a probing race or something as well
<robimarko> Cause, in my case the second AQR is not even identified as AQR
<robimarko> It only gets identified way later
<robimarko> Its all somehow racing
<robimarko> Ansuel: Any chance you can review the ipq60xx PR from 8dev?
goliath has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
torv has quit [Quit: torv]
torv has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<Ansuel> robimarko looking at the mtk code i notice there is some comments for gangload and daisychain
<Ansuel> i wonder if our problem is exactly that
rua has joined #openwrt-devel
<Ansuel> maybe the problem is present only with case where we have more than one aquantia phy ?
<Ansuel> for ipq60xx i recently received a router with that so i can also test it but what is the current state of it? I remember there were still some thing to polish ?
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<robimarko> Ansuel: Those are for when you have AQR-s connected to one another
<robimarko> Ansuel: There is still stuff to polish but the PR in its state is usable
<Ansuel> btw random idea is there some regs to check the version of the tz fw?
<robimarko> Ansuel: You can get the TZ FW string via SMEM
<robimarko> But that can happen only way later
<Ansuel> loved if psci: dont advertise OSI support for IPQ6018 could have some better handling (what did they say upstream?)
<robimarko> I did not submit it upstream as its really not upstreamable
<robimarko> Only way would be to add a new DT property to advertise the quirk
<Ansuel> yes was thinking just about that
<robimarko> I see the 8devices PR as a good starting point for now
<robimarko> There is stuff missing for sure, I only gave it one round of reviews
<robimarko> Mantas found the missing clock so that avoids the whole mess of including dozens of clocks just to get wifi working
<robimarko> And he fixed the USB3 port
<Ansuel> yep yep just asserting the situation
<robimarko> He finally pushed me to start working on the SoC
<Ansuel> what i currently hate is the fact that the wifi fw still crash... that is really strange
<Ansuel> (with the new fw versions)
<robimarko> Yeah, I agree
<Ansuel> we should really check if that happens with a qsdk mac80211
<robimarko> Though we are completely missing the 2.9 FW series for it
<robimarko> 2.6 and 2.7 were broken on ipq807x as well
<Ansuel> mhhh the problem was with BDF right?
<Ansuel> or I'm wrong?
skynet2 has joined #openwrt-devel
<robimarko> We dont know, as 2.9 magically worked again
<Ansuel> well I remeber 2.6 and 2.7 working only on qnap
<Ansuel> with other legacy device being broken
<Ansuel> do you have by chance a dts for for the linksys mr7350 ?
<Ansuel> we should be able to check for fw support by testing if an upstream BDF works with the new fw
<robimarko> AX6 was completely broken before 2.9
<Ansuel> let me do some comparison maybe the same problem with ipq807x is also present on ipq60xx
<Ansuel> for sure them not publishing fw for 2 years is very bad... maybe us adding support in openwrt will change things up ?
<robimarko> I hope it does, cause QSDK FW for IPQ807x and IPQ60xx is pretty much the same
<robimarko> They always have the same versions
<robimarko> No idea why they dont update the public versions for IPQ60xx
<Ansuel> I will try to send a mail to kavlo
<Ansuel> interesting is that i have a gl-axt1800 that reported to correctly work with 2.7
<Ansuel> after some fixup
<Ansuel> but his crash was with ailed to extract regulatory info from received event
<robimarko> That basically means that BDF has no regulatory info
<Ansuel> well i really need to check this... would be ideal to use 2.7 and just fix the BDF
<robimarko> I actually have the 8devices Mango DVK
<robimarko> So, I will eventually try it on the device
<Ansuel> last question do you have the serial pinout of the linksys?
<Ansuel> curious what the other pins are used (unpopulated on my board)
<robimarko> That should be JTAG (If you are talking about the dual row header)
rua has quit [Quit: Leaving.]
<Ansuel> btw at the end i manage to find the cause for the arm decompressor and it seems upstream they liked the fix
<robimarko> That is great to hear, what is the idea?
<Ansuel> with DTB_COMPAT mem_start call to validate (and fix the address) is skipped as it could be augumented by ATAGs but it was never called again
<Ansuel> resulting in ignoring completely the memory node data in the appended DTB
<Ansuel> with this and a less drastic patch to ignore MEM ATAGs AUTO_Z can work correctly and the data from DTB is used
<robimarko> That is great to hear
<robimarko> Oh boy, our QCA friends are again trying to upstream networking related drivers: https://patchwork.kernel.org/project/netdevbpf/cover/TYZPR01MB55563BD6A2B78402E4BB44D4C9762@TYZPR01MB5556.apcprd01.prod.exchangelabs.com/
<robimarko> None of the commits have description
<robimarko> Though the code actually looks OK
<Ansuel> been like 4 email i'm sending to lui offering for help... they always answer with "We will review internally"
<Ansuel> small details that net-next is closed (or isn't?)
<robimarko> Its closed
<Ansuel> they will get angry again i guess
<robimarko> Think they open tommorow, but lack of commit messages is no go
<robimarko> But with this series, IPQ5018 is basically usable and has better networking driver than anything
<Ansuel> finally... i have to send the last 3 series for at803x so we can finally detach everything from ssdk (aside from aqr)
<robimarko> Perfect
<Ansuel> btw they said they will "consider" working on an upstream version of EDMAv1
<robimarko> Sure, I will hold my breath for it
<Ansuel> after EDMAv2 is upstream
<robimarko> Look at the IPQ807x UNIPHY diagram
<Ansuel> oh!
<Ansuel> yep was the first thing i notice
<Ansuel> more stuff to detach from ssdk
<robimarko> One day
<Ansuel> they added only ipq50xx stuff
<Ansuel> am i wrong...
<robimarko> Yeah, only ipq50xx
<Ansuel> also ipq60xx is the same ?
<robimarko> ipq60xx is basically the same uniphy as ipq807x
<robimarko> Minus the
<robimarko> *Minus the UNIPHY2
<mrkiko> and is there a plan by them tocatc up for the lost performance with nss in the whole plan? Or am I missing something here?
<robimarko> And the UNIPHY1 is SGMII+ max, no 10G
<Ansuel> mrkiko nope... their plan with new ipq95xx was trash nss and move to correct PPE
<robimarko> mrkiko: Nothing can replace that perfmormance, but we are finally seeing some upstreaming of basic wired networking components here
<mrkiko> thanks. Very nice. I wouldn't have expected to see this happening.
rua has joined #openwrt-devel
<robimarko> Ansuel: Well, QCA geniouses made the UNIPHY driver stupid
<robimarko> They just hardcode values in the DTS
<Ansuel> ???
<robimarko> It is not aware of the required MAC mode
<robimarko> So, the frequency is just hardcoded in the DTS
<robimarko> So, its not suitable for on the fly MAC mode changes like for example happens when AQR-s are used
<Ansuel> ...
<Ansuel> maybe they want to expand it later?
jeff___m has joined #openwrt-devel
<robimarko> Doubt that, it would make sense to do it now
<robimarko> But that would require wiring the driver into phylink as a proper PCS one
<Ansuel> oh no!
<robimarko> What happened?
<Ansuel> no i mean it way too much work
<robimarko> It shouldnt be as there are existing PCS drivers doing exactly that
<Ansuel> CBT U-Boot ver: 2.3.01 ([IPQ6018].[SPF11.CSU1].[code version])
<Ansuel> very new uboot feel strange
<robimarko> Whats strange, it hasnt really changed functionally in ages
<robimarko> I am using SPF12.0 CSU1 for a board we support, had to enable lots of things to make it usable
<robimarko> U-Boot without long help is so weird
<Ansuel> mhhh should i flash the image on the mr?
<robimarko> It should work, but I havent tested it
jeff___m has quit [Ping timeout: 480 seconds]
<Ansuel> Unknown command 'tftpboot' - try 'help' .... usual linksys
<robimarko> Use dhcp
<Ansuel> nha for some reason they always rename tftpboot with tftp
<Ansuel> can confirm the image works
<robimarko> There is one thing missing from the PR, CPUFreq NVMEM needs to be backported
<Ansuel> mhhh maybe we can for now polish it a bit and set is as disabled to suspend buildbot image generation
<robimarko> Yes, I would just clean the obviously wrong things
<robimarko> And merge it marked as source
<robimarko> Then we can add couple of boards and fixup things along the way
<robimarko> And then its easy to remove the source marking
<robimarko> Otherwise it will drag on for a while
<robimarko> I have couple of boards and there will be a good number of users
<Ansuel> Wrong Image Format for bootm command
<Ansuel> ERROR: can't get kernel image!
<Ansuel> MHHH
<Ansuel> (treid sysupgrade from initramfs)
<robimarko> Honestly, no idea if sysupgrade was even wired properly
<robimarko> rmilecki: any news on the u-boot env parser being able to parse MAC-s from custom cell names?
<Ansuel> ubimkvol: error!: UBI device does not have free logical eraseblocks
<robimarko> Check with ubinfo
<robimarko> Linksys probably has QSDK UBI volumes that are not removed by default
<Ansuel> guess some fixup are needed in sysupgrad
<robimarko> If its just UBI volumes, you can find examples of doing that
<robimarko> Like I said, havent tried flashing as it was just a dev device
<Ansuel> btw news for the rootfs options thing?
<robimarko> I rebased my stuff, but havent retested
<robimarko> Its been on the TODO list for a while
<Ansuel> boot_part=2 nice same dual partition way
<Ansuel> [e]Failed to get erase block status
<Ansuel> MHHHHHHHHHHHHHHHHH
mentalow has quit [Quit: :]]
mentalow has joined #openwrt-devel
<Ansuel> well kernel partition is 8mb....
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<Ansuel> robimarko do you have the BDF ?
<Ansuel> with the upstream one it seems to work
<Ansuel> ok no actually it crashed bad on me connecting to it
<Ansuel> NOC_error.c:474 NOCError: FATAL ERRORparam0 :zero, param1 :zero, param2 :zero.
jeff___m has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
jeff___m has joined #openwrt-devel
<Ansuel> ok it doesn't seems to be a problem with BDF
<Ansuel> but more or instability?
<Ansuel> more of*
jeff___m has quit [Ping timeout: 480 seconds]
jeff___m has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
jeff___m has joined #openwrt-devel
<robimarko> I did not want to submit it until it was all working
<Ansuel> well from what i can see 2.7 crash sure but correctly recovers
<Ansuel> the BDF works correctly
<Ansuel> I also sent a mail to kalle
<robimarko> Great
<Ansuel> I'm temted to merge patches and ess dtsi to have the ball rolling for ipq60xx
<Ansuel> but no device or anything
<robimarko> I am fine with that, but I would drop all of the placeholder scripts he included
<robimarko> I think I even commented regarding that
<robimarko> Those should be added as the devices need them
<Ansuel> for sure i have to edit some commits have to see
<robimarko> I am all for adding the target, we can then fixup individual compoments easily
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
robimarko has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
jeff___m has quit [Remote host closed the connection]
skynet2 has quit [Quit: Leaving]
skynet2 has joined #openwrt-devel
gch981213 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
goliath has quit [Quit: SIGSEGV]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
gch981213 has joined #openwrt-devel