<russell-->
the .ko's are insmod'd from a temporarily mounted filesystem
Tapper has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
owrt-2203-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2203-builds has joined #openwrt-devel
owrt-snap-builds has quit [Remote host closed the connection]
owrt-2203-builds has quit [Remote host closed the connection]
owrt-2102-builds has quit [Remote host closed the connection]
owrt-2102-builds has joined #openwrt-devel
owrt-snap-builds has joined #openwrt-devel
hanetzer2 has joined #openwrt-devel
owrt-2203-builds has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
hanetzer3 has joined #openwrt-devel
hanetzer2 has quit [Ping timeout: 480 seconds]
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
owrt-2203-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds_ has joined #openwrt-devel
<russell-->
between the microcontroller and the i2c optoisolator (ti is01540) there is constant i2c chatter
owrt-2203-builds has joined #openwrt-devel
owrt-2203-builds has quit [Remote host closed the connection]
owrt-snap-builds_ has quit [Remote host closed the connection]
owrt-2102-builds has quit [Remote host closed the connection]
owrt-2102-builds has joined #openwrt-devel
owrt-snap-builds has joined #openwrt-devel
owrt-2203-builds has joined #openwrt-devel
cbeznea has joined #openwrt-devel
<russell-->
starting to think the E in E23068 is Engenius and it's a rebranded stm32
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<russell-->
i think it's one of these: STM32F038x6, and the second header is the SWD
srslypascal is now known as Guest7162
srslypascal has joined #openwrt-devel
Guest7162 has quit [Ping timeout: 480 seconds]
<jow>
nbd: I wonder if we should adjust netifd to update resolv.conf.auto in-place
<jow>
nbd: as in truncate / write / flush instead of new file + move
<jow>
the changing inode on update will complicate jailing
<Habbie>
there are also dragons in in-place updates
<jow>
I know that we moved those file into /tmp/resolv.conf.d/ so that we can bind mount the parent
<jow>
however not all services are able to deal with a directory of resolv files
MaxSoniX has joined #openwrt-devel
<jow>
Habbie: there's dragons everywhere
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<Habbie>
oh yes
goliath has joined #openwrt-devel
hitech95 has joined #openwrt-devel
<nbd>
jow: what's the issue with the directory? i mean if there is only a single file in there that needs to be read
<nbd>
i don't think we should switch to in-place update
<nbd>
because it opens up some nasty race windows
<hitech95>
Guys I'm facing an issue prith procd on stable 21.02.3, some services dont start automatically. hoc can I troubleshoot it?
<jow>
hitech95: logread
hitech95-mm has joined #openwrt-devel
Tapper has joined #openwrt-devel
<hitech95>
jow, logread right after the boot process? Give me a sec that I have to reboot. BTW the issue is showing on multiple divices also from my friend. Generally it is adblock and ddns that dont start. service statuses: https://pastebin.com/BfvRsCbs
hitech95 has quit [Remote host closed the connection]
<hitech95>
If I search for ddns only one script is executed and it is the only one that is marked as disabled (1 out of 3)
<hitech95>
of adblock I have no match in the log
<hitech95>
if I start the servcices manually they work fine
<jow>
maybe they are coded to not start on boot
<jow>
nbd: the problem appears to be some race condition, I'll think some more about it
<hitech95>
jow: dont thinks so. I've never had this kind of issue before to be honest. You can see that the service is enabled bbut not running, when stared manually it start correctly: https://pastebin.com/Ypu3FdnL
<jow>
both have nonstandard onboot handling and rely on hotplug invocation
<jow>
do you have ntpdate installed by any chance?
<jow>
it is known to break (stall) hotplug
<hitech95>
jow: oh ok so its a n issue with hotplug then... this is interesting. my wan is a virtual/floating inteface.... and this might be the issue. Now I have to understand why it happensds also to some my friends that uses ppp
<hitech95>
ntpdate is not installed
<jow>
hitech95: maybe something else is amiss then
<jow>
right after boot, run "ps wwww" and see if you have lingering hotplug-call processes
<hitech95>
jow, yep the issue are mostly to my friends atha are not tech savvy to know that something is not booted in the their router... especially for ddns
<jow>
that ddns stuff is ripe for a rewrite anyway
<hitech95>
This summer (on holiday) I would love to update some patches I have for luci and get them merged (if approved). I would love to have some feedback on them!
robimarko has joined #openwrt-devel
<hitech95>
hi robimarko, how is it going with the rb5009ug?
<robimarko>
Its not going, havent touched it in a long time
<hitech95>
no problem :D I was courious if some progress in uboot/2.5g PHY was done :D
privPet has joined #openwrt-devel
<privPet>
Heia. How would I make a package depend on a certain router model? Is that even possible?
<privPet>
I want to ensure that my package can only be installed on a given device
<slh64>
no, you can only limit package dependencies to a target (architecture), but it will always be available to all devices of the shared target. what you can do, is adding safe guards to your code not to do potentially harmful operations on different devices (rendering them a no-op), other than wasting space
<privPet>
allright, thanks for the quick response!
Misanthropos has quit [Remote host closed the connection]
SlimeyX has quit [Read error: Connection reset by peer]
privPet has quit [Quit: Page closed]
borek has joined #openwrt-devel
<russell-->
found the serial pins on the microcontroller, seeing 12 byte packets at 115200
<f00b4r0>
nbd: fyi I have a reduced test case for the bug I'm seeing. I have been able to confirm that it only affects wireless clients roaming ("roaming" a wired client between two APs does not trigger the bug). The most obvious symptom in captures so far is that during the blackout, DHCP Reply frames vanish. They do not even appear on the DSA physical interface. I'm trying to find a way to sniff the master interface now. Is there anything else I
<f00b4r0>
can check?
SlimeyX has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
<f00b4r0>
crap. So if I read the code right, libcap has no support for mtk DSA tags
<russell-->
so, the speed is one problem right off the bat, realtek-poe hardcodes 19200
* f00b4r0
discovers editcap, notices it can "solve" his problem
<f00b4r0>
the plot thickens. DHCP replies are also not seen on the master DSA iface
hitech95 has quit [Remote host closed the connection]
slh has quit [Read error: Connection reset by peer]
slh64 has quit [Read error: Connection reset by peer]
slh64 has joined #openwrt-devel
slh has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
<f00b4r0>
ha, even weirder. tcpdump seems unable to run filters (host/port) on the DSA slave interface when using vlan
<Slimey>
hurricos i have the firmware for the new waps if your interested
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Slimey>
they didnt encrypt it this time for some reason
slh has quit [Ping timeout: 480 seconds]
slh64 has quit [Ping timeout: 480 seconds]
MAbeeTT5 has joined #openwrt-devel
MAbeeTT4 has quit [Ping timeout: 480 seconds]
<nick[m]1234>
mrkiko: i See you already found it :)
<mrnuke_>
russell--: do you have a packet dump?
<f00b4r0>
what's the current preference for bug reports? Mailing list or GH issue?
<mrnuke_>
f00b4r0: I'd go with patches that fix the bug. Best bug reports ever -- don't even have to do anything about them
<f00b4r0>
yeah sure.
<f00b4r0>
except this is way beyond my ability to provide a patch.
<f00b4r0>
at least I have a reduced reproducible testcase. Which is not so bad I shall hope.
mircMin has joined #openwrt-devel
valku has joined #openwrt-devel
<mircMin>
Is that possible to build a package (make package/foo) only w/o building dependencies?
<jow>
mircMin: no
<mircMin>
:(
<jow>
if the dependencies aren't actually needed at build time (e.g. they're only logical and not, say, shared libaries being linked) then you can simply comment them out in the Makefile
<f00b4r0>
i'll start with email. I can always open a GH issue later after all
valku has quit [Quit: valku]
valku has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
ts has joined #openwrt-devel
mircMin has quit [Quit: Page closed]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
cbeznea has joined #openwrt-devel
<hurricos>
russell--: Oh, good. I will spin up a PR during my lunchtime to add the MCU to the device tree.
<hurricos>
Assuming I can find another device tree anywhere that does anything vaguely similar T_T
MaxSoniX has quit [Quit: Konversation terminated!]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<hurricos>
Yep. There is precedent for adding a UART-connected MCU to a device tree :D
<hurricos>
svanheule: has any effort been made to upstream realtek dtses, or is that impossible given the state of the target?
<hurricos>
I don't want device-tree MCU configuration stuck downstream.
<svanheule>
hurricos: there is at the moment a single DTS upstream, for the Cisco SG220-26G
<svanheule>
hurricos: the very little information that is in it, is wrong >_>
<hurricos>
sigh
<svanheule>
it was provided as a proof of concept with the initial set of platform patches. But as it was a stripped down version, it was probably never really tested :-/
<hurricos>
svanheule: Do we not have board support for the SG220-26G? I don't see it in the openwrt tree.
<svanheule>
it isn't in OpenWrt, no
<svanheule>
the person upstreaming didn't care about OpenWrt
<hurricos>
I see.
<hurricos>
And at that pricetag I sadly do not care about the SG220-26G
<svanheule>
AFAIK I am the only other person with that device, but I should be submitting more DTS files instead of just putting the device documentation on the wiki
<hurricos>
svanheule: I know there are a lot of OpenWrt specific-ish features in them, but would you reckon the ZyXEL(s) would be OK to upstream first? I'm not aware of any platform specific setup for them
<svanheule>
hurricos: somehow we were able to buy 4 of them for €280
<svanheule>
the GS1900 series?
<hurricos>
Yeah.
<hurricos>
Hold on, I haven't actually looked at them. I'm going to guess it'll cause some point
<hurricos>
pain*
<svanheule>
they are easily found, not too expensive, don't run restrictive vendor FW; would be a relatively good fit I think
<hurricos>
Right, but is .. realtek DSA upstreamed?
<svanheule>
nope, none of the networking stuff is upstreamed, nor is it currently in an upstreamable state
<hurricos>
I also see that we make heavy use of macros from rtl838x.dtsi, which are all intertwined w/ the DSA driver
<hurricos>
Oh, but none of those macros evaluate out to nonstandard stuff.
<svanheule>
is much of it non-standard? It's hard for me to tell, since I've only really provided bug fixes for the DSA driver
<svanheule>
hurricos: thanks for answering my question before you got it :)
<hurricos>
I just don't see cases where macros like this get used elsewhere in device trees :P
<hurricos>
and I don't want to uglify OpenWrt's implementation.
<svanheule>
I'm rather neutral about those macros, but there are other who dislike them
<hurricos>
svanheule: linux-mips would be the destination for the DTSes, no?
<svanheule>
they're not obvious, but OTOH defining 50 ports is also quite the hassle
<svanheule>
hurricos: I think so, yes. current DTS is in arch/mips/boot/dts/realtek (IIRC)
<hurricos>
correct.
<svanheule>
I did submit patches to change the SoC irq binding a while back
<svanheule>
but due to holy ABI stability (for whom exactly, in this case?) I haven't been able to convince the irqchip maintainer to accept those changes
<svanheule>
OpenWrt currently has a different IRQ binding than upstream
<hurricos>
svanheule: which patch-file?
<hurricos>
I'm seeing nothing major in target/linux/realtek/patches-5.10 that's not upstreamed
<svanheule>
hmm, maybe Birger just applied those changes to his tree then?
<hurricos>
is there any longer a copy of bkobl/openwrt, or is it all gone?
<hurricos>
Oh
<svanheule>
I git-fetch'ed it just as he was closing his PRs...
<hurricos>
wait. doesn't matter. As you said OpenWrt mainline doesn't depend on it
<hurricos>
it'd be good to have but it's not something we rely on now :P
<svanheule>
stupid thing is, the current IRQ implementation with interrupt-map is wrong, but the maintainer and DT maintiner didn't notice on the initial submission
<svanheule>
that caused broke IRQs on one of the recent kernels, and required a quirk to be introduced for a few chips, among them the realtek irqchip
<svanheule>
I didn't want to submit them until they got accepted upstream
<hurricos>
That was a good call :)
<svanheule>
doesn't mean I don't want them in though :P
<mrnuke_>
Will the realtek target be moved to 5.15, or more likely straight to the next LTS llinux?
<svanheule>
mrnuke_: must go to 5.15 first, since that will be the next OpenWrt release
<svanheule>
musashino was looking into that, and that should probably be on the top of our priority list ATM
<svanheule>
should allow us to drop some patches, catch up with upstream DSA (and other changes)
<mrnuke_>
svanheule: I like that plan
<hurricos>
rtl838x.dtsi upstream is licensed GPL-2.0-or-later OR BSD-2-Clause. Am I right that nobody will have an issue if I *ADD A LICENSE* to stuff I upstream?
<hurricos>
It's a device tree, most of the OEM devices run a BSD fork anyways.
<hurricos>
oh. wait, we already OR MIT. I'm blind.
<svanheule>
:P
<hurricos>
svanheule: I'm going to start by trying to upstream rtl838x.dtsi, so I apologize for the deluge of questions.
Tapper has quit [Ping timeout: 480 seconds]
<f00b4r0>
hurricos: if you are the author you can license however you please. If you aren't, it's generally frowned upon to relicense. Then again, I suspect DTS licensing is unenforceable anyway in most jurisdiction, since DTS is pure description
<hurricos>
I'll probably submit tomorrow, my lunch is almost over and I have to go convince the company that we should do real code review
<svanheule>
hurricos: try to make sure nobody rage quits the company over that discussion
<f00b4r0>
lol
<hurricos>
f00b4r0: MIT is BSD-2-clause compatible, isn't it?
<hurricos>
BSD2clause is more restrictive
<f00b4r0>
hurricos: I don't know. The point is that only the copyright holder can relicense.
<hurricos>
Similarly to how one can combine GPL and MIT works and relicense as GPL.
<hurricos>
I'm combining (submitting patches to) GPLv2 or BSD2 code.
<f00b4r0>
then again most of these files have no copyright marks, and as I said, my opinion is that license on DTS files is completely moot. But I may be wrong on that.
<hurricos>
OK, I can accept not thinking beyond device trees for today.
<hurricos>
I'll ask about code ;)
* mrnuke_
hopes he doesn't fall out of a (device)tree
<f00b4r0>
what I can tell you is that if you take my code and publish it elsewhere with a different license, *I* am going to be *very* cross with you :)
<svanheule>
hurricos: will you do a maple-only (rtl838x) DTSI, or will you try sharing features with rtl839x?
<hurricos>
svanheule: Are you asking me to read two device trees on one day? smh
<svanheule>
:P
<hurricos>
svanheule: I'm not sure yet. RE: Lexra, are the bindings for that stuff upstream? I should probably grep before saking
<mrnuke_>
hurricos: you can go past midnight. That counts as more than one day ;)
<svanheule>
I was going to add that I would prefer split DTSI-s
<mrnuke_>
^ +1
<svanheule>
i.e. one per SoC gen
<hurricos>
Oh, absolutely
<hurricos>
I'm not smart enough to rework what's in dts-5.10. But more significant than that, I'm lazy.
<hurricos>
I'm not going to want to hear the people who actually wrote code depending on what I'm trying to upstream, telling me how I've created more work for them.
<hurricos>
Listening to that is work.
rua has quit [Quit: Leaving.]
<svanheule>
hurricos: the Unifi Switch Lite 16 PoE is another device using I2C for PoE control, but also going to be pretty expensive
<hurricos>
svanheule: I already paid the $150.
<hurricos>
No, I'm only upstreaming so I can make the trees dirtier and add the UART-connected MCU to deal with russell--'s problem
<hurricos>
tbh we could circumvent the whole issue by refusing to specify baud rate while opening the device, and setting the baud in the device tree
<hurricos>
but I'm going to be honest, I don't want to be the lazy asshole that prevents some charismatic genius from convincing kernel to accept an in-kernel driver for these things one day
<hurricos>
easiest way to do that is to be lazy with the device tree
<mrnuke_>
hurricos: alternatively, that can be on the 02_network script, which then is used to generate a poe config file
<hurricos>
Since it sounds ok, I will just try rtl838x.dtsi upstreaming for now. I will get three patches together that take care of 1- clock replacement; 2- new bindings (have to check each of these compatibles), 3- all of these macros. I want 1 and 2 to survive if 3 won't.
<hurricos>
mrnuke_, I know, but nobody really likes those.
goliath has quit [Quit: SIGSEGV]
<hurricos>
Not really the right use-case. There's no ambiguity here as there is with WAN / LAN setting on two-port APs
<mrnuke_>
hurricos: I feel a bit guilty for using /proc/devitree/compatible for that quirk. It opened the gates for getting info from different sources
<hurricos>
mrnuke_: It might go away, who's to say. You saw the same witchcraft being done in the pulseview dump, rght?
<hurricos>
It's unfortunate. I really wish we had firmware sources; that would take the ambiguity away and we'd know *why* it works. Perhaps someone had a good reason. Perhaps that good reason can be reliably linked to the actual objects in the device tree.
<hurricos>
I'm going to guess there's no good reason., and if the sources were open we could fix and forget.
<mrnuke_>
hurricos: that's where I got it from. I'm okay with having the quirk! I just don't like that I had to parse the devicetree from userspace to enable said quirk.
kenny1 has quit [Ping timeout: 480 seconds]
<mrnuke_>
I honestly think somebody tried the default code, it didn't work, and they just started rpobing IDs. They got to '7', it worked, bug closed, move to next issue
<hurricos>
I know, I know. Usually done from board.d. I just hate when stuff goes there for no reason.
<hurricos>
it made sense for sourcing radio calibration data .. but where did that go? nvmem-cells, and that works AMAZINGLY now.
<mrnuke_>
I agree that devicetree is the best unified source of information. The caveat is that there must be a kernel driver to consume said information
rua has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
<hurricos>
I think you just need a consistent reason to consume the information, not a driver. A driver requires a consisten reason, otherwise maintainers will reject the patches
<mrnuke_>
I don't think compatible = "openwrt,realtek-poe,use-in-userspace"; will fly
<hurricos>
You need to, rather, be able to point to the most raw source of truth as to why <behavior>
<hurricos>
why point to a random offset in flash? Because the OEM manufactured 100K+ of these devices and put it there.
<hurricos>
The same discussion is harder to do here because we neither have documentation nor source for the firmware.
<hurricos>
ath9k has no firmware ;^)
<mrnuke_>
"random", or "arbitrary" offset in flash?
<hurricos>
nvmem cells for ART partitions
<hurricos>
That was the comparison anyways
<hurricos>
for why what appears to be witchcraft is actually really sensible
<hurricos>
We know that most vendors stick art / radio calibration partitions in flash to save on BOM. It's a consistent pattern that kernel maintainers accept because their drivers consume them ... but the drivers consume them because that's what AR/QCA designed. There's no concern out there that suddenly everything will be wrong -- that suddenly Qualcomm will distribute a firmware
<hurricos>
revision that breaks calibration, and that all device trees will need to change to fix it
<hurricos>
I mean, nvmem-cells isn't a specific binding for ath*k calibration.
<hurricos>
But the same is difficult to say when we're setting up a description for an mcu present on these boards.
<hurricos>
If we want to describe in the device tree what's going in a way that's specific -- describe [fact which delineates boards requiring power-on on ID 7 from those that do not] -- we need to know why that's true
<hurricos>
"What" from "why", and then "why" from "how" ... and if the MCU firmware ever changes, so does "how"
<hurricos>
sorry, you don't need to hear my diatribe
<hurricos>
I'm saying, I really wish I knew more about the MCU f/w so I could justify fully describing it in the device tree
<hurricos>
I'm going to guess our >12 port boards will all need it.
<hurricos>
We could parse the device tree to see how many PoE ports there are and go based on that.
<hurricos>
That would probably do it once we have more PoE boards out there.
<hurricos>
Then you can start on your path of redemption mrnuke_
<hurricos>
svanheule: how does the RTL8318b carry 8-ports of GMAC over QSGMII?
<svanheule>
rtl8218b? 8 ports over dual-qsgmii
<hurricos>
oh.
<svanheule>
not sure if it presents itself as 2 quad-port phy-s, or if the qsqmii links are trunked into one
<hurricos>
Never mind. That should have been obvious. Thanks.
danitool has joined #openwrt-devel
<mrnuke_>
hurricos: do we have somewhere documented a set of board/MCU FW rev and PSE ID for budget?
<mrnuke_>
really really curious if there's a correlation with the MCU firmware version
<mrnuke_>
hurricos: speaking of realtek-poe, that Norwegian patch looks fine and okay to me
<hauke>
hurricos: Probably one target after the other will move to 5.15
<hauke>
I do not think the 22.03 release is really blocking there
fuego has quit [Quit: Page closed]
<hurricos>
hauke: Thank you. I will try to push mpc85xx and test the boards I have.
<hurricos>
realtek first for now ...
Tapper has joined #openwrt-devel
bluew has joined #openwrt-devel
robimarko has joined #openwrt-devel
<russell-->
mrnuke_: right now, i have a sigrok save of a long section from power-up. apparently sigrok can't save uart decodes separately (or i couldn't figure out how)
<Habbie>
it definitely can but i couldn't tell you how right now
<Habbie>
i also always get lost
<Habbie>
no, sorry, i'm thinking of Pulseview
hitech95-mm has quit [Read error: Connection reset by peer]
<mrnuke_>
russell--: can that be imported into pulseview? Seems like the easiest way to go
bobthebuilder has quit [Read error: Connection reset by peer]
<russell-->
does anyone know about the wire test function that the vendor firmware provides? does some kind of time-domain reflectometry cable length measurement, checks individual pairs etc.
hanetzer3 has quit []
hanetzer has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<mrnuke_>
russell--: I doubt it does TDR in real-time. More likely estimates based on line resistance
<russell-->
mrnuke_: can you educate me on how you extracted that?
<mrnuke_>
russell--: save the decoder data from pulseview as "binary". Then do `hexdump -e'12/1 "%02x ""\n"' pv-saved.bin`
<russell-->
thanks
<mrnuke_>
The other option is `magic < sigrok-ews2910p-v3-poe-serial-capture.sr > working-rtl-poe.elf` but couldn't quite get the `magic` command to work as intended
<mrnuke_>
russell--: dump looks very similar to old broadcom protocol, but different just enough for them to be incompatible
<russell-->
sounds like realtek-poe needs some command line switches
<mrnuke_>
neah. just a config entry for "protocol" valid values ["broadcrap", "unrealtek"]
<mrnuke_>
russell--: did you happen to have a PoE device connected when you took the trace
Tapper has quit [Ping timeout: 480 seconds]
<russell-->
mrnuke_: i don't think so, but possibly something in port 3
<russell-->
actually, i think there's a probability of about 0.8 (80%) there was a poe device connected to port 3
<mrnuke_>
makes sense. I'm seeing queries with an argument of 02, which return back varying values
<russell-->
i can do more traces with the load in different ports, if that would help
<mrnuke_>
russell--: too early for that. I'm hoping I can map the command IDs to the old protocol
<mrnuke_>
we already know the format of the old protocol, so if we can prove the commands are a 1:1 map with different IDs, we're cooking with induction