trial has quit [Remote host closed the connection]
Rupurudu has joined #openwrt-devel
n05ph3r42 has joined #openwrt-devel
<n05ph3r42>
Hey there! Im trying to build firmware with custom kernel for BPI-R3 which is Cortex A53. When chekhing logs i noticed that compiler uses -march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' and not CFLAGS i specified in menuconfig in > Advanced configuration options (for developers) > Target Options
<n05ph3r42>
how it can be that march used is for armv8.5-a while cortex A53 uses armv8-a set?
<n05ph3r42>
i specified in # > Advanced configuration options (for developers) > Target Options next CFLAGS: -march=armv8-a+crc+crypto -mtune=cortex-a53 -mcpu=cortex-a53+crc+crypto
<n05ph3r42>
but seems that they are not present anywhere
<n05ph3r42>
in menuconfig also is set : "Target System (MediaTek Ralink ARM)" "Subtarget (Filogic 8x0 (MT798x))" "Target Profile (Bananapi BPi-R3)" and "Enable experimental features by default"
<n05ph3r42>
i can paste full log to somewhere if anyone interested
<n05ph3r42>
may it be that i made a typo in kernel config that overrides march?
goliath has quit [Quit: SIGSEGV]
<n05ph3r42>
Just checked, in .config CONFIG_EXTRA_OPTIMIZATION="-fno-caller-saves -fno-plt -ftree-vectorize" and CONFIG_TARGET_OPTIMIZATION="-O2 -pipe -march=armv8-a+crc+crypto -mtune=cortex-a53 -mcpu=cortex-a53+crc+crypto" is set
detonate has quit [Remote host closed the connection]
Stat_headcrabbed has joined #openwrt-devel
Stat_headcrabbed1 has joined #openwrt-devel
Stat_headcrabbed1 has quit []
Stat_headcrabbed has quit [Quit: Page closed]
Stat_headcrabbed has joined #openwrt-devel
Stat_headcrabbed has quit []
detonate has joined #openwrt-devel
Stat_headcrabbed has joined #openwrt-devel
<Stat_headcrabbed>
Hello, have anyone seen odhcp6c's maintainer(Hans Dedecker, dedeckeh) these days? Seems odhcp6c haven't been maintained for over one year.
<n05ph3r42>
schmars[m]: Sure, higher gen cmd set includes previous most of time. But not vise versa. How code generated for -march=armv8.5-a cand be processed on Cortex A53 which is basic armv8-a?
<Stat_headcrabbed>
There are some issues and MRs in github odhcp6c repo but the maintainer didn't respond to any of them.
<n05ph3r42>
And another question is about LTO (link-time-optimisation), is all packages already compatible with it?
<n05ph3r42>
There is config option to apply LTO globally to firmware, is ot safe, or some pkgs compilation will break?
<Stat_headcrabbed>
n05ph3r42: armv8.5-a has more instructions than armv8-a
<Stat_headcrabbed>
I'm not sure if armv8.5-a's binary would work on a53
<n05ph3r42>
Stat_headcrabbed: Thats what im talking about.
<n05ph3r42>
compiler uses unsuported march, while in config specified correct march.
<n05ph3r42>
Stat_headcrabbed: im building OpenWRT firmware and kernel for banana BPI-R3. It is a Cortex A53. I specified in menuconfig options CONFIG_TARGET_OPTIMIZATION="-O2 -pipe -march=armv8-a+crc+crypto -mtune=cortex-a53 -mcpu=cortex-a53+crc+crypto" and CONFIG_EXTRA_OPTIMIZATION="-fno-caller-saves -fno-plt -ftree-vectorize"
<n05ph3r42>
Stat_headcrabbed: and then checked build logs, noticed that gcc uses wrong CFLAGS (... -march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' ...)
<robimarko>
Where do you see GCC using wrong march?
<robimarko>
On the kernel or packages?
<n05ph3r42>
rabomarko: is it makes any difference?
<robimarko>
Yeah, since kernel passes its own flags
<robimarko>
Lets put it this way, give me the simplest way to reproduce the issue
<robimarko>
As since filogic has cortex-a53 set as the CPU_TYPE it will just pass -mcpu=cortex-a53
<robimarko>
Like all other A53 targets
<n05ph3r42>
rabomarko: well, maybe you right, but a53 wont exec code for v8.5a set anyway, how it can be in cflags used by compiler?
<robimarko>
That is why I ask, give me a way to reproduce whatever you are seeing
<robimarko>
Cause GCC will just be built for -mcpu=cortex-a53 as its default
<n05ph3r42>
rabomarko: can you expliain why config options is ignored?
<n05ph3r42>
rabomarko: is it a but due to experimental feature?
<f00b4r0>
n05ph3r42: robimarko is trying to help you here. Before asking more questions, can you please answer his?
<n05ph3r42>
bug*
<f00b4r0>
provide your .config and the name of the package where you see these CFLAGS
<n05ph3r42>
Also any ideas about global LTO compatibily, anyone?
<robimarko>
Its hit and miss
<robimarko>
Hence why some packages disable it in makefile
<n05ph3r42>
Only few distros supports it globally, Gentoo still works on it for example
<n05ph3r42>
Wondering is it safe to eble LTO in menuconfig for OpenWRT
<robimarko>
You gotta test it, it should work on most stuff
<\x>
kernel lto when
<robimarko>
Soon TM
<\x>
lto with graphite bro
<n05ph3r42>
<\x> afaik lto for kerenel is already done for llvm
<\x>
yup it is
<\x>
i compile my own kernels for my andropid phone, clang + polly no issues
<n05ph3r42>
<\x> also there is another killer feature - BOLT
<\x>
for arm64, iirc sultan has changes needed to get aarch64 lto kernel working, but its for like 5.15
<\x>
with gcc*
<kerneltoast>
\x: that's for gcc lto of the kernel
<\x>
yup yup
<kerneltoast>
also wouldn't really suggest polymorphic optimizations on the kernel since afaik there is still no stable polymorphic optimization backend yet
<kerneltoast>
though I've heard polly is not as horrendous as graphite
<\x>
oh man
<\x>
This motherboard comes with an exclusive 802.11 a/b/g/n/ac/ax/axe/be Wi-Fi 7 + BT v5.4 module that offers support for 802.11 a/b/g/n/ac/ax/axe/be Wi-Fi 7 connectivity
<kerneltoast>
for openwrt i doubt you'll see much impact from lto since the kernel code coverage is quite small for an AP or router
<\x>
its becoming longer and longer
<kerneltoast>
PGO would probably give spicy results though
<n05ph3r42>
<kerneltoast> and BOLT will achieve even more than pgo+lto
<n05ph3r42>
<kerneltoast> on top of it
<\x>
so there it is, 5GbE from realtek now on next gen boards, rtl8126
<\x>
new am5 boards announced and listed and mid to higher tier boards have them
<kerneltoast>
n05ph3r42: *unlimited power*
<Stat_headcrabbed>
Btw can anyone solve my problem above?
<robimarko>
n05ph3r42: what package do you see armv8.5 flags?
<robimarko>
GCC is clearly built with your optimisation flags only and a53
<n05ph3r42>
robimarko: then error comes from kernel config?
<mirko>
when flashing OpenWrt on a DSA-compatible device - the default is a bridge over all lan ports (e.g. lan1, lan2, lan3, lan4). If I now want to add a logical VLAN interface - what's the way? br-lan.VLAN? bridge over lan1.VLAN, lan2.VLAN, lan3.VLAN, lan4.VLAN ? configure the switch ports via bridge VLAN filtering?
<mirko>
also, the default br-lan is always a software bridge - is this correct?
<nbd>
mirko: use bridge vlan filtering
<nbd>
add bridge-vlan sections for the bridge device in /etc/config/network
<robimarko>
n05ph3r42: Again, where are you seeing the flags
<robimarko>
I have asked like 5 times
<mirko>
nbd: ok, what still confuses me is that br-lan looks to me like a software bridge. so adding VLANs to the (seemingly) software-bridge looks like all traffic goes through that software bridge
<Stat_headcrabbed>
nbd: Hello, I'm the author of that wds+wed support patch. I'm currently stuck on it, can you take over this patch?
<Stat_headcrabbed>
I'm not really familiar with mt76 code, just an enthusiast, so not really sure if I could improve it as what you asked for. I've put more information on my reply email.
<nbd>
mirko: the idea behind dsa + bridging is that the software bridge datapath is offloaded to the hardware
<nbd>
Stat_headcrabbed: i will try to find the time soon to complete that patch
<nbd>
thanks for your work
<Stat_headcrabbed>
:)
<nbd>
mirko: the imporant part when using multiple vlans is to have them all handled by a single bridge via vlan filtering
<nbd>
mirko: and then using vlans on top of the bridge for ip interfaces
<n05ph3r42>
robimarko: ( ... -march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' ... ) thats what im talking about
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<robimarko>
n05ph3r42: Wait, its kernel 5.15, is that 23.05?
<n05ph3r42>
robimarko: v23.05.5
<robimarko>
n05ph3r42: Well that would explain why config was weird for master
Rupurudu has quit [Read error: Connection reset by peer]
<mirko>
nbd: hmhm, ok. it just feels awkward configuring VLANs on the HW via a software-bridge - and not via e.g. the physical net device itself (eth0)
<mirko>
thanks for explanation, though, makes sense when knowing about what you just told me
<mirko>
how do i know that configuring vlan filtering on a software bridge is actually offloaded to the (DSA-capable) hardware? In LuCI I guess when "Bridge VLAN filtering" pops up as tab(?) But what's actually indicating that on low-level?
<schmars[m]>
mirko: on a software bridge i get e.g. /sys/devices/virtual/net/eth1.41/brport
<KanjiMonster>
vlan filtering just means this is a vlan filtering (aware) bridge; it does not necessarily mean that there is offloading in the background
<KanjiMonster>
I recommend to install ip-bridge to get a better view into the bridge configuration/state
<schmars[m]>
oh wait that brport file is because that vlan interface is itself part of a bridge (other port is a wifi iface)
<KanjiMonster>
(e.g. 'bridge vlan' will show you all configured vlans)
<mirko>
KanjiMonster: alright, thanks
<mirko>
out of curiosity, what happens with the bridge vlan filtering when some ports part of a bridge are connected to a DSA supported switch and some are not?
<KanjiMonster>
IIRC the mac addresses on ports that are not on dsa ports are configured for the cpu port, so that anything to/from them goes to the cpu
<schmars[m]>
i run that setup a lot, what specifically are you looking for? :) it "just works"
<KanjiMonster>
the mac addresses of learned devices behind ports*
<schmars[m]>
yeah
<mirko>
schmars[m]: me? i'm trying to understand
<schmars[m]>
was just looking for clarification of the question :)
<KanjiMonster>
also dsa drivers can refuse vlan configuration, so if you try to configure something that the driver can't handle, it will just fail with an error instead of silently breaking (in theory)
<KanjiMonster>
but in general the theory is that you add all ports where you want to forward traffic between to a vlan filtering bridge, and then configure the vlans on that bridge
<mirko>
KanjiMonster: ack
<KanjiMonster>
where you configure for each port which vlans it is a member of, including pvid and (egress) untagged - and the bridge itself is also treated as a port
<KanjiMonster>
so mondern linux can automatically configure vlans for each vlan interface you create on the bridge
<KanjiMonster>
you don't need to have ports part of the bridge though; if you use a port as a wan port, then you can just use it as is (and configure vlan interfaces on it), even when you have other ports on a vlan filtering bridge
<schmars[m]>
yep that part is really nice
<schmars[m]>
it can get iffy if you have e.g. multiple AP devices on the same "dhcp" vlan, and clients roam between the APs. but manageable
<mirko>
i really feel like i'm not the only who this doesn't strike as intuitive :) not meaning sth. is wrong or doesn't make sense and i really get get advantages now - but browsing through the and 3rd party docs was always missing the crucial bits helping me to actually understand
<schmars[m]>
yeah it's a little bit magicky and blackboxy
<mirko>
so i assume which / whether a port is connected to a DSA capable switch, where the driver then - at runtime - decides, whether it can/want to pass the config down to the actual HW, is defined in the device tree?
<schmars[m]>
at least for mtk dsa driver, the dts only declares which port is "wan". i dont know if the number of ports is static, or configured, but the config is based on /etc/board.json
<KanjiMonster>
the device tree mostly has the physical information, i.e. which of the possible ports are actually connected and how (phy or SFP) - it even supports stacked switches
<mirko>
also the part that a bridge is not a bridge anymore (according to my conventional understanding), once VLAN filtering is enabled, does not help with intuition
<mirko>
*once VLAN filtering is enabled *and configured*
<KanjiMonster>
it's still a bridge, it just now also looks at the vlan tags before forwarding between ports
<KanjiMonster>
it also does learning per vlan (see "bridge fdb" output)
<mirko>
technically it surely still is a bridge, but one has to know that a bridge does not mean (anymore) it simply bridges ports (forwarding *all* traffic incl. VLAN tags)
<KanjiMonster>
right, that is the "vlan filtering" part
<KanjiMonster>
one nice thing about using a vlan filtering bridge is that it also allows you to use ranges when configuring vlans (e.g. bridge vlan add dev lan1 vid 100-200)
<mirko>
i'm still not getting the part where i know whether my VLAN config on a software-bridge is passed/off-loaded down to the hardware - or not
<robimarko>
I think that is visible in the ip bridge command
<mirko>
KanjiMonster: how on earth is a range passed down to the hardware? probably it isn't, but I know that limits of configurable tags vary immensely..
<mirko>
..depending on the hardware.
<KanjiMonster>
only in way that the dsa driver accepted the configuration, so it is supposed to be offloaded when accepted
Stat_headcrabbed has joined #openwrt-devel
<mirko>
KanjiMonster: and the way to "overcome" HW limitations is doing VLAN filtering in software - by disabling off-loading?
<KanjiMonster>
mirko: the kernel configures each vlan individually, and presumably backs out if the driver eventually reports an error because the vlan table is full (and presumably undos any partly configured vlans)
<KanjiMonster>
so each port has 2 vlans configured; 2 as tagged, and 99 as pvid untagged (except for the bridge, where everything is tagged)
<mirko>
not sure how to determine whether it's HW or SW doing VLAN filtering from that output, though
<KanjiMonster>
if this is a vlan aware bridge, then you know it is HW because you were able to configure it
<mirko>
KanjiMonster: didn't you just tell me earlier vlan awareness, does not mean it's capable of offloading? :)
<KanjiMonster>
... if the ports that you bridged are ports from a dsa switch
<mirko>
was referencing "17:12 < KanjiMonster> vlan filtering just means this is a vlan filtering (aware) bridge; it does not necessarily mean that there is offloading in the background
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<mirko>
hm, ok
Stat_headcrabbed has joined #openwrt-devel
<KanjiMonster>
ah. yeah. There's nothing stopping you to create a vlan aware bridge on your pc and bridge multiple network cards, linux will then do all the forwarding/filtering in software
<KanjiMonster>
but once a dsa port gets added to a bridge it becomes complicated
Stat_headcrabbed has quit []
<mirko>
KanjiMonster: and bridge util will display me something different than what I showed in my paste, indicating it's done in SW?
<KanjiMonster>
no, it will show the same
<mirko>
krkr ;)
<KanjiMonster>
adding the first dsa port to a vlan filtering brige can fail if the dsa driver doesn't support the existing configuration of the bridge
<mirko>
I still don't get how to figure out whether VLAN filtering on my bridge is done in SW or HW then. But you helped me a lot, so I'm not gonna press further on this
<KanjiMonster>
if's implied by having dsa ports on the brige and the kernel accepted the bridge vlan configuration
<KanjiMonster>
but there is no way to know if the driver correctly configured the vlans in the switch
<KanjiMonster>
"ethtool -i lan1" => "driver: dsa"
<mirko>
how do i know that after flashing an openwrt release on my device and looking at the default br-lan "VLAN aware"-capable bridge, whether it's a DSA compatible switch handling stuff in HW - or not?
<mirko>
KanjiMonster: ah!
<mirko>
KanjiMonster: but as you said, just because it CAN be handled by DSA, doesn't mean it is (as it might have refused the config due to e.g. HW limitations), correct?
sorinello has quit [Ping timeout: 480 seconds]
<KanjiMonster>
mirko: not 100% sure I can follow your question. Basically any network configuration on dsa ports goes through dsa/switchdev and needs to be acked (as successfully configured in hardware) by the switch driver
<mirko>
KanjiMonster: my question assumed sth, but probably it's not the case, so asking that one explicitly: there's no fallback (if DSA NACKs config request) or way to turn off HW-offloading for DSA-capable ports - and then done in SW?
<KanjiMonster>
Ah, no, there is no sw fallback
<mirko>
ok, so DSA-managed ports work in HW - or they don't work (with requested config)
<mirko>
the big picture feels rather complete then
<KanjiMonster>
yes. and IIRC this is even intentional, so that you can't accidentally trigger a software fallback and suddenly all your network performance is shit
<mirko>
KanjiMonster: that's what i was fearing, given it being a blackbox where you don't know whether it's HW or SW - hence my rather pressing questions
<mirko>
thanks a lot - that helped tremendously
<mirko>
though i'm still wrapping my head around what would happen if I'd add a 5th port - let's say, a really dumb asix based USB-ethernet device to the bridge. ideally lan1-lan4 would still do everything in HW and only traffic between one of the lan1-4 and usb-eth would pass through the CPU?
<KanjiMonster>
exactly that is what happens :)
<mirko>
*phew* :)
<KanjiMonster>
from the dsa standpoint the usb ethernet is essentially no different to a wifi ap interface that is part of the bridge
<mirko>
KanjiMonster: feels like a bad example given that you can't /usually/ pass VLANs to/via WiFi devices