<Ansuel> MH?
<mangix> I assume that commit has to do with the switch or ethernet driver having special support
<mangix> Hmm this is shown in Documentation/networking/sfp-phylink.rst
<Ansuel> anyway is it late for you? do you have a device with 2 cpu port?
<mangix> my archer does
<mangix> it's 17:00 here
<Ansuel> Want to test a patch? the target is test if everything work with only port6 declared
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
<mangix> sure
<Ansuel> BTW 2:30 am here ahahah
dangole has quit [Remote host closed the connection]
eck has joined #openwrt-devel
dangole has joined #openwrt-devel
<mangix> that commit is probably not applicable here. I assume the ethernet driver needs phylink support
<mangix> only the upstream driver has that
<mangix> or backport the phylink conversion
<Ansuel> almost done need to check if i missed some changes
<Ansuel> mangix: patch ready where should i send them ?
<Ansuel> gist?
<Ansuel> you should replace patch from 05 (so leave the phy patches as they are not included in this series)
<Ansuel> binding changes falling moved to phy node and enable pll
<mangix> OK
<mangix> alright, building. commented out port 0
<Ansuel> nice!
<Ansuel> i also made a patch to apply internal delay for sgmii
<mangix> meh failed
<Ansuel> do you remember where you read the user reporting port instability?
<Ansuel> the error is?
<mangix> failed patch
<mangix> guess I did something wrong
<Ansuel> post error pls
<Ansuel> let me check if we have the same code for qca8k in 5.10
<Ansuel> mhhh think you removed too much patch ?
<Ansuel> you replaced 781 correct?
<mangix> just 0005 and later
<Ansuel> actually no remove every 781 from 1 to 9
<mangix> and replace with these?
<Ansuel> yep
<mangix> even worse
<Ansuel> ...
<mangix> I have linux cloned on this computer. I could try git am
<Ansuel> trying to compile an image on my buildroot
<mangix> error: patch failed: drivers/net/phy/at803x.c:142 . of course it fails. why would it succeed
<Ansuel> mhh on my side it does compile correctly
<Ansuel> just to make sure you have the qca8k pr backport
<Ansuel> and removed 781 patch and put mine in the pending directory
<Ansuel> correct?
<mangix> right
<mangix> maybe I have an older version of clayface's qca8k PR
<Ansuel> could be that you have some extra patch in the dir
<mangix> nope. at least git it not saying so.
<mangix> oh
<Ansuel> can you give me output of git added files? or private stuff ?
<Ansuel> ??
<mangix> I have your LED patch as well
<Ansuel> try to drop it
<Ansuel> also the multipatch
<mangix> multicpu DSA? I don't have that
<Ansuel> ok
<mangix> same error
<mangix> I'll try getting everything backported to my linux clone and try that.
<Ansuel> did hauke really finished the 5.13 backport o.o wow
<Ansuel> he is crazy ahahaha
<Ansuel> wonder if you are missing some backport patches
<mangix> possiblwe
<Ansuel> i mean if we really want to go the hack way we can consider replacing the qca8k.c and .h file ahaha
<Ansuel> quick and dirty
Ansuel_ has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<Ansuel_> i mean with my r7800 and the current patchset all works
<russell--> still seeing: netlink: 'iw': attribute type 302 has an invalid length.
<mangix> cherry-pick d7805757c75c76e9518fc1023a29f0c4eed5b581 fails
<mangix> hahahahaha
* Ansuel_ is uploading qca8k.c and qca8k.h to gist
Ansuel has quit [Ping timeout: 480 seconds]
<mangix> yes indeed
<mangix> I am missing backports
<mangix> from net: dsa: qca8k: pass switch_revision info to phy dev_flags and up it seems
<Ansuel_> how is possible that you don't have that
<mangix> I actually do.
<mangix> was listing just the 1* patches
<mangix> anyway, I have all the backports
<Ansuel_> and still error o.O
<mangix> no idea
<mangix> maybe I'll redo the backports
rua has joined #openwrt-devel
<Ansuel_> i mean for now you can consider removing the extra patch and replace the file directly in the build dir
<Ansuel_> that will also work for a quick test
<mangix> Applying: drivers: net: dsa: qca8k: add support for cpu port 6 <-- fails against linux-next and master
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<mangix> yeah same error
<Ansuel_> mhh can you give me the patch you have so i can compare them to mine ? it's too strange that i compiled an image correctly
Ansuel_ has quit [Quit: Probably my PC crashed or time to sleep.]
Ansuel has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
<mangix> maybe I am missing a backport
<mangix> there's no qca8k_setup_mac_pwr_sel
<Ansuel> but that is part of addition and is implemented by the new patch
<mangix> same error
<mangix> removed all 781 patches and cp 907ac4b51923c006693011a088cb7231-1d6981cc4bfce24ec25280061f07d27d7a7f73c8/* target/linux/generic/pending-5.10/
<mangix> v3-0003-drivers-net-dsa-qca8k-add-support-for-cpu-port-6.patch also has fuzz
Ansuel_ has joined #openwrt-devel
<Ansuel_> Applying /home/ansuel/openwrt/target/linux/generic/pending-5.10/v3-0004-drivers-net-dsa-qca8k-add-support-for-cpu-port-6.patch using plaintext:
<Ansuel_> patching file drivers/net/dsa/qca8k.h
<Ansuel_> patching file drivers/net/dsa/qca8k.c
<Ansuel_> no fuzz for me
<Ansuel_> but i admit that it could be i have old patches
<mangix> yeah you do
<mangix> I just checked why they're failing with my linux clone
<mangix> fuzz is because of return 0 vs return ret;
<mangix> also, qca8k_setup_mac_pwr_sel is not present in qca8k_setup
<mangix> hence it fails to apply
<Ansuel_> but qca8k_setup_mac_pwr_sel is added by v3-0001
<Ansuel_> god damn....
<mangix> nope
<mangix> now it fails at patch 8
Ansuel has quit [Ping timeout: 480 seconds]
<mangix> compiling now
<Namidairo> give up on ipq807x already? :P
<mangix> Ansuel: so either it's not working or ath8216 needs to give up first. I think it's not working.
<mangix> I lied
<mangix> it's working
<mangix> same iperf speed looks like
<mangix> maybe a little faster
<mangix> no that wouldn't make sense
<mangix> port6 is eth0. DSA probably uses that by default since no multicpy
<mangix> *cpu
<mangix> wonder if I should open this router again...
Ansuel_ has quit [Ping timeout: 480 seconds]
clayface has joined #openwrt-devel
clayface_ has quit [Ping timeout: 480 seconds]
dangole_ has quit [Ping timeout: 480 seconds]
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
Tapper has joined #openwrt-devel
rua has quit [Quit: Leaving.]
myon98 has joined #openwrt-devel
Ansuel has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rsalvaterra> mangix: I have a WDR3600, yes.
<rsalvaterra> Why am I here on a Sunday before 8 AM…?
* rsalvaterra goes back to sleep
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
goliath has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<aparcar[m]> rsalvaterra: ideas about this sdk crypto dev issue?
<aparcar[m]> mangix: ^^
hanetzer has quit [Ping timeout: 480 seconds]
noltari_ has joined #openwrt-devel
noltari has quit [Remote host closed the connection]
noltari has joined #openwrt-devel
noltari_ has quit [Read error: Connection reset by peer]
noltari has quit [Read error: No route to host]
noltari has joined #openwrt-devel
titanous has quit [Remote host closed the connection]
hubvu has quit [Remote host closed the connection]
Vaughn has quit [Remote host closed the connection]
zx2c4 has quit [Read error: Connection reset by peer]
noltari has quit [Read error: No route to host]
titanous has joined #openwrt-devel
noltari has joined #openwrt-devel
hubvu has joined #openwrt-devel
Vaughn has joined #openwrt-devel
zx2c4 has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
hanetzer has joined #openwrt-devel
zx2c4 has quit [Ping timeout: 480 seconds]
titanous has quit [Ping timeout: 480 seconds]
hubvu has quit [Ping timeout: 480 seconds]
Vaughn has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
<hanetzer> bleh, finally getting around to updating the fleet of APs to 21.02.0
Vaughn has joined #openwrt-devel
titanous has joined #openwrt-devel
zx2c4 has joined #openwrt-devel
hubvu has joined #openwrt-devel
Ansuel has joined #openwrt-devel
victhor has joined #openwrt-devel
<Ansuel> mangix: don't know if you are here. Anyway any idea if we have qca8327 with mac exhcnage? i'm finding many device that are uncorrectly reported with qca8327 but they are qca8337 example the archer c7 v4 and v5
<Ansuel> we just notice mac exchange is reserved on qca8327 and we assume they just hided the bit... what if it's just not supported?
<hanetzer> question. I have a pair of ubiquiti nanobeam m5's to bridge a network to some buildings across the street. they're 8/64 devices (not ideal, I know), using the legacy ar71xx target. would a port to ath79/tiny be accepted? don't wanna do the work if its for nothing :)
<hauke> hanetzer: I do not know the device but 8/64 is no problem for ath79
<hanetzer> hauke: ah yeah. looking at ar71xx at the last commit before it was nuked shows it to be a 'generic' device, so should be no issue.
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
<hanetzer> on another note, my company is soon to be moving to a new locationand we're thinking to upgrade our wireless setup (currently a handfull of meraki mr24's). Any suggestions as to modern devices which fill a similar niche?
<Namidairo> ask your aruba/ruckus/meraki/ubiquiti/`insert enterprise wifi vendor here` sales rep?
goliath has joined #openwrt-devel
<hanetzer> I don't have one :D
<hanetzer> we're just a homeless shelter :P
Ansuel has quit [Ping timeout: 480 seconds]
* Slimey throws hanetzer to Ronald MacDonald
<hanetzer> eww
<hanetzer> howya doin friendo
<Slimey> good and yourself
RoadDv has joined #openwrt-devel
<hanetzer> pretty good, just updated like 10 meraki mr24's to the new release :)
<RoadDv> I'm busy trying to fix up https://github.com/tmn505/openwrt-dvb v4l-dvb package. I've come to the point where the package is compiled, but the kernel configuration is not. In it's current state, each of the kernel package directives have variable V4L_KCONFIG, which to the best of my knowledge is just ignored. Instead the package just generates a default .config file. The problem is, I'm not sure what would be the best way to gather all the V4L_KCON
<RoadDv> at the end I would like to do something like `$(file >$(PKG_BUILD_DIR)/v4l/.config) $(foreach C,$(V4L_KCONFIG),$(file >>$(PKG_BUILD_DIR)/v4l/.config,$C))` which should fix it
<RoadDv> Any pointers on ideas? I've been trying to read through the makefiles but there is just a lot going on
<hanetzer> *idea sorry, bad programmer joke :)
dangole_ has joined #openwrt-devel
<Slimey> hanetzer nicccccccce
<Slimey> heh thats part of my problem i bet "OpenWrt switched [1] their MAC address (from flash) retrieval code from their mtd-mac-address based solution [2] to nvmem-cells."
<Slimey> my old dts file uses the later
Ansuel has joined #openwrt-devel
<Slimey> yay lets see if it isn't screwed up when completed
Ansuel has quit [Read error: Connection reset by peer]
Ansuel has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Acinonyx_ has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<dangole_> looks like python/host somehow broke on the buildbot: https://buildbot.openwrt.org/master/packages/#/builders/18/builds/196/steps/24/logs/stdio
rejoicetreat has quit [Remote host closed the connection]
rua has joined #openwrt-devel
RoadDv has quit [Remote host closed the connection]
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
dangole_ has quit [Ping timeout: 480 seconds]
clayface_ has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
RoadDv has joined #openwrt-devel
<mangix> aparcar[m]: I do not. Now if you could merge this:
Ansuel has quit [Quit: Probably my PC crashed or time to sleep.]
Ansuel has joined #openwrt-devel
<Ansuel> and reviewer are starting to argue each other FK.... every time ahahahah anyway mangix I know i'm beeing annyoing but when you want and have time do you want to test v4? we really need to understand if qca8327 can work with cpu port6 defined and with cpu port0 commented
<Ansuel> also do we have a device with qca8327 that has mac exchange? it seems is not supported on that switch
<mangix> rsalvaterra does
<mangix> AFAIK
<mangix> Hmm? What changed with v4?
<Ansuel> i checked the device in ath79 and everyone have a uncorrect switch in the wiki
<Ansuel> they are actually all qca8337
<Ansuel> i fixed a typo where the phy id was read instead of the switch id
<Ansuel> it caused problem with sgmii
<mangix> Uhhh, there's no way the 3600 is qca8337
<Ansuel> what dtsi use wdr3600 ?
<Ansuel> i didn't remember it has mac96 exchange
<Ansuel> 06*
<mangix> Same as 4300
<Ansuel> ar9344_tplink_tl-wdr4300.dtsi no mac06 exchange
<mangix> ohhhhhhhh. I was thinking about open drain. NVM.
<Ansuel> current revision is about the exchange mess we will see how it goes for led drain ahahah
<Ansuel> if you want i can give you v4
<mangix> Pretty old stuff uses mac6-exchange
<Ansuel> itecom_wlr-7100.dts qca8337
<Ansuel> sitecom_wlr-8100.dts same
<Ansuel> tplink_archer-c7-v4.dts same
<Ansuel> tplink_archer-x7-v5.dtsi didn't check the others but i think we can assume they have wrong info in the wiki
<Ansuel> exchange bit is reserved in qca8327 and device that use it are only qca8337 so...
<Ansuel> didn't check the other tho as finding internal photo is hard
<mangix> No way.
<Habbie> didn't read all, i have a c7 v5 here, anything i can do to help?
<Ansuel> DomyWifi DW33D qca8337 in the wiki
<mangix> Still. I refuse to believe ar1022 is 8337. ar1022 is old
<mangix> For internal photos, FCC is great.
<Slimey> heh
<Ansuel> iodata_wn-ag300dgr can't find photo of this
<Ansuel> i mean we can try to check if exchange is present on qca8327
<Ansuel> just set the exchange and swap the cpu port definition
<Ansuel> (and comment port6)
<Ansuel> with a sgmii configuration we should have no connection if the swap is not supported
<mangix> I'll try this. I'm a bit busy today though. I'll get around to it later.
<Ansuel> sure take your time
<Ansuel> we just need to test 3-4 things to clear some doubt
RoadDv has quit [Remote host closed the connection]
<Ansuel> IMHO we are near the approval of the patch
leorize has joined #openwrt-devel
<mangix> Until they start arguing with each other again :P
dwfreed has quit [Read error: Connection reset by peer]
<leorize> I'm building openwrt master for lantiq and I'm getting "ERROR: package/system/gpio-cdev/nu801 failed to build." despite on kernel 5.4 and CONFIG_package_nu801 is not set
robimarko has joined #openwrt-devel
dwfreed has joined #openwrt-devel
<Ansuel> andrew will go on holiday for the next week... so thinks will be stuck for the entire week very sad... hope we have time to include stuff in the net-next
<mangix> Habbie: you can test the DSA PR to make sure it works for you.
<robimarko> Has anybody got any experience with the ath11k PCI and MHI?
<robimarko> I am trying to get the QCN9024 on AX9000 working
<Habbie> mangix, if it fails, do i need to solder to the UART? or is there TFTP recovery?
<robimarko> It appears to go throught all the MHI states into Mission mode and then ath11k gets stuck
<Ansuel> robimarko stupid question did you check if they added some patch about it ?
<Habbie> mangix, is this the PR? https://github.com/openwrt/openwrt/pull/4622
<Ansuel> (pls don't hate me)
<robimarko> Ansuel: Yeah, but there is a whole forest of patches for MHI after 5.10
<robimarko> And I still cant get PCI to work under 5.15
<Habbie> mangix, ah, that advises me to setup wifi to avoid lockout, awesome
<Ansuel> i read some work with 5.13
<Ansuel> no luck in using that?
<robimarko> Yeah, I am using Haukes 5.13 testing as QCN9024 is only supported in 5.13
<robimarko> Like I said, ath11k sees it, starts probing, goes through all of the MHI states and then gets just stuck after Mission mode
<hurricos> Hey folks. Question about compiling luajit for a 32-bit platform using gcc from Debian testing without being able to install said GCC.
<hurricos> How?
pmelange has joined #openwrt-devel
<Habbie> hurricos, are you in the right channel? you could be, just want to make sure
<hurricos> I was guessing that the OpenWrt toolchain should be building the right GCC, but I get:
<Habbie> ok, carry on :D
<Habbie> checking for strings.h... In file included from /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:194,
<Ansuel> robimarko: reading there is also mhi-next branch what a mess to track all these stuff
<Habbie> that doesn't look very 32 bits
<robimarko> Ansuel: Yeah, a big issue is the 5.10 kernel which is just old for this stuff and tends to have a ton of bugs
<robimarko> Ansuel: As far as I can tell, there is only one more state and that is the Ready state which it doesnt get to
<robimarko> Ansuel: I just cant get 5.15 PCI working on IPQ807x so I can properly test stuff
RoadDv has joined #openwrt-devel
<Ansuel> anyway intermediate kernel works? i mean i think the only way to escape from this is reduce in every way possible all the patches to check but i think that's not possible
<Ansuel> i assume it all broke even with 5.11
<robimarko> Yeah, it broke somewhere
<robimarko> Weirdly, I backported most of the changes from 5.11 and 5.12 as they were refactoring things to get PCI working in 5.10
dangole_ has joined #openwrt-devel
<Ansuel> random idea did you tried pci 5.10 version on 5.15 ? or it's really not possible? i mean the idea is to at least understand if something is missing from 5.13 to 5.15 about mhi
<robimarko> No point in that as I backported IPQ60xx PCIe support and refactoring changes to 5.10 and that works
<robimarko> There was a lot of refactoring into core in 5.11-5.13
<Ansuel> so bisecting is HELL
<robimarko> Yeah
<robimarko> Something fundamentally broke as even gen2 port is not working
<robimarko> And that has been upstream for a while now
<Ansuel> i mean considering the brakage is directly from 5.10 and 5.11... did they push that much changes from 5.10 to 5.11 ?
<robimarko> Yeah
<Ansuel> and nobody notice that ?
<robimarko> They refactored the whole DWC core to handle a lot more stuff
<robimarko> Most boards are probably working
<robimarko> And its not like anybody is using IPQ807x on upstream kernels at this point
<Ansuel> xiaomi hacky stuff? NOPE
<robimarko> Nope, this is something generic
<robimarko> For IPQ807x and IPQ60xx which use the same controller for PCIe Gen3
<Ansuel> oh so it's not some special implementation that got dropped/generilized
<Ansuel> it's even more strange that ipq60xx works and not ipq807x... i honestly think the only way to find the problem is backport one patch at the time, test it and find where it does brake but i think you already did that.
<robimarko> I dont think that IPQ60xx works at all despite somebody upstreaming support for the PCI
<Ansuel> i read that you backported things for ipq60xx and it does work
<robimarko> Yeah, but in 5.10 only
<Ansuel> all this stuff is funny considering that even ipq806x dwc driver was broken upstream and nobody ever notice that...
<robimarko> Last time I tried that PCI patch on IPQ6010 it failed in the same fashion as on IPQ807x
<robimarko> Its a clasic case of QCA not pushing stuff and not providing docs
<robimarko> As even the USB support for IPQ60xx that was pushed upstream doesnt actually work with mass storage
<robimarko> It works fine though with USB to ethernet
<Ansuel> that's good. if ipq6010 crashed the same as ipq807x we can at least start from a surely working device and find the code that destroy things
<Ansuel> wth usb to ethernet works but not mass storage o.o
<robimarko> Yeah, I couldnt believe it as well
<Ansuel> i'm curious to check the changes from 5.10 to 5.11
<robimarko> The weird thing is that PCI for IPQ60xx only got merged recently as is queued for 5.16
<robimarko> So it looks like somebody didnt actually test the thing
goliath has joined #openwrt-devel
<Ansuel> also what is problematic in this is... did the problem comes from pci core changes or dwc ?
<robimarko> Yeah, well I have got no idea
<robimarko> And I only got one IPQ60xx board with a PCI slot
<robimarko> And that one is a pain to work with
<Ansuel> from dwc side 5.11 changes started from nov 18 2020
<robimarko> As the vendor messed up everything they could
<Ansuel> and end to 26 2020
<Ansuel> dec 26 202
<Ansuel> and yes i can see they generalized tons of stuff and at the same time it looks like they changed some logic for this related to ipq807x
<Ansuel> (wonder if ipq806x works with all these changes)
<robimarko> That would be interesting to see
<Ansuel> do you know if having 5.15 in openwrt require lots of changes?
<Ansuel> i'm curious now...
<robimarko> Yeah
<robimarko> As you gotta port all of that pending/hack stuff
<robimarko> Just use buildroot for a small rootfs and make an initramfs directly
<Ansuel> well pending stuff luckly are now tagged with the version so i can just drop them... about hack i can just drop them if they are not necessary...
<Ansuel> mhhhh should i do this creazy thing ?
<robimarko> Honestly, if you just want to test 5.15 use buildroot
<Ansuel> or i can try 5.11
<hauke> Ansuel: you can use an external kernel and try 5.11 there
<hauke> CONFIG_EXTERNAL_KERNEL_TREE
<hauke> then you get questions about the new kernel config options
<hauke> do not include the gpio button support
<robimarko> Ahh, upstream applied the IPQ60xx PCI DTS patches
<robimarko> But they didnt actually apply the drivers
ecloud has quit [Ping timeout: 480 seconds]
<Ansuel> O_O
<Ansuel> how
<robimarko> Well, this happens when MSM tree applies something while the PCI one didnt
<Ansuel> but the changes are in pci right?
<robimarko> Nope
wvdakker has joined #openwrt-devel
<robimarko> I applied the PCI driver changes for IPQ60xx and it doesnt work
<robimarko> In the same fashion as IPQ807x
<robimarko> PCI PHY links up, everything will seem fine
<robimarko> You can see the PCI card(QCA9377 in this case) in lspci
<Ansuel> but nothing works
<robimarko> But when ath10k probes it will always get stuck on one of the spes
<Ansuel> magjestic fail
<robimarko> Yep
ecloud has joined #openwrt-devel
<mangix> Habbie: use wifi to avoid potential lockout. Should work fine though.
<mangix> LEDs might not. They should though.
<Ansuel> robimarko: if 5.11 works i will swear
Ansuel_ has joined #openwrt-devel
<Ansuel_> WTH Parse error at /home/ansuel/openwrt/scripts/kconfig.pl line 144.
<mangix> Everything’s a learning experience I guess
<Ansuel_> LOL mb i didn't create the config for 5.11
<Ansuel_> compiling...
<Ansuel_> o.O
Ansuel has quit [Ping timeout: 480 seconds]
<Ansuel_> but by the bootloader using Linux kernel's cmdline parameter mtdparts.
<Ansuel_> WTF IS THIS HACK IMPLEMENTATION GOD DAMN
<Ansuel_> sorry for the rant...
<Ansuel_> i mean i can add some hack patch to create entries from that... but wth.... it will never be accepted upstream
<Ansuel_> can't we just make the partition static?
<Ansuel_> the bottloader should report always the same one am i wrong?
<mangix> hahaha. Not all bootloaders work properly.
<mangix> Most uboot stuff is non upstreamable trash hack code.
<Ansuel_> i honestly think the correct and easier implementation is just mangle bl args / ignore them and declare partition in the dts...
leorize has quit []
<robimarko> I assume that they are using the bootloader for dual firmware
<mangix> Hmm? I think there’s an mvebu patch for ignoring kernel params.
<robimarko> And just having it pass partitions to the cmdline
<Ansuel_> mhh don't know they are ath79 device... low flash...
goliath has quit [Quit: SIGSEGV]
<Ansuel_> waiting for the user answer back to compiling 5.11
pmelange has left #openwrt-devel [#openwrt-devel]
<hauke> Ansuel_: you can configure the kernel to ignore the bootloader arguments
<hauke> OpenWrt does this for most targets becasue vendor bootloaders provide starnge options
Ansuel has joined #openwrt-devel
<hauke> *strange
<Ansuel> think i missed the last message
<hauke> Ansuel_: you can configure the kernel to ignore the bootloader arguments
<hauke> OpenWrt does this for most targets becasue vendor bootloaders provide strange options
<Ansuel> i know but i think we need the patches used in other target to extract the correct rootfs to mount
<Ansuel> can't understand why ath79 still use this hacky implementation instead of something more ""clean""
goliath has joined #openwrt-devel
Ansuel_ has quit [Ping timeout: 480 seconds]
<Ansuel> mangix: are you reading the pr?
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
hanetzer has quit [Quit: WeeChat 3.2]
Acinonyx_ has joined #openwrt-devel
wvdakker has quit []
wvdakker has joined #openwrt-devel
<Slimey> hmm?
<Slimey> ERROR: package/system/gpio-cdev/nu801 failed to build.
Acinonyx has quit [Ping timeout: 480 seconds]
<Ansuel> robimarko: rip.... pci works correctly in 5.11 on ipq806x
<Ansuel> [ 0.000000] Linux version 5.11.22 (ansuel@Ansuel-xps) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2
noahm has quit [Quit: reboot]
<hurricos> Habbie: I know: it's compiling for 32, though.
<hurricos> Actually, what bugs me the most is that it's checking out the system's installed headers, and not looking for the ones from the toolchain.
<hurricos> Unless LuaJIT is part of the toolchain?
<hurricos> Let me look closer.
<hurricos> No, right. This is part of the toolchain.
noahm has joined #openwrt-devel
<hauke> Slimey: I also was this problem when I wanted to apply the pull reqeust adding nu801
<hauke> Slimey: here they wrere unable to reproduce it: https://github.com/openwrt/openwrt/pull/4623
<hurricos> OK, got my answer. There was a patch for the buildbots (whose Dockerfiles I use almost directly): https://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033245.html
<hurricos> gcc-multilib needs to be installed, not build-essentials:i386
danitool has joined #openwrt-devel
<robimarko> Ansuel: Well, its IPQ807x/IPQ60xx specific then
<robimarko> IPQ60xx is weird, it gets stuck probing
<robimarko> And then after some time it just moves on and actually finishes probing ath10k
<robimarko> But fails on the BDF as my QCA9377 card doesnt have an upstream BDF
hanetzer has joined #openwrt-devel
<Ansuel> the delay seems interesting
<robimarko> Yeah, to me it seems to be exactly the same length
<Ansuel> some timeout that finish and probe continues?
<Ansuel> or some ready thing?
<Ansuel> that is now check and in the old driver was ignored?
<Ansuel> could be that now a mode is check and then it was just ignored?
<robimarko> Yeah, it starts probing:
<robimarko> [ 1.612068] ath10k_pci 0000:01:00.0: enabling device (0000 -> 0002)
<robimarko> [ 1.614913] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
<robimarko> And then it takes around 120 seconds to continue
<Ansuel> i notice some refactor where they added some extra check and it caused the failure of the driver for that reason. (and added some extra code to ignore the added check) so that would not be the first time something like that happen... especially with qca doing not standard at all stuff
<Ansuel> just for fun can you check if the 120 second are always around that value?
<Ansuel> a so precise values and so big... it must be a timeout or a sleep... nothing in hardware can require that much time
<robimarko> Its not the same, once it took 430 seconds
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
<robimarko> Ansuel: Check the IPQ807x log though
<robimarko> I have not seen these cma_alloc errors before at all
<Ansuel> do you think they are related?
<robimarko> Yeah, gotta be
<robimarko> ath11k is trying to allocate memory for QMI messages
<Ansuel> finally some error i should say
<Ansuel> why we didn't have this earlier ?
<Ansuel> mangix: btw don't know you but https://github.com/openwrt/openwrt/pull/4664 seems a bit arrogant....
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
<hurricos> So, after being unable to boot OpenWrt on another P1020RDB derivative, the WS-AP3825i, I sent out an email to plm@extrementworks.com (see https://cloud.kapostcontent.net/pub/04b28a7b-c5d0-4e4d-a1e7-79da832b3922/osd-extremewireless-os-version-ap-10-dot-51?kui=KD6X9S4PNomHSrog2y_LxQ)
<hurricos> I sent it from my work email because I figured, we use Extreme Networks products, how better to get a response?
<hurricos> I got a response basically within 15 minutes by a teed-off-sounding techincal product manager https://www.linkedin.com/in/paulofranciscotoronto/?originalSubdomain=ca
<hurricos> ... the response was to a giant reply-all with me cc'd, to https://www.linkedin.com/in/lam-peter/
<hurricos> I this will get juicy
<hurricos> s/I/I imagine/
<aparcar[m]> mangix: ping
Tapper has quit [Ping timeout: 480 seconds]
<hauke> robimarko: I updated mac80211 to 5.14 in my branch
<Ansuel> O_O
<Ansuel> patch n = 2000 ?
<robimarko> Just rebased on top of it and its building
<robimarko> Thanks
<robimarko> Unfortunatelly, its the same
<robimarko> ath11k is waiting for something and does not finish probing
<robimarko> Its gonna be a painfull debugging
<aparcar[m]> hauke: one more point till 5.15!
<aparcar[m]> hurricos: uhm what is happening?
<hurricos> aparcar: No, I just found it interesting which person responded to a GPL request to Extreme Networks.
<hurricos> I usually find GPL requests get responded to lower down the pipeline.
<hurricos> s/pipeline/ladder/
<hauke> hurricos: When companies provide a special mail address for GPL compliance this is often handled by the legal or compliance department and not the normal support department.
<hurricos> I see!
<hurricos> I know that Mikrotik just has you email support@, and they get back quickly.
<hurricos> well, last time it took a week.
<robimarko> hurricos: Have you by any chance got the ROS v7 GPL?
<robimarko> Last time I tried they were playing dumb
<robimarko> Claiming that its not released yet
<dangole_> hauke: any plans to nuke out-of-tree mt76 in favor of using the in-tree version with maybe patches on top? asking because i'm seeing patches taking long detour through gh/openwrt/mt76 before reaching kernel ml...
clayface has joined #openwrt-devel
clayface_ has quit [Ping timeout: 480 seconds]
<hauke> dangole_: currently mt76 gets updated more often than our mac80211 stack
<hauke> I do not have any plans in that directly, currently nbd is taking care of mt76
<hauke> there are only very few changes in mt76 and the QCA wifi drivers between 5.14 and 5.15, I think something went wrong
<robimarko> Ansuel: Found the culprit for not moving on
<Ansuel> While at it, let's also remove the auto-start option from ath11k mhi
<Ansuel> controller.
<Ansuel> yhea sure just to srew ath11k for no exact reason LOL
<robimarko> Its not an issue in the upstream kernel
<Ansuel> WTH .....
<robimarko> As it happened at the same time
<robimarko> But 5.10 MHI driver still requires that
<Ansuel> owww
<robimarko> And BTW, I got the same DMA error now in OpenWrt
<robimarko> So it looks like the upstream PCIe driver may actually work
<robimarko> LOL, but despite the DMA warning it actually registers the card
<Ansuel> LOL...
<Ansuel> and it does actually work ?
RoadDv has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<robimarko> Yeah, I can see it broadcasting and it allows to connect even in AX mode
<robimarko> Now I gotta pull the stock FW BDF for it
<robimarko> And fix the AHB radio as that is broken now
<robimarko> It appears to not know that remoteprocesor is up
<robimarko> And then tries to start that multiple times
<robimarko> And just gives up
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
fda- has joined #openwrt-devel
fda| has joined #openwrt-devel
hanetzer has quit [Quit: WeeChat 3.3]
fda^ has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
Tusker has joined #openwrt-devel
<Ansuel> i made something so hacky that that guy will laugh so badly
<Ansuel> lol
fda- has quit [Ping timeout: 480 seconds]
<Ansuel> robimarko: are you still here?
<robimarko> Ansuel: Yep, still here
<clayface> Ansuel: do you need help converting qca8k.txt to yaml?
fda| has quit [Ping timeout: 480 seconds]
<Ansuel> clayface definetly i would love some help... i still need to change the code if you can help me with that maddness
<Ansuel> robimarko: are you confident with mtdparts bootargs?
<Ansuel> i can't understand if it can contain nested partition
<robimarko> Ansuel: You shouldnt really be messing with that
<robimarko> Its been an upstream parser for a long time
<Ansuel> i'm experimenting adding support for nvmem if we have the static partition defined in the dts
<Ansuel> since we have some ath79 device that use bootargs to define mtd and are also defined in the dts... (they have dynamic rootfs and kernel that are set based on some uboot values)
<Ansuel> but everything else is static like the art partition
<Ansuel> so the idea is... you have bootargs and the static partition defined in dts... just assign of_node
<robimarko> So you want to ignore everything else?
<Ansuel> i just tested it and it works just good
<Ansuel> but i need to know if it can have nested partition
<tmn505> no, it can't, You can only specify flat table: https://www.denx.de/wiki/DULG/BootTimeConfigurationOfMTDPartitions
<Ansuel> <mtd-id>:<partdef>[,<partdef>] this part is scary....
<Ansuel> but if it's really just 1 level of partition than it's actually very good and i can just ignore any complex parsing
<robimarko> Like tmn505 pointed, you can only pass name(size)
<robimarko> Nothing more complex than that
<Ansuel> very good.... than it's done considering the comparable dts node structure would be just one level partition
<robimarko> But how would you pick and choose stuff?
<Ansuel> what do you mean ?
fda has joined #openwrt-devel
<robimarko> I mean, isnt bootloader passing the complete partition list?
<robimarko> I doubt that its only passing some partitions
<tmn505> btw, his devices dtsi specify fixed-partitions _and_ the partitions are passed with cmdline, which is obviusly wrong. He should choose one without the other.
<robimarko> Yes, that is really bad
<Tusker> well, if you want to override some partition definition, such as combining two useless factory partitions into a bigger one
<robimarko> The only reason why that is working is because the parser list is hardcoded in the media driver
<robimarko> And usually cmdline has higher priority
fda^ has quit [Ping timeout: 480 seconds]
<Ansuel> the intention is not to push this upstream as it would be rejected 100%
<robimarko> Honestly, cant the NVMEM be extended to just define a name in DTS and then match the partition based on that instead of OF?
<tmn505> I wonder if it'll work if all partitions except ART are specified in cmdline and ART as fixed in dts, would it pick art and create nvmem?
<robimarko> I know, that is why I would rather extend NVMEM than hack around parsers more
<Ansuel> robimarko: actually not that wrong
<robimarko> tmn505: I dont think you can have multiple parsers for the same MTD device
<Ansuel> was thinking a dedicated compatible for nvmem
<Ansuel> that register and one of the binding is the mtd label ?
<robimarko> Wait, didnt upstream add support for the whole MTD device for NVMEM?
<tmn505> robimarko: aye, thanks
<Ansuel> robimarko: yes but without an of_node the things doesn't work... you can't really assign cell without of node
hanetzer has joined #openwrt-devel
<robimarko> Yeah, but if we are gonna be hacking this anyway why not extend that to accept a string
<robimarko> And then do old school matching via partition name
<robimarko> Everything else can be the same
fda- has joined #openwrt-devel
<robimarko> BTW, you can be a bit naughty
<robimarko> And just define the ART partition that you care about in the DTS
<robimarko> And then rely on the fact that cmdline has higher priority
<robimarko> That would give you your of_node while using the cmdline parser(In theory)
<Ansuel> nope cause cmdline parser crate mtd parts with no of_node assigned
<Ansuel> so i added a function to the parser to find the of_node in the dts
<Ansuel> give me a sec and i can show you this sh*t ahahha
fda| has joined #openwrt-devel
<robimarko> Then, the only way I see to extend NVMEM to be able to create a cell using label matching instead of just OF
<Ansuel> yes that would be the only correct way... a node that register a dedicated nvmem provider and is based on mtd label
fda has quit [Ping timeout: 480 seconds]
<Ansuel> (i mean the only way to handle mtd defined from bootargs)
<Ansuel> for all the other case we have of node
<robimarko> Yeah, I mean that is what mtd-mac-address was relying on
<hurricos> robimarko: I got a similar response from Normunds R.
<robimarko> It was just matching on label instead of OF node
<robimarko> hurricos: So they are still pushing that logic
robimarko has quit [Quit: Page closed]
<hurricos> robimarko: If you hadn't left, I'd have given you the exact response, lol
<hurricos> How does one use the IRC bot to record messages for someone?
<Ansuel> anyway the switch to kernel 5.16 will be FUN... they set warning as error by default
fda- has quit [Ping timeout: 480 seconds]
<hurricos> RE: RouterOS 7: https://paste.c-net.org/RegalProceeds < "When it is out of beta and we have stabilised, I can prepare the v7 files too."
<hurricos> The release candidate 3 is out right now, so I imagine it's not long before RouterOS 7 has its full release.
robimarko has joined #openwrt-devel
<hurricos> The email I listed above is Linux patches on top of (iirc) Kernel 3.4, for their custom chip
<hurricos> robimarko: RE: RouterOS 7: https://paste.c-net.org/RegalProceeds < "When it is out of beta and we have stabilised, I can prepare the v7 files too."
<robimarko> hurricos: I got the same reply like a year ago
<hurricos> word-for-word?
<robimarko> Not word for word
<hurricos> You will notice v7 is still in release-candidate here: https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status
<robimarko> But it was the same, its not currently out, bla bla
<hurricos> Well, this one gives a timeline. Right now v7 is not stabilized
<robimarko> Yeah, 7.1 RC4 is the current release
<robimarko> I mean its been in some kind of beta/RC for over a year
<hurricos> I'm sure they'll stretch out the relase-candidate phase for as long as possible, lol
<robimarko> Yeah
<hurricos> But hey .... anyone remember how OpenWrt 20.10 turned into 20.12 turned into 21.02? :^)
<robimarko> As far as I understand, they are kind of obligated to provide GPL sources even if its in "beta"
<hurricos> It is poor behavior under the GPL for sure
<robimarko> Because its released publicly
<robimarko> Its not like an internal build, they regularly update it, provide changelog etc
<hurricos> But I imagine it's also a lot of work to figure out which version you have and make sure you have exactly the right sources.
<robimarko> Yeah
<robimarko> Their v6 is just useless
<hurricos> In what sense?
<robimarko> In the sense that code is terrible
<hurricos> that doesn't mean it's not production code :^)
<hurricos> it's just not production QUALITY ....
<robimarko> And it always tends to "lack" important stuff
<robimarko> Trust me, that is production/release code
<hurricos> I don't know, I have a soft spot for Mikrotik. They get a lot of stuff right that their competitors routinely mess up
<robimarko> You know that they are using it since it a copy/paste mess from vendor SDK-s
<Ansuel> big wors from robi HAHAH
<hurricos> Hahaha, same as every other vendor
<Ansuel> words*
<robimarko> Ansuel: Which warning?
<hurricos> robimarko: Sounds like any warning LOL
<hurricos> (in the Linux kernel build process)
<robimarko> hurricos: Yeah, every vendor SDK I have to touch, lets just say that its hard to even look at the code
<hurricos> I am glad I do not work in this industry, but it is still hard to shell into a Ubiquiti NanoHD and try to read dmesg
<hurricos> It physically hurts me
<robimarko> I am happy that I work at a company that uses upstream/mainline ready stuff 90+% of the time
<hauke> The OEMs get the SDKs they ask for
<robimarko> Yeah
<Ansuel> ready for the worst patch you will ever see ?
<hauke> or better the big OEMs get the chip vendor SDKs they ask for
<robimarko> hauke: Yeah, unfortunatelly recently I have been dealing with switch vendors
<hauke> robimarko: big binary blob?
<robimarko> To say the least
<robimarko> If you heard of DENT project
<robimarko> Its a move to switchdev
<Tusker> Ansuel: formatted nicely, so hardly the worst :)
<robimarko> Of course in the binary firmware sense
<robimarko> That you just use the kernel as a fancy interface to the blob
<robimarko> But even that is an improvement to the for example Marvell switching SDK
<robimarko> Which implements everything in userspace
<Ansuel> why it seems everything is switching to firmware blob with linux just be used as the ""coordinator"" of them?
<robimarko> Because they can hide whatever they want behind that interface
<robimarko> Ansuel: I have seen way worse patches
<Ansuel> i mean the implementation is....
<robimarko> As long as it works, it can be improved
<hauke> Ansuel: you can use the FW on multiple OSes, the custoemr can not modify it so it is less support, you can protect your IP
<hauke> and it is more secure, becuase linux is very insecure
<hauke> from a HW vendor perspective
<robimarko> Honestly, they just care about it making it a lot more difficult for competition to copy things
<hauke> have you ever seen that a competitor really copies Software?
<Ansuel> but honestly... considering the target is really linux... it's just an excuse to keep their code secret
<Ansuel> i don't trust all the security reason
<robimarko> hauke: No, they dont care about the software
<robimarko> But if its transparent then they are afraid that they can figure out how the HW works
<hauke> the security reasons are mostly marketing terms only. Often such a FW is build with 10 year old toolchains without ALSR, memory protection or anything like this
<Ansuel> crypto firmware blob would be a direct example ?
<robimarko> Security is like the last important thing for them, otherwise like you mentioned there is a lot of things that can be improved first
fda has joined #openwrt-devel
<robimarko> One of them would be not relying on 5+ year old userspace apps built with GCC5 at best
<Ansuel> clayface: did you start some conversion? I'm starting working on the droiver side. Just asking
<robimarko> And off couse, no hardening options enabled
<Ansuel> robimarko: i smell qcom stuff here aahahha
<robimarko> Ansuel: They all operate the same
fda- has joined #openwrt-devel
<Ansuel> anyway in all of this mess i would be really curious to check a documentation of one wifi chip and source of firmware blob
fda^ has joined #openwrt-devel
fda| has quit [Ping timeout: 480 seconds]
<robimarko> Ansuel: The only way you will be seeing that is if you a developer on that team and after a lot of NDA-s
<Ansuel> in expect pure panic considering the complexity that ath11k driver reached
<Ansuel> yhea like many papaer of NDA ahahah
<Ansuel> still i would hate it considering their main target is not upstreaming stuff but the qsdk
<robimarko> Well, they all they care about
<hauke> they do not have controll over upstream stuff, but they controll the QSDK
<hauke> and the QSDK is probably verified
<hauke> to work 100%
<robimarko> As long as their big customers dont complain and use whatever they provide its gonna be like htis
fda has quit [Ping timeout: 480 seconds]
<robimarko> The only reason why Marvell has a switchdev driver is due to a huge customer requiring it
<robimarko> As they dont want Marvell to controller the SW like the vendors are used to
fda- has quit [Ping timeout: 480 seconds]
<hauke> are the big cloud vendors (AWS, Azure, GCP) fine with the switch vendor SDKs?
<mangix> Ansuel: I'm back
<mangix> aparcar[m]: pong
<aparcar[m]> mangix: I guess the SDK hazard is fixed?
<mangix> yep
<robimarko> hauke: I can tell you that one of the isnt
<robimarko> Hence why DENT exists
<mangix> wait a day of 2 for everything to be built
<Ansuel> hauke nice question
<robimarko> hauke: And considering that Microsoft has SONIC then you know which one it leaves
<hauke> robimarko: ok nice, they should be big enough to influance the chip vendor if they are able to coordinate internally
<hauke> This website lists one of them: https://dent.dev/
<robimarko> hauke: Oh yeah, they kickstarted a whole ecosystem here
<mangix> alright
<mangix> time to pester people
<Ansuel> sartura it's you 1?!?!
<Ansuel> also nvidia wow...
<robimarko> Yeah, we are members
<robimarko> Nvidia was originally Mellanox, but they bought Mellanox since then
<Ansuel> interesting project it seems
<Ansuel> Mellanox LOL
<hauke> I assukme that AWS is 5% to 20% of the datacenter 100G+ switch market
<robimarko> I honestly dont know, but currently DENT has 1G or 10G based HW
<robimarko> Its focused on the edge switching
<hauke> I am supprised that they still care about 1G and 10G
<robimarko> Well, its about edge switching
<robimarko> Which in 99% of cases has no need for over 10G
<robimarko> And its an untapped market
<hauke> but 40G is not so expensive and this is for the next gen systems anyway
<hauke> interesting that there is still lot of 1G in the cloud
<robimarko> The target here is much wider
<robimarko> I would say that cloud/data center is not the target at all
<robimarko> As that is SONIC-s market
<robimarko> This is targeted at retail stores, warehouses
<robimarko> Anything that is just pure edge
<hauke> ok interesting
<robimarko> So its gotta hit relatively low prices
<robimarko> Current HW is overcomplicated
<robimarko> As it has 2 CPUs
<robimarko> One is open source and runs your SW
<robimarko> Armada 7040 currently
<robimarko> And the other Armada 385 is where the magic FW souce for the ASIC-s happens
<mangix> Ansuel: looks like you might be right. These mac6-exchange routers might be using qca8337
<mangix> I got a bootlog from that domywifi unit
<mangix> 8337
<Ansuel> did you find some reference for the 2 ancient device?
<mangix> not that far yet
<mangix> oh perfect it's that hiroshi guy
<Ansuel> ?
<mangix> i'm looking through git history on all these devices
<mangix> tmn505: ping
<mangix> WHAT
<mangix> 8337
<Ansuel> lol?
<mangix> how does an old device get a new switch?
<Tusker> 8337 has been around since at least 2014
<mangix> Ansuel: forgot what you wanted me to test. mac6-exchange and the port definitions swapped, right?
<Ansuel> yes but i think we can safely say mac06 exchange is only present in qca8337
<Ansuel> what i really want to know if qca8327 can work with port6 as the only cpu port
<mangix> I think so
<mangix> I tested that yesterday
<Ansuel> yesterday you had some problem if i remember correctly
<mangix> oh nono
<mangix> unrelated
<Ansuel> so you confirm that also qca8327 worked with cpu port6 only
<Ansuel> nice!
<mangix> I didn't have the CONFIG_AR8216 removal so the switch coming up took longer
<Ansuel> ow right
<Ansuel> we still need to fix that in openwrt...
<mangix> but it works just fine
robimarko has quit [Quit: Page closed]
<Ansuel> nooo robi :(
<Ansuel> any idea to improve this? for (port = 0; port != 6; port = 6) {
<Ansuel> ahahah
<mangix> what?
<Ansuel> logic to loop 2 times...
<mangix> i think i'm missing context
<Ansuel> i'm writing v5 and i need a loop to check the 2 cpu port so port0 and port6
<mangix> right?
<Ansuel> for (port = 0; port != 6; port = 6) { and this is pure shit
<Ansuel> (and also wrong)
<mangix> I mean...the alternative is a while loop
<Ansuel> found a cleaner solution... we are in probe lets waste some cycle AHAHAH