<Ansuel>
nice i moved all the phy led configuration to a trigger
<Ansuel>
now i need to polish
kenny has joined #openwrt-devel
lmore377_ has joined #openwrt-devel
lmore377 has quit [Read error: Connection reset by peer]
Ansuel has quit [Read error: Connection reset by peer]
kenny has quit [Ping timeout: 480 seconds]
strobo has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
strobo_ has quit [Ping timeout: 480 seconds]
<stintel>
alright, finally contacted WatchGuard to request GPL sources for M300
kenny has joined #openwrt-devel
kenny has quit []
kenny has joined #openwrt-devel
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
Tapper has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
lmore377_ has quit [Ping timeout: 480 seconds]
slh has quit [Remote host closed the connection]
slh64 has quit [Quit: gone]
slh64 has joined #openwrt-devel
slh has joined #openwrt-devel
jlsalvador has quit [Quit: jlsalvador]
dangole has joined #openwrt-devel
Borromini has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
rmilecki has joined #openwrt-devel
danitool has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
Borromini has joined #openwrt-devel
<olmari>
so... master MPC85xx kernel is apparently 5.10, and tplink wdr4900 still has propably the https://bugs.openwrt.org/index.php?do=details&task_id=4038 going on... Is there an way to biuld master with older kernel still or do I need to stick with last released version (or dig up the release where change occurred)
<olmari>
I guess I can try changegin kernel patchver in mpc85xx makefile
<olmari>
Maybe better question is that is this on anyones agenda that knows what they're doing or is WDR4900 going to be obsoleted by this :)
<olmari>
I know the general opinion of someones PPC stuff, this device is just suprisingly dandy for what it is otheriwse
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<blocktrron>
olmari: yes, you need to modify the makefile, however 5.4 support (and with it much probably the device) will be removed
<blocktrron>
In theory, one could try to build a uboot-mpc85xx which is chainloaded from the tp-link U-Boot, but I'm not aware of anyone working on that
<olmari>
blocktrron: I know the old(er) kernel needs to be dropped, just sad to see this device go, but yeah... I know I have no that kind of devskills to even attempt any form of fixing the fix that made wdr4900 keep working as long as it did :D
<blocktrron>
This problem is known since 2+ years and nobody cared about it. So I'd assume, this is where it goes
<olmari>
yeah
<olmari>
or well... "simpleimage" did work.. I mean kernel partititon growing over some arbitary tplink limit was the issue originally (or to that effect), this got fixed by simpleimage (whatever that means) bck then... but simpleimage stuff got broken on 5.10, so
<olmari>
so on 2+ years someone got interested and did something, but that fix broke again on 5.10 :)
<olmari>
Just to clarify that problem wasn't uncared for 2+ years :P
<olmari>
I do realise it can be/become uncared now :)
<blocktrron>
I wouldn't call this a fix, It's rather "buying some time to fix it"
gladiac has quit [Read error: No route to host]
gladiac has joined #openwrt-devel
victhor has joined #openwrt-devel
<olmari>
well, bought me plenty time in june 2019 ;P
gladiac is now known as Guest5239
gladiac has joined #openwrt-devel
<olmari>
Tho I'm not sure what else there is to be fixed unless changing whole bootloeader, which ins't exactly openwrt ante ither :)
Guest5239 has quit [Read error: No route to host]
<olmari>
For the interested, w/ kernel 5.4 device still got built and booted up too, so for immediate things it still works :=
tomn has quit [Quit: leaving]
<russell-->
what is simpleboot?
<stintel>
rsalvaterra: didn
tomn has joined #openwrt-devel
<stintel>
rsalvaterra: didn't you have a wdr4900 ?
<hauke>
JiiPee: for ath79 we have this loader for example: target/linux/ath79/image/lzma-loader/
<hauke>
JiiPee: on some devices we let the vendor bootloader load an extra u-boot which then loads the kernel
<hauke>
JiiPee: adding this is normally an not easy, except if there is already something for the target and it only has to be activated for an additional board
<hauke>
Tapper: currently the biggest problem are boards which have a fixedd size kernel partition and our kernel image is getting too big, dnsmasq is only user space
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
myon98 has left #openwrt-devel [WeeChat 3.3]
clayface_ has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
shibboleth has quit [Quit: shibboleth]
dedeckeh has quit [Remote host closed the connection]
<stintel>
hauke: actually gave them some more thought, and I'm thinking we should add all symbols exposed by CONFIG_KERNEL_ options to config/Config-kernel.in rather than adding them to kernel configs
<stintel>
as make kernel_menuconfig or make kernel_oldconfig will remove those symbols
<stintel>
which is probably what causes the same symbols to disappear and later be added again
<stintel>
which is an utter waste of time, resource, and also extremly frustrating
<stintel>
I hit another one when enabling FTRACE :P
<stintel>
which I had to enable for kmod-drop-monitor (CONFIG_DROP_MONITOR) which I added to be able to use dropwatch, to figure out why I'm seeing a gazillion dropped packets on the M300
<stintel>
but I'm no wiser yet :(
<stintel>
if I enable cake, all rx packets are dropped according to the counter
<stintel>
but that would mean I would have no Internet anymore, which is not the case
<stintel>
so I'm guessing the DPAA ethernet driver is just doing something stupid
<stintel>
hauke: that might actually work, I think the failure was in gdbserver and not in gdb itself
jlsalvador has joined #openwrt-devel
<stintel>
hauke: can you use a paste service that doesn't break the patch ?
<stintel>
are you using wgetpaste ?
jlsalvador has quit []
jlsalvador has joined #openwrt-devel
jlsalvador has quit [Remote host closed the connection]
jlsalvador has joined #openwrt-devel
jlsalvador has quit [Quit: jlsalvador]
jlsalvador has joined #openwrt-devel
alex_const has joined #openwrt-devel
<stintel>
argh, KASAN_VMALLOC pops up now
Andi_ has quit [Ping timeout: 480 seconds]
<stintel>
maybe arch related
<alex_const>
Hi. I'm adding a new device. When writing device tree files should I use the same partition layout as my device originally had or should I adjust it somehow for openwrt?
Andi_ has joined #openwrt-devel
<stintel>
arch/powerpc/Kconfig: select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
<stintel>
hauke: ok, can I translate that into an Ack also? then I'll push right away
<hauke>
yes
<stintel>
thanks!
<stintel>
target/linux/generic/config-5.10:# CONFIG_TIPC is not set - good, and we also don't offer it via kmod
<stintel>
so we don't need to rush a new release ;)
BorgCuba has joined #openwrt-devel
<BorgCuba>
Hi, how can I obtain an uImage when building openwrt?
<alex_const>
any help with device tree files? :(
<stintel>
alex_const: I would do an RFC patch on the ML or a GH PR with what you have already and mention what you're struggling with in the mail
<tmn505>
alex_const: does Your device boot with different layout?
<stintel>
BorgCuba: there are some examples, git grep uImage on openwrt.git should help
<alex_const>
tmn505: different from what? I used dmesg to find out the layout in vendor's firmware and translated it to my DTS. I'm just not sure if I need to change the layout for openwrt. Presumably openwrt might have other size for rootfs for example. So my question is: do I write partitions in my DTS the way they were when I got the device or somehow different?
<alex_const>
Also I noticed that when I change kernel in vendor's SDK, I get a slightly different layout - rootfs size if off by 0x100
<hauke>
alex_const: it depends on the device
<tmn505>
alex_const: usually bootloader reads part of flash and boots it, if kernel is outside of the boudaries it'll fail
<hauke>
OpenWrt is pretty flexible with the partition layout
<alex_const>
stintel: thanks, I'll do that then. Which is more active - mailing list or github?
<stintel>
alex_const: depends on who you ask, time-of-day, day-of-week, etc
<stintel>
I tend to favour ML still
<alex_const>
hauke: what info about the device is relevant here?
<stintel>
actually I could have answered: I'd start with the same layout as OEM, see if that works, if it does, go with that, submit for review
<tmn505>
yep ^^^
<stintel>
if not, gently massage it until it does :P
<alex_const>
stintel: is that normal that OEM layout doesn't have partitions such as uboot-env and art? Calibration data seems to be stored in rootfs.
<stintel>
alex_const: they might be named differently
<stintel>
yikes, caldata in rootfs seems like asking for trouble - are you sure about that ?
<tmn505>
alex_const: what's the target?
<stintel>
oh shit, I broke things
<alex_const>
stintel: they have, in this order, bootloader, nvram, factory, linux, rootfs, jffs2. rootfs is inside linux partition, everything else is separate from each other
<alex_const>
tmn505: target is ath79. SoC's name is QCN5502.
<BorgCuba>
stintel, I found some hints in other makefiles so I added this "KERNEL := $(KERNEL_DTB) | uImage lzma" to my target in "target/linux/ramips/image/mt76x8.mk". Rebuilding the kernel with "make target/linux/compile" did not generate a uImage. Not sure where this Makefile gets evaluated?
<stintel>
BorgCuba: target/linux/install, iirc
<tmn505>
alex_const: if the kernel fits linux partition then keep the OEM layout. The claibration data location is unusuall, is it stored in nvram or factory?
<alex_const>
stintel: well there's a lot of .bin files in /lib/firmware/QCA9888/hw.2/ . A lot of them have BoardData, 5G and the name of 5GHz chip in the name. I assumed it was for calibration
<alex_const>
tmn505: the only partitions mounted after boot are rootfs and jffs2. not sure if I can mount the rest - `mount` won't let me do anything with /dev/mtd{,block}1 for example
swalker has quit [Remote host closed the connection]
<stintel>
ow, miniupnpd nftables might be surprisingly easy
swalker has joined #openwrt-devel
<stintel>
firewall4 is seriously fragile
<stintel>
or it might be nftables, not enough experience with these things yet
<stintel>
install -d -m0755 /etc/config
<stintel>
install: cannot change permissions of '/etc/config': No such file or directory
<stintel>
wtf ¯\_(ツ)_/¯
Tapper has quit [Ping timeout: 480 seconds]
<alex_const>
stintel: do I need to be subscribed to the mainling list to get replies to my messages?
<PaulFertser>
alex_const: no if the person replying you is doing it properly.
<alex_const>
PaulFertser: thanks, I'm new to mailing lists hehe :)
<PaulFertser>
alex_const: mailing lists work just like plain e-mail.
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
<alex_const>
PaulFertser: should I send source code as attachments or just part of the message?
<stintel>
git send-email
<stintel>
dangole_: fyi, I read in the meeting notes you would try nftables wrapper for upnp, but as I am working on firewall4 and using upnp, I fixed it already :P https://github.com/openwrt/packages/pull/17094
<stintel>
and not with the wrapper
<stintel>
this was surprisingly easy
<stintel>
and with that I'm done breaking things for today, going to play some games on the xbox, with open NAT ;p
<dangole_>
stintel: oh nice! i didn't get to it yet, but will dog-feed your solution which looks perfect and i will see if it works next time my gf uses whatsapp on her phone
<stintel>
awesome
<stintel>
waiting for review by jow and then I'll probably land my pending firewall4 fixes and luci-app-firewall changes to work with both firewall3 and firewall4
<alex_const>
stintel: I gather it does the same as format-patch but also emails it, right?
<stintel>
alex_const: not exactly, but you can git send-email --format-patch ;)
<alex_const>
stintel: what's the workflow is I use a web based mail client?
<alex_const>
if*
<stintel>
google :P
<stintel>
gmail has smtp support
<stintel>
dunno if that's what you use but smtp is what you should figure out how to use with your mail provider
<dwfreed>
note that if you use 2fa, you have to use an app password to use git send-email
<alex_const>
stintel: yeah I know I should set up IMAP and SMTP at some point... one of the few things I procrastinate on
<PaulFertser>
alex_const: do not use a web based MUA to send patches to the mailing list, just use git send-email please.
<alex_const>
PaulFertser: even if I can make the web UI send plain text?
<PaulFertser>
alex_const: well, in this case sending the patch as e-mail text should be ok, with the right Subject. I suggest you read Linux documentation on sending patches, it has some detailed hints.
<PaulFertser>
alex_const: but any properly configured Unix host has a working MTA anyway, and git send-email requires no configuration at all to work with that.
Grommish has joined #openwrt-devel
Grommish_ has joined #openwrt-devel
Grommish_ has quit []
Grommish has quit [Ping timeout: 480 seconds]
<Slimey>
heh
Borromini has quit [Quit: leaving]
rmilecki has quit [Quit: Konversation terminated!]
dangole_ has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
<BorgCuba>
I did not succeed
goliath has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Ansuel>
tech question.... I'm looking at the tcp_no_window patch... the value has the __read_mostly tag
<Ansuel>
does removing it would cause a performance hit?
<Ansuel>
(kernel added some check for global variable and i would like to move it in a separate struct like the other variables like that but that would remove the __read_mostly tag and would cause to no be cached)
<slh>
Ansuel: quick feedback, the current state of the multi-cpu patch (built late last night) finally seems to work for me, both with software bridging (tested on my nbg6817) and bridge-vlan filtering (tested on the g10)
<Ansuel>
slh: did you test for longer time e8hack reported some problem after some time
<Ansuel>
e9hack*
<slh>
Ansuel: uptime ~14 hours now, so far it seems to be fine for me (on both routers)
<slh>
including a trunk port (two tagged VLANs, one untagged, managed switch behind)
<Ansuel>
nice! the more complex you can set the better
<Ansuel>
did you notice some perf degradation ?
<slh>
that's a little hard to judge - the nbg6817 with software bridging is back to full speed (420/220 MBit/s WAN), the g10 seems to achieve ~300 MBit/s with bridge-vlan filtering (iperf3)
<slh>
next plan ist moving the nbg6817 to bridge-vlan filtering, now it's working (with multi-cpu support)
<slh>
I'm not quite sure if that's down to ipq8065 vs ipq8065 or down to my (different) testing methods yet
<slh>
err, ipq8065 (nbg6817) vs ipq8064 (g10)
<Ansuel>
well it would makes sense ipq8065 runs at 1.7ghz instead of 1.4
<Ansuel>
also higher chache
<Ansuel>
(you can consider overclock if you really want :DDDD)
<Ansuel>
(I overclocked my r7800 to 1.9ghz and 1.7 cache) LOL
<hurricos>
Hey all: is requiring a U-boot replacement *NOT* from source a reasonable requirement for OpenWrt installation?
<hurricos>
I have two AP370's and they're behaving a little differently and have different U-boot builds. If I copy u-boot from one to the other they will no longer do so. The u-boot install doesn't contain any device-specific variables
<hurricos>
If this is OK, what is the reasonable way to distribute patched copies of u-boot?
dedeckeh has quit [Remote host closed the connection]
<hauke>
Ansuel: thanks for working on the LED offloading
Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
robimarko has joined #openwrt-devel
<Ansuel>
hauke: for the moment it's all getting worse ahahahah
<Ansuel>
they are asking for an implementation that would pollute an already complex trigger instead of implementing a new one
<robimarko>
Well, thats Marek only
<robimarko>
He tried to add networking LED offloading last year
<robimarko>
Got to v2 and kind of gave up
<Ansuel>
mhhh but i think others will follow his idea... extend a trigger is better than adding a new one
<robimarko>
I mean, he is going the "proper" route with adding HW offloading to the netdev trigger
<robimarko>
But the issue with it is that the trigger itself doesnt support triggering of much more than, link and traffic(rx or tx or both)
<robimarko>
It doesnt fit the PHY use case at all
<Ansuel>
but most of the time switch leds can work in software mode or in hw not both... setting a netdev trigger would mean that a driver can work in both software and hw
<robimarko>
As it triggers in userspace rather in HW
<Ansuel>
mhh wonder if expanding netdev trigger would be difficult
<robimarko>
It would
<robimarko>
I mean, he is targeting this from another angle
<Ansuel>
i mean we can't really handle all the device_name part
<Ansuel>
mhhh that part can be set by setting it to ro
<robimarko>
Other from the fact that it has no DT awareness, it doesnt help at all
<robimarko>
As what we want is a way to configure the LED controllers inside of HW
<robimarko>
Rather than "offload" the blinking
<robimarko>
As what good is to offload the blink when you are triggering in SW which is the expensive part
<robimarko>
And the reason why pretty much all switches and PHY-s have HW dedicated to triggering and blinking LED-s
<Ansuel>
the fun part is that the command he described are actually the same with only the difference that you don't set the device (it would be static anyway in our implementation) and the option are in a dedicated directory