<russell-->
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
<russell-->
fatal: the remote end hung up unexpectedly
<russell-->
all the other remotes fetch fine
pmelange has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
pmelange has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
rmilecki has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<rsalvaterra>
russell--: One does not simply fetch from blogic. :P
<stintel>
rsalvaterra: re gcc 11: no
<rsalvaterra>
aparcar[m]: I'd assume upstream backports wouldn't need much reviewing. The fact they're upstream means they've already been reviewed, no?
<rsalvaterra>
stintel: Do it. You know you want to… 😎
<aparcar[m]>
I just created a commit to use gcc 11 by default
<aparcar[m]>
any conversation I missed about that stintel rsalvaterra ?
<mangix>
in terms of failures, stintel seems to have a way of exposing them
<rsalvaterra>
aparcar[m]: No, you didn't miss anything. I mean, stintel bumped the default GCC version to 10, but I suggested just skipping it and going directly to 11.2.
<rsalvaterra>
(There's a Spinal Tap joke around here, somewhere…)
<rsalvaterra>
mangix: DSA is also working great on my WDR3600. I didn't fetch the LEDs commit, so I don't have working LEDs yet… but to me that's a feature. :P
<mangix>
uhh what?
<rsalvaterra>
mangix: The qca8k LED support patch? And the device tree changes needed?
<mangix>
what do you mean working LEDs?
<rsalvaterra>
The switch LEDs, I mean.
<mangix>
so they don't work currently?
<rsalvaterra>
They're all off, on my device. Wait, wasn't it supposed to be like that, without the LEDs patch?
<mangix>
On my Archer they work just fine.
<mangix>
no LED patch needed
<rsalvaterra>
Hm.
<mangix>
LED patch just lets me control them
<rsalvaterra>
Oh, it just exposes them in sysfs?
<mangix>
yeah. I can also turn them off via DTS, but that's wrong IMO
<rsalvaterra>
We don't want unupstreamable device tree hacks, for sure… :/
<rsalvaterra>
I think the relevant pulls have been updated in the last couple of days, so I probably need to cherry-pick the relevant commits again…
<aparcar[m]>
i'm off
<aparcar[m]>
stintel: please comment on the gcc11 proposal
<rsalvaterra>
aparcar[m]: Good night! :)
<mangix>
rsalvaterra: I'm talking about the default-state property. DTS is meant to describe the hardware. But describing an LED as off when it's on by default is wrong.
<mangix>
on a sidenote, I find it funny how this router has an LED for wlan2g via GPIO and one directly from the ath9k chip.
<rsalvaterra>
mangix: I see. Maybe we missed something…?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<mangix>
?
<rsalvaterra>
mangix: Yeah, that's weird! Why not have both LEDs connected to each ath9k chip?
<mangix>
who knows. The ath9k LED is probably bogus.
<mangix>
Currently I can disable all LEDs except for the system one
<mangix>
the system one is not GPIO connected
<mangix>
Two drivers that could use LED support are mt76 and mt7530. Wonder if ImmortalWrt has patches for them.
<rsalvaterra>
mangix: You've got mail. :)
victhor has joined #openwrt-devel
<mangix>
:). I'd ACK but I'm away from a computer.
<rsalvaterra>
Just reviewed aparcar[m]'s GCC 11.2 bump. Ship it! :)
Tapper has joined #openwrt-devel
<mangix>
One thing I learned from the whole LED thing is that the label property is deprecated.
<mangix>
Which is interesting since it's used everywhere here.
Borromini has quit [Quit: Lost terminal]
<mrkiko>
slh: blocktrron: thanks for the reply
<mrkiko>
slh: blocktrron: my question wasn't clear. I'm testing an experimental port of a board and was wondering if when switching to 5.10 there will be the need to change partitioning to enlarge kernel partition itself. It's and 128 mb so not particularly constrained in space.
<stintel>
aparcar[m]: I have no objections, I started work on gcc10 as default before gcc11 was in tree, spent multiple days on that, so didn't want to let that work go to waste
pmelange1 has quit [Quit: Leaving.]
Tapper has quit [Ping timeout: 480 seconds]
victhor has quit [Ping timeout: 480 seconds]
victhor has joined #openwrt-devel
rua has joined #openwrt-devel
<blocktrron>
mrkiko: if it's a NAND device, OPT for ~6-8 MiB
<blocktrron>
Avoids heacaches in the future
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
valku has joined #openwrt-devel
valku has quit []
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
ecloud has quit [Ping timeout: 480 seconds]
<swalker>
mangix: upstream has been corrected in the watch file
brpr has joined #openwrt-devel
danitool has joined #openwrt-devel
<brpr>
Hi all! I now have some time to further diagnose my PHYs on my router
<brpr>
and once again my nickname changes, I was the RT-AC55U guy :)
<brpr>
PaulFertser, I hope that you're still here lol. My router is bootlooping only if the RX (router)-TX (uart adapter) is made and only if I have picocom running
<Habbie>
brpr, just RX-TX connected? nothing else?
<brpr>
if I disconnect RX-TX and only connect TX-RX (obviously GND too) the router boots a-ok Habbie.
<Habbie>
right - GND was the underlying question
<Habbie>
no further questions from me
<brpr>
:)
<brpr>
welp time to get out the Pi, that worked reliably but really annoying
<brpr>
with Pi it works :P
<PaulFertser>
brpr: hey
<PaulFertser>
brpr: do you have a resistor to connect in series?
<PaulFertser>
100 Ohm should work, 1k too.
brpr has quit [Ping timeout: 480 seconds]
<rsalvaterra>
mangix: Dang, the AT803x is just full of surprises…!
<hauke>
rsalvaterra: they probably fixed some bugs with the newer revision and thee bugs are not relevant for all use cases, or it is just a different revision like an industry version
brpr has joined #openwrt-devel
<rsalvaterra>
hauke: It's a different revision, yes.
<rsalvaterra>
hauke: Need testing for the backports update?
brpr has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
robje has quit [Quit: WeeChat 3.2.1]
robje has joined #openwrt-devel
mrkiko has quit [Quit: leaving]
pmelange has joined #openwrt-devel
<mangix>
Wow. Ansuel worked some miracles when I was asleep. If qca8k gets in the next version of OpenWrt, it'll be in better shape than even ar71xx
<rsalvaterra>
mangix: The guy is a machine. Another revision identified. 😉
<rsalvaterra>
I think DSA for ath79 is feasible for 22.x. Especially if Ansuel can make his automated conversion work.
<rsalvaterra>
mangix: Tell me when you add the changes you your tree, easier to cherry-pick from yours. 😆
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<mangix>
LOL
<mangix>
My branch no longer has 3600 support. Need to add it.
<mangix>
reading 6 bytes from a region of size 0 . love it
<Slimey>
is it appropriate to ask for a dev if wanting to take on a piece of hardware on the openwrt-devel mailing list?
<aparcar[m]>
Slimey: yes. If you're a doing that for a company you should mention it. Also the device should be special in some way, don't ask if someone needs an old 4MB router please.
<rsalvaterra>
mangix: Oh, I just noticed you reverted the multi-CPU DSA patch. What broke?
<aparcar[m]>
mangix: thank you
<mangix>
rsalvaterra: probably I'm missing the iproute change
<mangix>
anyway, I don't need it right now.
<aparcar[m]>
mangix: what about the layerscape thing?
<mangix>
aparcar[m]: unrelated
<mangix>
it fails during the dts stage
<mangix>
probably does so currently if I had to guess
<slh>
rsalvaterra: I've lost track a little, how is qca8k running on your tl-wdr3600 and u-boot_mod for you? (I have a tl-wdr3600 v1.5 and tl-wdr4300 v1.1 sitting here, waiting for it and was planning to rebase my ipq806x patchsets later today ;)
<mangix>
slh: switch LED control is coming back
<mangix>
present on ar71xx, lost with ath79
<slh>
yeah, LEDs aren't a big concern for me - good if they're there, wouldn't lose sleep if they aren't
<slh>
black electrical tapes works well ;)
<mangix>
not good enough on devices with light bleed
<slh>
yeah, I know (Asus wl-500gP v1, Netgear SXR30, ...)
rmilecki has quit [Ping timeout: 480 seconds]
<mangix>
anyway, the last massive bug was just fixed.
<mangix>
AR1A and BR4A is nomenclature used for the switch as well. Not just the WiFi cards
<mangix>
Best part is, the Archer C7v2 has a BR4A wifi card but an AR1A switch
<mangix>
probably fixed with the v3.
<slh>
heh, interesting - but probably (for TP-Link) just a v1 with the wireless cards replaced
<mangix>
also a flash space bump (8MB to 16MB)
<mangix>
slh: that would be the cheap way to fix it, yes.
* mangix
's branch is a nightmare
<hauke>
rsalvaterra: I am currently not at home, will do some tetsing in the next days and push the mac80211 updates
<mangix>
alright, since qca8k supports configuring the LEDs, my LED patch goes away
<mangix>
rsalvaterra: force pushed. cherry pick should be painless now
<mangix>
aparcar[m]: uhhh was that gcc 9 removal broken? I still see GCC 9 as selectable.
<mangix>
weird
<aparcar[m]>
it there
<aparcar[m]>
toolchain/gcc/Config.in
<aparcar[m]>
it's "gcc 9" not "gcc9" so my grepping didn't catch it
<aparcar[m]>
I'll fix that in a bit
<mangix>
hmmm taking a while to compile the toolchain
<mangix>
aparcar[m]: finally fixed.
<aparcar[m]>
thanks
<aparcar[m]>
it's running agian
<mangix>
hmmmm thinking about it, the patch does indeed fix compilation. But doesn't sound like it's right. The code is casting a 32-bit integer to a u8 pointer. The original type is a u8[6] which is 48-bits.
<mangix>
which implies the last two bytes are uninitialized.
<rsalvaterra>
slh: I don't have the exact pepe2k u-boot mod. I have a mod of that mod with overclocking enabled (can't find the site, but it was also done by some Polish guy). My WDR3600 is rev 1.4. :)