<mangix>
what you just saw is an issue with a lot of host packages honestly.
<aparcar[m]>
thanks for the pointer that might do the trick already
<aparcar[m]>
doesn't that defeat the whole purpose
<mangix>
?
<aparcar[m]>
building host packages which then end up being linked again host libs
<Tusker>
hmm... what has changed between 21.02 and master that could impact mpc85xx targets ? any ideas ?
<mangix>
sort of. hostpkg binaries should most definitely be linking to hostpkg libraries. but the whole point is to fix some package that depends on a hostpkg. if it works it works.
<Tusker>
oh, it could be the fdt locator config@ vs config- change... hmmmm
Slimey has quit [Remote host closed the connection]
<slh>
hauke: mac80211_update-to-backports-5.10.64 and the musl patch series are working fine for me on ipq8065/ nbg6817, ipq8064/ g10 and ipq40xx/ map-ac2200 - built tested (only) on lantiq/xrx200, ath79, ath79-tiny, ipq807x and realtek
pinky_ has quit [Remote host closed the connection]
<mangix>
aparcar[m]: updated again... The install section was totally wrong.
<mangix>
Should a second clean call succeed or fail?
rmilecki has joined #openwrt-devel
<aparcar[m]>
Succeed
valku1 has joined #openwrt-devel
valku has quit [Read error: Connection reset by peer]
valku1 is now known as valku
Grommish has joined #openwrt-devel
<mangix>
aparcar[m]: fixed and pushed to the meson PR. Please repull
<mangix>
hmmm why is mm-common even in the codebase?
<aparcar[m]>
Duuno
<mangix>
it says tools/libtool depends on it. I call bullshit.
<mangix>
The mm-common module provides the build infrastructure and utilities shared among the GNOME C++ binding libraries. It is only a required dependency for building the C++ bindings from the gnome.org version control repository. An installation of mm-common is not required for building tarball releases, unless configured to use maintainer-mode.
<mangix>
says nothing about libtool, which is unrelated to GNOME
<Tusker>
ok, p2020rdb doesn't like gcc-10 it seems - hangs during kernel 1st stages (no console output yet)
<Tusker>
so, 21.02 works because it's still at 8.4, trying gcc 9 now to see if that is a better option - doing a fresh build in case some things are half built by gcc10 etc
<mangix>
should be
<mangix>
-fcommon came with gcc10
<Tusker>
is there a flag I should try with gcc10 with p2020rdb ? or just stick with gcc9 ?
<mangix>
-fno-common
<mangix>
sorry, the complete opposite
<mangix>
-fcommon
goliath has joined #openwrt-devel
<Tusker>
OK, will try -fcommon with gcc10 first, with a fresh build for all packages
<Tusker>
if -fcommon solves it, is it possible to add that as a default option for the target ?
<mangix>
wait.... what's failing to compile?
<Tusker>
it compiles fine, it fails to run the kernel
<Tusker>
21.02 branch works without modification
<mangix>
...
<Tusker>
master branch works by changing gcc to 8.4.0
<mangix>
that sounds like hilariously bad behavior
<Tusker>
is it worth trying -fcommon, or is it totally unrelated ?
<mangix>
depends on the code
<mangix>
but
<mangix>
if that was the issue, the code wouldn't compile either way
<mangix>
basically, -fno-common
<mangix>
doesn't allow two c files to have identical variable names
<mangix>
(sort of)
<Tusker>
ok, so should break compiling, rather than runtime...
<mangix>
yeah runtime sounds unrelated
<Tusker>
trying gcc9 build instead then from a fresh directory
<mangix>
try using O2 instead of Os
<Tusker>
oh ok, let's see
<mangix>
that sounds more likely
<mangix>
there was a kernel config for it AFAIK
<mangix>
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
<Tusker>
so don't do : CONFIG_TARGET_OPTIMIZATION="-O2 -pipe -mcpu=8540" ?
<aparcar[m]>
mangix: not that I really understand...
<mangix>
it complains in dmesg if you're not overclocked
<mangix>
that's just brilliant
<mangix>
so they actually have a sponsor...
<mangix>
i guess some people really need extra 18.06 support.
Tapper has joined #openwrt-devel
<mangix>
hmm OK interesting. So they have one packages repo that's compatible with even 18.06. That's pretty amazing.
<Tusker>
aparcar[m]: OK, python3 is /usr/local/bin/python3 which is already in the PATH
<Tusker>
nope -O2 also hangs on gcc-10
<aparcar[m]>
mangix: why are the packages so interesting?
<aparcar[m]>
mangix: why does it complain?
<rsalvaterra>
mangix: Spying the competition? :)
<Tusker>
gcc-9 try with -Os
<mangix>
aparcar[m]: the author of that PR is trying to say MOAR POWAH.
goliath has quit [Quit: SIGSEGV]
<mangix>
rsalvaterra: one of aparcar[m] 's GitHub actions references ImmortalWrt
<rsalvaterra>
aparcar[m]: I'm a fan of zstd when there has to be a trade-off between speed and compression ratio. For the kernel and likely the squashfs rootfs, the highest possible compression ratio achievable makes more sense.
<rsalvaterra>
(Within the constraints of the target system, of course.)
<mangix>
rsalvaterra: how's DSA progress? :)
<aparcar[m]>
rsalvaterra: morning
<rsalvaterra>
mangix: Haven't tried again yet. Probably need guidance from Ansuel. :/
<aparcar[m]>
mangix: well that's nice
<rsalvaterra>
aparcar[m]: Good evening, mate! ;)
<rsalvaterra>
mangix: Just read the updates on the C7 DSA pull, I guess I'm being bitten by that POWER_ON_STRAP, aren't I?
aleksander has joined #openwrt-devel
<mangix>
rsalvaterra: most likely. bug Ansuel to add support :)
<rsalvaterra>
mangix: Because if those initvals are really important for the switch to work, the qca8k driver should be able to get them from the device tree, right?
<mangix>
no, most likely just a new device tree property needs to be added
<mangix>
those two properties were added by Ansuel when I was trying to get it working
<mangix>
another property needs to be introduced to add POWER_ON_STRAP
<mangix>
or just hardcode it in the driver :P
<rsalvaterra>
sgmii-rxclk-falling-edge and sgmii-disable-pll?
<mangix>
yeah
webguest23 has joined #openwrt-devel
<mangix>
both are useless for your unit since you have no SGMII
<rsalvaterra>
Hardcoding seems to be a nice way to fix one device and break all others. :)
<mangix>
:)
<mangix>
I ported all devices with a similar switch config to the C7 to DSA in that PR.
<mangix>
I looked at all dts files. Some devices have very strange configurations
webguest23 has left #openwrt-devel [#openwrt-devel]
<rsalvaterra>
The only other device I have is the Archer C6 v2… let me see if it's similar to the C7…
<mangix>
without hardware available, this will be very hard to test
<mangix>
nope
* mangix
checks
<mangix>
no ar8327 used
<rsalvaterra>
mangix: Are you sure? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/qca9563_tplink_archer-x6-v2.dtsi;h=fc6206d891a92249eabad471934ccade3b1ff7f3;hb=HEAD
<mangix>
actually...blockttron has a patchset for it
<mangix>
oh
<mangix>
I'm looking at v1
<rsalvaterra>
:)
<mangix>
rsalvaterra: I'm confident that's ar8337 and not 27
<mangix>
despite what dts says
<rsalvaterra>
It's a QCA8337N, yes.
<rsalvaterra>
And no POWER_ON_STRAP on the C6 v2.
<mangix>
and a situation Ansuel has probably not encountered, one CPU port
<rsalvaterra>
PORT0 PAD MODE CTRL and PORT0_STATUS are initialised to the same value as your C7.
<mangix>
which is interesting
<rsalvaterra>
mangix: Uhh… that's probably the most common scenario…?
<Tusker>
OK, gcc9 allows it to boot past initial kernel boot, but fails on illegal instruction (4) in busybox
<mangix>
rsalvaterra: for ar83xx, no
<mangix>
So this router has 1 CPU port connected to the switch and one dedicated WAN port
<rsalvaterra>
Note that the C6 v2 also has a single CPU port.
<mangix>
interesting
<mangix>
DTS lies yet again
<rsalvaterra>
Most ath79 routers I've seen are one-armed, a single eth connected to the switch and VLANs to separate LAN from WAN.
<mangix>
well, I just have a C7v2 :)
<mangix>
Anyway, do you want to test it?
<rsalvaterra>
mangix: The very common Netgear WNDR3700 also has a dedicated eth for the WAN. :)
<rsalvaterra>
mangix: Test what? The C6?
<mangix>
yeah
<rsalvaterra>
Hm… not sure. The C6 is a bitch to recover (no serial console and the TFTP is finicky).
<mangix>
flash the bootloader
<rsalvaterra>
With what? :)
<mangix>
breed
<rsalvaterra>
Hm… didn't know it supported the C6 v2.
<mangix>
I'll check
danitool has joined #openwrt-devel
<mangix>
wow this is strange
<Tusker>
turning off all -O and trying with gcc9
<mangix>
i remember flashing breed on an archer c7v4 but I don't see which binary would work
<mangix>
yeah... I wouldn't bother trying breed
<nitroshift>
rsalvaterra, mangix just to chime in re cpu ports: wrt3200acm also has one cpu port for wan and one for the switch
<mangix>
uhhhh, no?
<rsalvaterra>
nitroshift: Hm… I tought both CPU ports were connected to the switch, like on the Omnia…?
<mangix>
they are
<rsalvaterra>
So, the same as the C7 v2 and the Omnia. The WNDR3700, however, has a dedicated eth for the WAN port.
<mangix>
with the wires shorting something and breaking all operation of the router
<rsalvaterra>
aparcar[m]: I tested your Wi-Fi preconfiguration patch, but I think it's missing the openwrt_wifi_defaults file in the base-files package (the build fails complaining not being able to find it).
<mangix>
I had to rotate all the connectors 90 degrees
<mangix>
I will not question it
<mangix>
probably bad soldering
<rsalvaterra>
mangix: But for that I need aparcar[m]'s patch. :) I need to have Wi-Fi enabled at boot, after a complete wipe. ;)
<mangix>
i don't think you need to wipe
<rsalvaterra>
(That's the main reason I tested the WDR3600 before the C6.)
<mrkiko>
rsalvaterra: yes, aparcar patch is great and I hope it gets merged. I remember I pointed out the build faiulure but I might be wrong
felix has quit []
<mrkiko>
rsalvaterra: in the meantime, I solved it with http://ix.io/3z2f
<mangix>
rsalvaterra: I just boot working commit, vi /etc/config/wireless -> enabled to 1. rm /etc/config/network -> sysupgrade
<mangix>
after that just sysupgrade
<mrkiko>
rsalvaterra: works for this router, donìt know if i'll work in general
<rsalvaterra>
mangix: I'd need to change a bit more stuff, since I had the WDR3600 in production, but I see your point.
<mangix>
I mean, alternative is soldering iron :)
<aparcar[m]>
rsalvaterra: yes rigjt I thought about this patch today. I'll check it out tomorrow
<rsalvaterra>
Yeah, better keep the 880 MHz. Not much of a difference.
victhor has joined #openwrt-devel
<rsalvaterra>
mangix: Heh… got a conflict cherry-picking from your branch, for no obvious reason. :P
<rsalvaterra>
(Trivially fixed.)
<mrkiko>
mangix: how does overclocking technically happens here?
<mrkiko>
mangix: I mean how do you overclock it and what does happen?
<mrkiko>
mangix: I'm more curious about the technical aspect than the practical
dedeckeh has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
mrkiko: The clock frequency is derived from a PLL. You reprogram the PLL in order to set the frequency you want.
<mrkiko>
rsalvaterra: and you can do this from inside Linux?
<rsalvaterra>
mrkiko: Yes, if it's software-controlled. However, there are devices which don't like to be reprogrammed on the fly and crash.
<mrkiko>
rsalvaterra: thanks! Was looking at immortalwrt right now
dangole has joined #openwrt-devel
<mrkiko>
oh - it's like a parallel universe! They haven't dropped ar71xx! They also say - more devices supported. Would like some more infos on this but I guess it's definitely off-topic here.
<ldir>
rsalvaterra: I notice .66 is out
<rsalvaterra>
ldir: That was fast…!
<rsalvaterra>
I'll take it, as usual. :)
<rsalvaterra>
WTF, four reverts and a new release…? o_O
<rsalvaterra>
Ok, they seem serious enough.
victhor has quit [Ping timeout: 480 seconds]
Uphantom has joined #openwrt-devel
<Uphantom>
Hi dev, may I ask if is there any on going project with router ToTolink A720R,?
<Uphantom>
Its chipset are Realtek8197DL+8192ER+8812AR
<rsalvaterra>
Uphantom: Stay away from it. Nobody's touching Realtek SoCs, they're unsupported and undocumented.
<PaulFertser>
Except those in the switches
<Uphantom>
Oh no :( , poor me, I did buy it already. The router supports Imgp snooping/proxy, but it seems that imgp is not as good as usdpxy, as my iptv channel crash quite often compare to my previous openwrt router
<rsalvaterra>
Tough luck, I'm afraid. Like PaulFertser, only (very few) switch SoCs are supported.
<rsalvaterra>
*said
<rsalvaterra>
I understand the appeal, though… they're cheap as chips.
Uphantom has quit [Remote host closed the connection]
Tusker has quit [Quit: Time wasted on IRC: 2 hours 30 minutes 3 seconds]
Tapper has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tapper1 has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
<stintel>
hauke: see what Tusker wrote earlier today
<stintel>
hauke: probably due to -fcommon or -fno-common
kenny has joined #openwrt-devel
Borromini has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<xdarklight>
hauke: it took 2.5 weeks for me to get another "unexpected reboot" on my HH5A with https://pastebin.com/3Ff42vQM - unfortunately there's still zero output and then it reboots
<xdarklight>
hauke: last manual reboot was on Sunday where I updated to latest git master. before that it ran one week without any unexpected reboot
chadn has quit [Ping timeout: 480 seconds]
pmelange has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Tapper has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
<hauke>
stintel: the comment on github says it also works when selecting gcc 11
<hauke>
xdarklight: thanks for testing
<hauke>
xdarklight: I have no idea why it is crashing
dedeckeh has quit [Remote host closed the connection]
dangole has quit [Quit: Leaving]
pmelange1 has joined #openwrt-devel
pmelange has quit [Read error: Connection reset by peer]
<aparcar[m]>
mangix so now you hype people about immortalwrt?
<mangix>
rsalvaterra: how did that dsa fix work out?
<rsalvaterra>
mangix: No time yet. At the choir rehearsal, at the moment. 😅
<rsalvaterra>
(Quassel is amazing, by the way, really happy with it.)
<slh>
don't like it (at all) on the desktop, but for phones it's indeed pretty good
<rsalvaterra>
I have an image ready, I'll try to flash it before going to bed.
<mangix>
wow. just tested 19.07 ar71xx. it's actually slower than ath79
<mangix>
my memory was the reverse
kenny has quit [Ping timeout: 480 seconds]
<rsalvaterra>
mangix: Why should ath79 be slower? It should be just a change in configuration (device tree), nothing else.
<rsalvaterra>
What's strange is there being a noticeable speed difference between ar71xx and ath79. 😉
<mangix>
nah
<mangix>
bugfixes
<rsalvaterra>
Hm. It's possible, yes.
<mangix>
what doesn't make sense is the qca8k speedup
<mangix>
it's slower everywhere else
<rsalvaterra>
Anyway, let's not exhume that corpse, ath79 is the future.
<rsalvaterra>
Who knows, maybe it will even be upstreamed, one day! 😉
<mangix>
oh this is just for testing purposes. My memory was that there was a performance degradation from ar71xx to ath79. Numbers don't lie though.
Tapper has quit [Quit: Tapper]
<rsalvaterra>
I'm really curious to see how the WDR3600 behaves with the new image.
<rsalvaterra>
But carrying all those changes, before being definitive, is a bit of a hassle.
<mangix>
all those changes?
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
<aparcar[m]>
rsalvaterra: could you please test the wifiopt patch?
<rsalvaterra>
mangix: I have quite a few of my own too.
<rsalvaterra>
aparcar[m]: Sure, you added the missing file?
<aparcar[m]>
rsalvaterra: yas
* slh
382 files changed, 44627 insertions(+), 4758 deletions(-) at the moment (ipq807x, ipq806x-dsa, ipq40xx-k5.10, musl update, mac80211 update, the rest is trivial)
<rsalvaterra>
Ok, good to know. I'm keeping pepe2k's, though, for the time being.
<stintel>
oh, chrony just crashed again :(
<Tusker>
what reason? maybe you need to disable SMP for now...
<rsalvaterra>
mangix: The mtd-rw thingy is a nice touch. I remember I had to use a specific image with the bootloader mtd partition unlocked, at the time.
<rsalvaterra>
The module parameter is just the cherry on top. :)
<slh>
somehow I don't feel to great of having to use a translator plugin, I still have scars from the Xiaomi ax3600 webinterface running in chinese ;)
<mangix>
rsalvaterra: either works
<stintel>
Tusker: not going to do that
<stintel>
it's 4c/8t, disabling SMP will completely nuke the performance
<stintel>
might as well go back to my APU2 then
<Tusker>
understand, but at least for triage purposes, if the problem goes away if SMP is disabled, then it might help you find out why it is failing
<stintel>
I'll first do a build with global -fcommon
<stintel>
I should probably sabotage sysupgrade on my main m300 to avoid accidentally flashing it instead of the dev one
<stintel>
ah, or just disable the main one in the script I use to scp the sysupgrade image