<robimarko>
I will never understand why people are doing that
<robimarko>
You are basically converting OpenWrt back to stock FW
<Znevna>
the wifi part at least
<robimarko>
They did the networking as well, not in that thread
<Znevna>
pft
<robimarko>
But there is networking and offloading from stock FW as well
<mrkiko>
robimarko: stop reading ...
<mrkiko>
:D
<oliv3r[m]>
Is it possible, to define a u16 (array) in the devicetree, and then OR bits together? e.g. I want to do `led_set0 = /bits/ 16 <0x0000 (FIELD1 | FIELD2 | FIELD3)>;` e.g. would the parenthesis help/are they required? ( I would expect it so?)
<robimarko>
mrkiko: Those dont bother me anymore
<robimarko>
I stoped caring a long time ago
<oliv3r[m]>
could I also use `led_set0 = /bits/ 16 <0x0000> <FIELD1 | FIELD2 | FIELD3>;` instead? or what other magic could I use?
<oliv3r[m]>
should be some possibility right? as I see AM33XX_IOPAD(0x9b4, PIN_OUTPUT_PULLDOWN | MUX_MODE3) for example if I grep for it
<robimarko>
dtc is not going to do that for you
<oliv3r[m]>
I thought the kernel was using cpp as preprocessor regardless? e.g. how is upstreaem kernel doing that in the AM3XX case? (the only diff. being that the macro forces parenthesis around it)
<robimarko>
Yes, you should be able to do it with a macro
<oliv3r[m]>
because the macro forces it through the preprocessor?
<jow>
robimarko: could imagine that this effort is for creating dd-wrt-esque downstream firmwares
<jow>
openwrt just happens to be the facilitator (in terms of providing toolchain / image packing tools and/or community support platform)
<jow>
I somehow doubt that this is private enthusiasts seeking to squeeze more perf out of their boxes
<mrkiko>
robimarko: in your opinion, would it be feasible to merge only the "fan" related DTS changes for the Zyxel NBG7815 ? Or would it be better to have a more general solution ?
<robimarko>
jow: Yeah, they use use the infra
<robimarko>
mrkiko: DTS changes for it are worthless as they are exposing the fan as GPIO
<robimarko>
What I proposed it to register it as gpio-fan
<robimarko>
And then you can attach it as active cooling device directly in DTS
<robimarko>
Cause its ON/OFF anyway
<robimarko>
jow: Any chance you can take a look at those OPKG patches?
<robimarko>
I am hearing just seeing whole thread of complaints because ASU doesnt work
<robimarko>
And its not ASU-s fault
<mrkiko>
robimarko: yeah, good point
<mrkiko>
robimarko: the problem is - I'm little bit worried about devices getting too hot; wondering if having at least the option to keep the fan constantly on would be better than having it constantly off for the times being...
<robimarko>
mrkiko: If they made the heatsink properly its not gonna be overheating
<robimarko>
Worst case scenario you are gonna trip the passive thermal trips and cpufreq is gonna throttle
<mrkiko>
robimarko: OK, thanks
<robimarko>
What I asked in the PR is easy to do, no idea why it was not implemented
<robimarko>
Its easier then using an userspace script with harcoded paths and everything
danitool has joined #openwrt-devel
<Znevna>
couldn't resist not to ask
<Znevna>
and reported
<Znevna>
ez
<gch981213>
robimarko: The proprietary vendor driver is more stable than the one in Linux when the open-source one isn't made by the chip vendor themselves. I used to do that on mt7620 back in 2015.
<gch981213>
robimarko: Nowadays I decided it doesn't worth my time so all my mt7620/mt7612e routers are on the shelf doing nothing. :P
<robimarko>
gch981213: why not just use stock FW?
<gch981213>
robimarko: You can't install plugins there.
<Znevna>
it looks pretty stable here
<robimarko>
gch981213: Sure you can, just use the MTK SDK which is fresh 17.01
<Znevna>
fresh :P
<dhewg>
bleeding edge from a vendor's perspective
<gch981213>
robimarko: The fw provided by vendor can't though.
<gch981213>
LEDE MTK SDK wasn't a thing in 2015.
<gch981213>
It was one based on Barrier Breaker with Linux 3.10
<gch981213>
and I hate how MTK configures their wifi.
<robimarko>
You dont like non cfg80211/nl80211 drivers?
<robimarko>
I always find it fascinating that they seem to reinvent some weird config format
<gch981213>
robimarko: Not that. MTK doesn't use netifd and wrote their own.
<robimarko>
Well, I would be surprised if they did not
<gch981213>
robimarko: They've been using that config file since the WEXT days and never bother to upgrade to cfg80211.
<gch981213>
It isn't reinvented :P
<robimarko>
That just makes it even worse
<gch981213>
Yes. Just a ton of ancient code.
<Znevna>
Asus uses something called "OpenWRT SDK_4210" :P
<gch981213>
Znevna: 4.2.1.0 is their Linux SDK. It isn't based on OpenWrt.
<robimarko>
Other vendors are starting to do the same
<robimarko>
They are now dropping the based word
<Znevna>
gch981213: any ideea how we find the proper value for mediatek,bmt-max-reserved-blocks = <64>; ?
<gch981213>
Znevna: I remember nbd said it doesn't need any override?
<Znevna>
that was about force-create I think
<nbd>
the reference code that i was pointed at had default values
<nbd>
and force-create is not used
<Znevna>
so we can omit the reserved blocks?
<Znevna>
max-reserved-blocks*
<nbd>
yes, i think so
<Znevna>
ok, thank you
<xback>
f00b4r0: I'm not missing the issue or blindly ignoring it :-)
<xback>
I'm questioning it as the reboot is always at exactly the same point even with jitter due to context switching over such a period of time
<stintel>
xback: can you check `ubus call system watchdog` ?
<xback>
stintel: sure. Just arrived at the office and will start investigating further now
<stintel>
on qoriq/m300 the problem was that watchdog was modular, procd starts watchdog before kmodloader runs, so the watchdog wasn't started, then during sysupgrade, procd does watchdog handover, which in this case started the watchdog, and this particular watchdog didn't like procd default watchdog values and after X time watchdog reset the system
<stintel>
usually before sysupgrade finished because I had a couple of larger files in /tftpboot that needed some time backing up
<xback>
stintel: can you elaborate where to check this exactly? it will speed up testing a lot
<stintel>
just run the ubus command
hanetzer has quit [Quit: WeeChat 3.8]
<stintel>
in the case of the m300, the watchdog was not running
<xback>
{
<xback>
"status": "running",
<xback>
"timeout": 30,
<xback>
"frequency": 5,
<xback>
"magicclose": false
<xback>
}
<stintel>
ok so it's not the same issue as on qoriq/m300
<stintel>
maybe still, the watchdog doesn't like the handover procd does during sysupgrade
<xback>
stintel: but in your case, did it cleanly reboot or just reboot without any closure
<robimarko>
Is this the imx I am seeing in emails?
<xback>
as in this case, alle attached devices are first properly closed before reboot
<xback>
robimarko: yes
<stintel>
xback: watchdog reboot is hardware reset
<xback>
stintel: exactly my point
<stintel>
xback: so I guess it's not the watchdog
<robimarko>
If its cleanly rebooting it aint WDT
<xback>
which is the reason I'm not blindly following the WDT stuff in mails
<stintel>
then I will withdraw from the discussion ;)
<robimarko>
Does this usually get printed before reboot?
<xback>
the log shows a nice clean reboot with drivers being unload first etc
<mrkiko>
Out of curiosity - what happened when gl.iNet submitted the gl-b2200 support? I am genuinely curious - did someone tell them their submission was not complete and hence not acceptable (e.g.: because sysupgrade support was missing)?
<f00b4r0>
ok so it confirms you get a clean shutdown
<robimarko>
Thats weird, but maybe the WDT is being used to reboot
<f00b4r0>
but that shutdown is apparently premature
<xback>
robimarko: it is on purpose
<mrkiko>
anyway I agree with you robimarko; to me it seems e are on a kind of a situation where the openwrt project doesn't react because we hope them not to close down things too much, and they try to not close down things too much because they know they need openwrt. Am I wrong?
<xback>
Gateworks ventana uses pmic to powercycle the whole board. not the internal imx6 registers
<f00b4r0>
have to run, bbl
<xback>
the dts contains a few lines which registers the WDT to trigger a GPIO to an external pmic
<xback>
this way all attached pheripherals are rebooted too
<gch981213>
mrkiko: I guess everyone forgot to check that.
<mrkiko>
But probably I'm wrong on my thinking - and probably all those vendors simply don't care too much in general, also because they have to respect qca/mtk/whatever rules
<robimarko>
xback: Ok, that makes sense
<Borromini>
mrkiko: they buy their stuff from QCA/MTK/...
<gch981213>
mrkiko: It seems that router vendors don't get access to the complete chip manuals nowadays. Even if they want to contribute upstream, they have to guess how the chip works from the garbage code written by chip vendors.
<Borromini>
ultimately those are the guys that deliver the SDK, so you have to make do
<mrkiko>
so, they are in a similar position as we are but with pretty different objectives
<robimarko>
gch981213: My bet is that they dont even ask, its way cheaper and faster to just not ask
<robimarko>
And use the SDK, then you just make support cases and thats it
<mrkiko>
Thank you all guys for your explanations and patience. I apreciate them
hanetzer has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
<gch981213>
robimarko: QCA doesn't provide manuals for IPQ stuff unless you are a big client and sign a separated NDA for those. But I agree that most of the time router vendors don't care about upstreaming at all.
<robimarko>
Exactly my point
Znevna is now known as BinaryBob
<mrkiko>
BinaryBob: don't do that, you remember me that day of the guy attacking stintel ...
<stintel>
impersonated by a troll on IRC and ML yes
<stintel>
because I told them they need to put the device specs in the commit message
<stintel>
and then the typical kiddie ban evasion and ascii farting in the channel
<robimarko>
You gotta hand it to him, he was persistant
<stintel>
I disagree, he gave up within 24h
<stintel>
s/he/they/* before I get the woke police on my back
<robimarko>
Lets just use it
<mrkiko>
but ok guys, an urgent decision needs to be made regarding forum moderations and so on
<Borromini>
Znevna: that Annick got some screws loose.
<Znevna>
I don't vouch for the other one either :P
<Borromini>
:P
<Borromini>
but hey, the blind leading the blind
<mrkiko>
Borromini: uh, didn't know this "way of saying"
<Znevna>
someone with higher powers will take the appropiate action
<Znevna>
appropriate *
<Znevna>
but I like how the "dev" just pointed this out "i do not have any device so it's not easy, what is not working?" ^^
valku has joined #openwrt-devel
<gch981213>
lol
<gch981213>
Why does he make that firmware if he can't benefit from it himself?
<Znevna>
to quote him, "is to walk with hands on the ground"
<gch981213>
Znevna: What does that even mean...
<Znevna>
¯\_(ツ)_/¯
<stintel>
loosely translates to "I'm a troll"
<gch981213>
stintel: :D
srslypascal is now known as Guest2403
srslypascal has joined #openwrt-devel
valku has quit [Remote host closed the connection]
<oliv3r[m]>
robimarko: the dtc lets you do all sort of stuff, but you have to put stuff in paranethis, the pre-processor doesn't do those evaluations ...
<robimarko>
Oh, that is nice
Guest2403 has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko: (or anyone testing ath11k): did you experience latency spikes when pinging a 2.4ghz client from a 5 ghz client or the other way around?
<robimarko>
Cant say I tried that
minimal has joined #openwrt-devel
<mrkiko>
if you need some sample data, let me know :D - all the rest works great it seems
<robimarko>
mrkiko: It could be the bridge causing spikes
<robimarko>
nbd: Does bridger work on all HW?
<mrkiko>
robimarko: but it tends to happen more markedly when taling from client to client, with peaks of e.g.: 237 ms ping time
<mrkiko>
and when 2.4ghz is involved in the loop
<robimarko>
That is screaming some kind of a buffer
<mrkiko>
But ok, think it's time for me to get a pause from the PC. Thanks to all of you for all and for the great work. Keep it up
<mrkiko>
and talk to you soon
<nbd>
robimarko: its software offload part works on all hw. actual hardware offload is only supported on mtk for now (via WED)
<nbd>
but the offload API is generic
<nbd>
(tc-flower + redirect)
<nbd>
so if somebody were to implement the same APIs, it could potentially work for nss-offload with ath11k
<robimarko>
nbd: Thanks, it couldnt hurt to see how much it improves the perf
<stintel>
bridger was causing issues for me sometimes when a client roamed from 1 AP to the other, I had no time to debug that at the time so I stopped using it, is this something you remember fixing ?
Borromini has quit [Ping timeout: 480 seconds]
<nbd>
could be
Ansuel has joined #openwrt-devel
<Ansuel>
o/
dangole has joined #openwrt-devel
Ansuel_ has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
<Tapper>
I have a build messing up because of binutils-2.40. Should I report a bug or is it none about?
<Tapper>
known*
<Tapper>
target is ramips
<dhewg>
works for me, ramips/mt7621
<dhewg>
started from clean build dirs?
<Tapper>
No but I did a make clean befor starting the build