<stintel>
hah, now that I'm giving it some thought ...
<stintel>
the ERL was my backup router, so normally not getting a lot of trafficv
<stintel>
but, it's running conntrackd in the mode that is not recommended, which causes a shitload of traffic, in pps
ashkan has joined #openwrt-devel
<Tusker>
damn, no wg_dsa.ko source code :|
<stintel>
reply to their mail and state that it's missing
<Tusker>
already done
rua has quit [Quit: Leaving.]
<stintel>
excellent ;)
<stintel>
dangole: ah btw, I'm back at home where I have 10GbE PoE switch, so if you have anything you want to have tested for 2.5GbE on the U6LR, tell me
kenny has quit [Ping timeout: 480 seconds]
<stintel>
ugh damnit, RPi Zero 2 is just stuck at rainbow now, while I was previously able to boot it but without wifi
Tapper has quit [Read error: No route to host]
Tapper has joined #openwrt-devel
<dangole>
stintel: nice one! enabling CONFIG_AQUANTIA_PHY in target/linux/mediatek/mt7622/config-5.10 would be a first step. then dumping MDIO ID and adding it in case it is different from PHY_ID_AQ1202...
<dangole>
stintel: there is an existing patch in layerscape target adding support for it: 701-net-0331-drivers-net-phy-aquantia-enable-AQR112-and-AQR412.patch
<stintel>
hmmmmz
<stintel>
really tempted to give that a go right now :D
rsalvaterra has quit [Quit: rsalvaterra]
rsalvaterra has joined #openwrt-devel
<stintel>
dangole: actually the patch is not even needed I think because we have target/linux/generic/backport-5.10/701-net-0331-drivers-net-phy-aquantia-enable-AQR112-and-AQR412.patch:+++
<stintel>
wait
<stintel>
yeah ignore me, i copied it there from layerscape *facepalm*
<stintel>
and it doesn't apply cleanly
<Tapper>
My god llvm-bpf takes a long time to build. I did make -j1 to see if that fixt it and it has bin going for an age!
<Tapper>
The packages did build with the host llvm but qosify keeps crashing.
<Tapper>
stintel -j80 o man!
<Tapper>
stintel I would not like your power bill! lol
<stintel>
anyway, good luck, hitting the bed
<stintel>
Tapper: me neither
<Tapper>
Thanks mate have a good sleep.
<stintel>
cheers
<stintel>
my apartment consumes ~20kWh when I'm *not* at home
<stintel>
per day&
ashkan has quit [Ping timeout: 480 seconds]
<dangole>
stintel: i've imported and fixed that patch, but mdio bus is completely dead, maybe pinctrl issue, looking into mt7622 datasheet atm...
<dangole>
stintel: maybe they even use bit-banging mdio on some random gpios....
kenny has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
strobo_ has joined #openwrt-devel
strobo has quit [Ping timeout: 480 seconds]
<dangole>
stintel: ok found. mtk_eth_soc lacks drivers lacks support for clause-45 mdio access. apparently only clause-22 is supported atm.
<Slimey>
stintel lol sounds like me and my servers, network gear
victhor has quit [Ping timeout: 480 seconds]
<dangole>
stintel: it's not very hard to do imho, just need to probe c22/c45 from of and then change some bits of read and write commands (see mt7622 datasheet page 1958, 1959: PHY Indirect Access Control)
kenny has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
felix has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
enyc has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
<Namidairo>
do mtk not ship ubifs capable u-boot with their mt7622 sdk
<Namidairo>
I guess that explains why the stock image I was looking at had a squashfs image
<dangole>
Namidairo: squashfs can happily exist on top of ubiblock... ubifs is usually only for read-write filesystem, ie. replaces jffs2 (which is not really suitable for NAND)
<dangole>
Namidairo: afaik they have reconsidered that design, the new spi-nand driver also used for mt7629 and part of recent MTK SDK is built for UBI...
Andi_ has quit [Ping timeout: 480 seconds]
<dangole>
Namidairo: (i mean the original JFFS2-on-top-of-NAND-with-BMT design which was not the best idea...)
Andi_ has joined #openwrt-devel
<dangole>
stintel: i'll continue after sleeping, but in theory things could work now: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commitdiff;h=fbab1a0e68f170d6a6b3b38548c9898478dc069b
rua has joined #openwrt-devel
<Namidairo>
too bad the only cheap choice for a mt7622+mt7915 unit here is a locked down unit
<Namidairo>
e8450/rt3200 was never released here
dangole has quit [Remote host closed the connection]
<slh>
new day, new game - MediaTek Filogic 830 appears to become what the rt3200/ e8450 should have been to actually compete
Grommish has quit [Read error: No route to host]
rua has quit [Quit: Leaving.]
danitool has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<Namidairo>
I wasn't particularly keen on reprogramming the nand on the unit anyway
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
rmilecki has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
nitroshift has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
gladiac has joined #openwrt-devel
goliath has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
nitroshift has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
dedeckeh has joined #openwrt-devel
drikus_ has quit [Remote host closed the connection]
<dhewg>
nbd: qosify sounds nice! I think there's a typo in include/bpf.mk though: http://sprunge.us/iRN3my
<nbd>
right, thanks
<dhewg>
with that it builds, but qosify -o prints "libbpf: elf: endianness mismatch in /lib/bpf/qosify-bpf.o"
<dhewg>
is that a bug or is my clang not suitable?
<dhewg>
is that comparing apples to apples? I'm not sure if I can translate the bandwith like that, sqm has this 'overhead' option, which in this case is set for pppoe
<stintel>
qosify does diffserv4 o_O
<stintel>
I need to put this higher on my todo list :D
<rsalvaterra>
stintel: Uh… cake does diffserv4.
<stintel>
ah, right
<stintel>
brainfart
<rsalvaterra>
But not by default, I think. You need to choose it specifically.
<stintel>
yeah, I'm using that
<stintel>
SQM: ERROR: SQM script ctinfo_4layercake.qos not found!
<stintel>
oh well
<Tapper>
nbd Hi qosify is running grate on my r7800
<Tapper>
After getting llvm to build which took a long time it is all up and running and it's faster than SQM for me. I get about 20mbits more on my download.
<Tapper>
bufferblat is looking good.
<rsalvaterra>
stintel: I remembered where I've seen the hostapd VLAN stuff… https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5aa2ddd0d6b9759c62bbb7bb11b72a7f4269c16b
<stintel>
hmmm still some spanning tree issues
dangole_ has quit [Ping timeout: 480 seconds]
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
schwicht has joined #openwrt-devel
isinyaaa has quit [Quit: WeeChat 3.3]
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
jbowen has quit [Read error: Connection reset by peer]
jbowen has joined #openwrt-devel
philipp64 has joined #openwrt-devel
<Habbie>
the packages CI emits artifacts, with filenames like arm_cortex-a9_vfpv3-d16-packages.zip - or, as I have now, arm_cortex-a9_vfpv3-d16-packages(2).zip and growing
<Habbie>
does anything else depend on those names? if not, can we maybe make them more distinct?
<Habbie>
(this is the github multi-arch-test-build.yml action)
Tapper has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
<stintel>
opening the U6LR looks a lot harder than the U6Lite :(
<Habbie>
only if you want to neatly close it later
<stintel>
:D
<stintel>
I can do tftp recovery but I have the feeling that console is going to be handy to try and get it to do 2.5GbE
<stintel>
flashed image with changes from dangole's staging tree and it's no longer reachable
dangole_ has joined #openwrt-devel
<stintel>
dangole_: the U6LR is unreachable after flashing with image containing your changes
<stintel>
I was just able to open it up, will try getting serial console now
<stintel>
alright, got console
<dangole_>
stintel: oh, i could have told you that.... i just went to sleep and knew it wouldn't work yet
<dangole_>
stintel: i will continue working on it thursday or friday, polluting everything with tons of printf's to see if my newly introduced codepaths are even used now...
<hauke>
xdarklight: I have the Buffalo WSR-2533DHP2
<stintel>
dangole_: I can do some printks and report back :)
<dangole_>
stintel: i also request GPL sources from ubnt and they already confirmed that they have received my request an compliance team will get back to me. from analyzing stock bootlogs it was already obvious though that we will require clause 45 phy support...
gopherouter has joined #openwrt-devel
<stintel>
Set RTL8367S SGMII 2.5Gbps
<stintel>
hmmz
<gopherouter>
hey, sorry if I interrupt an ongoing troubleshooting for some comrade, I want to ask about one of the known issues in 21.02.1 (luci menu misallignment)
<gopherouter>
if I checkout the 21.02.1 tag and perform feed update today would the issue still be there?
<gopherouter>
I'm asking because I'm confused if feeds for luci bootstrap theme are updated with feed update or they exist in the main openwrt git
<stintel>
afaik there is not luci code in the base repo
<gopherouter>
oh thanks, so I assume that feeds update everytime gets the latest version of the sources for example with luci, right?
<stintel>
that depends on what is in feeds.conf, let me check
<stintel>
it's pinned to the commit hash so you'd have to change that
<hauke>
xdarklight: which mt7622 device do you have?
<stintel>
gopherouter: you could also just build from the openwrt-21.02 branch instead of the 21.02.1 tag
<stintel>
there feeds.conf.default is tracking the branch, not a git hash - https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=feeds.conf.default;h=98bf97232de53b711e17502a6ec1811271f5391b;hb=refs/heads/openwrt-21.02
<gopherouter>
*facepalm* sorry stintel for the effort, I should have seen directly the feeds.conf file, I really appreciate helping me !
astronautap has quit [Ping timeout: 480 seconds]
<gopherouter>
I have to close browser to conserve resources for the build process, cu all later *waves*
gopherouter has quit []
<stintel>
dangole_: fyi, mdio_phy_id_is_c45(phy_addr) does not evaluate to true
astronautap1 has quit [Ping timeout: 480 seconds]
minimal has quit []
<dangole_>
stintel: that explains why it doesn't work...
Tapper has joined #openwrt-devel
<stintel>
dangole_: I hacked it with || 1 but it still doesn't work
<stintel>
did you see: Set RTL8367S SGMII 2.5Gbps
<stintel>
I get that in u-boot
<stintel>
after running tftpboot
<dangole_>
stintel: that probably just comes from MTK SDK which gave choice to either us MT7531 or RTL8367 as switch IC. probably that AQ phy needs tuning tx/rx-delay similar to RTL8367
<stintel>
understood
<dangole_>
stintel: but in that sense it already works, with 2.5G fixed link. just the PHY itself doesn't report link status and you can't set it to negotiate with 2.5G link partner as we can't access it via MDIO in Linux.
<dangole_>
stintel: the most interesting line in the bootlog is this: mdio45.w addr[0x0000E410] value[0x00000000]
<dangole_>
stintel: mdio45 is clause-45 MDIO functions in mtk uboot
astronautap1 has joined #openwrt-devel
<stintel>
dangole_: something else I noticed is that _mtk_mdio_write is never called
<dangole_>
stintel: that is expected as reading already fails
<dangole_>
stintel: you mean at runtime, i suppose. it should be reachable in code, of course.
<stintel>
yeah at runtime, added printk in this one also
<stintel>
ok, I added the mdio tool to my image and that confirms it cannot read
goliath has joined #openwrt-devel
ashkan has joined #openwrt-devel
<aparcar[m]>
rsalvaterra: any updates on your ramips 5.10 update?
<rsalvaterra>
aparcar[m]: Not that I know of, no. I do agree with lipnitsk, however. If there's any fallout, we should be able to fix it incrementally.
rejoicetreat has quit [Remote host closed the connection]
<xdarklight>
hauke: I don't have any MT7622 device but an MT7621 based D-Link DIR-1960
<lipnitsk>
rsalvaterra: do we really need okli to merge 5.10 for ramips?
<lipnitsk>
I'd say just merge it and fix okli incrementally, and I think you said the same, just confirming.
<lipnitsk>
5.10 is the way to go so why hold non-okli targets hostage?
<lipnitsk>
People that need those targets can always use 21.02 or fix master:)
Tusker has joined #openwrt-devel
jbowen has quit [Quit: leaving]
dedeckeh has quit [Remote host closed the connection]
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
<hauke>
xdarklight: ok, mt7622 and mt7621 are using the same NAND controller you would like me to test mt7622
ashkan has quit [Ping timeout: 480 seconds]
<xdarklight>
hauke: MT7621 seems to have some quirks since it's NAND and ECC controllers are not ECC compatible. it would be great if you could try out my patches once I made them work on MT7621 (to verify that I didn't break MT7622)
<hauke>
xdarklight: no problem
ashkan has joined #openwrt-devel
<hauke>
most mt7622 devices use SPI nand
<hauke>
but the Buffalo WSR-2533DHP2 uses parallel nand
c0sm1cSlug_ has joined #openwrt-devel
kenny has quit [Ping timeout: 480 seconds]
c0sm1cSlug__ has joined #openwrt-devel
kenny has joined #openwrt-devel
c0sm1cSlug has quit [Ping timeout: 480 seconds]
c0sm1cSlug_ has quit [Ping timeout: 480 seconds]
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]