<schmars[m]>
can someone trigger a 22.03-snapshot ramips/mt7621 rebuild? firewall4 still depends on kmod-nft-nat6 there, which has been removed. the firewall4 change didn't get picked up by the build somehow, so the 22.03-snapshot imagebuilder is quasi broken - https://github.com/openwrt/openwrt/commit/534e256c029bc47920d8b2544a43e568491b1af2
<schmars[m]>
eeh same for mt7622 and probably a few others
<slh>
that will happen automatically after the next commit/ tomorrow
<schmars[m]>
time for me to go to sleep anyway :-)
Tapper1 has quit [Ping timeout: 480 seconds]
KGB-0 has quit [Quit: KGB-0]
KGB-0 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador has joined #openwrt-devel
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
FriendlyNGeeks has joined #openwrt-devel
<FriendlyNGeeks>
@stintel I hope you enjoyed the camping, if you get a second to tell me where I've been messing up for months. still cant build an image to make it past boot for pi0w2 and i pressed enter
FriendlyNGeeks has quit [Quit: Page closed]
FriendlyNGeeks has joined #openwrt-devel
danitool_ has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<\x>
hurricos: https://i.imgur.com/YbTHHMO.jpg on m.2 1216, maybe we will see this refit to mini pcie like how ax200 mini pcie is made. still cant see m.2 2230
<\x>
X670/E and B560/E (am5) motherboards will come with them though so we need to wait for a month or two.
<stintel>
FriendlyNGeeks: you don't need to ask/wait for me specifically ... the instructions in the commit message should be pretty clear, they were tested and confirmed working by someone other than me
<stintel>
I suggest you just use the snapshot images
<stintel>
the rpi2 one for 32bit or the rpi3 one for 64bit
goliath has quit [Quit: SIGSEGV]
danitool has joined #openwrt-devel
<rmilecki>
jow: nbd: any objections to small uci code cleanup: s/uci_list_add/uci_list_add_tail/ ?
rmilecki has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
<rmilecki>
jow: nbd: (i'm back reconnected)
SlimeyX_ has joined #openwrt-devel
<nick[m]1234>
Tapper1: thanks
SlimeyX__ has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX__ is now known as SlimeyX
SlimeyX_ has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
MaxSoniX has joined #openwrt-devel
aiyion_ has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
srslypascal is now known as Guest192
srslypascal has joined #openwrt-devel
srslypascal has quit []
Guest192 has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
hitech95 has joined #openwrt-devel
<hitech95>
nbd, I've seen that you merged IPv6 for the mtk PPE! Thanks a lot. Any plan in implementing MAP-E/MAP-T acceleration in Openwrt?
<hitech95>
I've seen that the PPE v4 have support for MAP protocols... Mtk HWNAT kernel module don't have any references so far on how to configure them... Only some references about MAP-E
srslypascal has quit [Ping timeout: 480 seconds]
<oliv3r[m][m]>
I'm trying to figure out where EEE fits into the whole NIC/DSA/PHY picture. For desktop adapters, it's more or less easy, its an ethernet device( NIC) with integrated MAC + PHY, so it doesn't matter so much. But EEE is kind-of a PHY feature-ish (or atleast cooperates with the MAC). Especially on switch-chips, that just have an *MII interface to the MAC's, the PHY has the EEE info. I see DSA has some eee related entries, but the ops
<oliv3r[m][m]>
struct doesn't have the `.get_eee` member.
<oliv3r[m][m]>
So how does this fit together? And is it fair to say, that a switch chip tends to offer 2 (or more) functions? E.g. the DSA bit (l2, l3, vlan etc) and the PHY bits so it's expected to have 2 drivers for different reasons (ignoring thingsl ike LEDs which would be a 3rd feature)
robimarko has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<robimarko>
rsalvaterra: Is mvebu 5.15 ready for merge?
Piraty has joined #openwrt-devel
<f00b4r0>
interesting: the patch that assigns a separate cpu gmac to each port on mt7621 (PR#10238) actually "fixes" the speed downgrade problem. Suggests the problem is tied to cpu port config. Now to hunt that down in the code...
<stintel>
so any of the ax210 users here know how to make it monitor mode on 6GHz channels?
borek has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
<rsalvaterra>
robimarko: As far as the Omnia is concerned, it works. I'm running it myself. :)
<robimarko_>
rsalvaterra: It seems to work for most people
<robimarko_>
For me it worked on the devices I could test
<ynezz>
rsalvaterra: why are you so shy to merge it? :P
hanetzer has quit [Quit: WeeChat 3.5]
<rsalvaterra>
ynezz: I feel merging shouldn't be done by the person who creates the pull, nothing else. :)
<hauke>
oliv3r[m][m]: DSA has a own .get_eee_get and set function
<hauke>
there you can do the settings needed in the MAC
<pepes>
rsalvaterra: Yes, merging should not be usually done by the person, who created it. :) But it works on Turris Omnia, so its good. MOX is not supported in OpenWrt, yet. I can write it to the pull request that it works on both routers.
<stintel>
rsalvaterra: you can't really merge it anyway, you'd have to push to git.openwrt.org, merging in github gets overwritten
<stintel>
doesn't github magically add Tested-by or Reviewed-by tags like patchwork?
* stintel
hides
<ynezz>
rsalvaterra: well, if you're that pedantic, BTW you've got my ACK, so what's blocking you?
rua has quit [Quit: Leaving.]
<ynezz>
stintel: I would say, that crypto in Git prevents that
<ynezz>
pw can introduce backdoors freely
<oliv3r[m][m]>
hauke yeah I saw, but i'm not sure where the 'traditional' net/phy/realtek.c -like drivers relate to DSA. I would expect that a DSA switch driver, would still probe all PHY's and based ont he PHY ID, invoke the PHY driver. So there must be some relation between DSA and PHY driver? For EEE i'm less concerned, as I think those come mostly from standard MMD calls (but what If I need to override it for my particular phy?)
rua has joined #openwrt-devel
<robimarko_>
PHY drivers are still used
<robimarko_>
But DSA does not manually probe PHY-s, that is done by PHYLIB independently before DSA even gets probed
ekathva has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<oliv3r[m][m]>
ok fair nuff, so; if my PHY chip (like the rtl8218) probably needs to offer 2 drivers, right? one phy_driver; to do auto-neg, phy status cable-testing etc; and one DSA driver, to setup L2/L3 stuff; is that the gist of it?
<oliv3r[m][m]>
so DSA is to take care of EEE, and PHY the other stuff; but what if my PHY is non-standard and needs some quircks; how to do that?
<robimarko_>
No, you are mixing it
<aparcar[m]>
ynezz: do you run all device tests via ssh/cram or do you run some directly on the device itself?
<robimarko_>
PHY driver only handles the ethernet PHY
<robimarko_>
DSA handles the switch/MAC
<robimarko_>
MAC has to advertise EEE and PHY as well
<ynezz>
aparcar[m]: UARTs are not reliable, so I prefer to test over SSH only
<aparcar[m]>
how is it not relyable?
<aparcar[m]>
*reliable
<ynezz>
bitflips
<stintel>
hmmm I was asked if we have an architecture diagram for OpenWrt
<stintel>
whatever that means
<oliv3r[m][m]>
robimarko_to give you more detail, i'm looking at the RTL9302 SoC; which has an integrated 8 port MAC (no PHY) and integrateds witch, and an external octo-phy (the RTL8218). they speak XSGMII and MDIO. So the PHY stuff (auto-neg, link-ready, speed selection) is all defined (traditionally) in net/phy/realtek.c and the more switch stuff would be in DSA?
<robimarko_>
Yes
<robimarko_>
That is correct
<oliv3r[m][m]>
but EEE is a 'function' of the PHY?
<robimarko_>
In the end yes
<robimarko_>
PHY driver must expose that
<oliv3r[m][m]>
but the MAC/DSA has to 'push' that via MMD calls
<aparcar[m]>
ynezz: I see, thanks!
<oliv3r[m][m]>
ah, exactly, so how does the PHY driver expose the EEE functions?
<robimarko_>
There are standard OPS for that
<mangix>
stintel: monitor mode...funny. My router just reboots when running hcxdumptool.
<oliv3r[m][m]>
(assuming for arguments sake, they are non-standard)
<mangix>
on my ax210
<robimarko_>
oliv3r[m][m]: You just add EEE via OPS
<oliv3r[m][m]>
robimarko_so I saw set_eee and get_eee in ethernet_ops
<robimarko_>
And if its really broken, you can advertise certain EEE modes as broken
<oliv3r[m][m]>
robimarko_do you have an example that I can look at?
<mangix>
stintel: mine's the minipcie version. I doubt that's the reason for the reboots
<oliv3r[m][m]>
(this was already super helpful though; thank you for that)
<robimarko_>
oliv3r[m][m]: I know that broadcom PHY driver hakcs it during config_init
<aparcar[m]>
ynezz: yea I saw things like that I wondered if the cram approach is the way to go. I checked out bats(-core) which allows you to run and capture commands instead of listening to the full stdout
<robimarko_>
oliv3r[m][m]: You can actually define broken EEE modes in DTS itself
<aparcar[m]>
anyway thanks for that example, I'll look into an ssh test setup for lava
<aparcar[m]>
ideally I use all your cram stuff and just run it within the lava framework, I hope you don't mind
<oliv3r[m][m]>
I haven't looked into WHY our target has custom EEE functions and why that patch was even done
<stintel>
Mangix: there's miniPCIe version? o_O
<robimarko_>
oliv3r[m][m]: No idea, probably a hack to force it directly from DSA
<ynezz>
aparcar[m]: well, cram is not relevant in this case, everything would fail on UART bitflip/fifo overrun as it would change the expected test output
<oliv3r[m][m]>
robimarko_thanks anyway, As i'm slwoly getting up to speed on this platform and trying to clean it up a bit; and ther's a lot to be cleaned up ;(
<mangix>
that thing should not exist, but I'm happy it does
<aparcar[m]>
ynezz: that's why I'm implementing the ssh approach for lava
<stintel>
Mangix: great, so I went through all this trouble to get miniPCIe to m.2 adapters and tiny pigtails just to learn this :/
<robimarko_>
oliv3r[m][m]: Oh yeah, the whole target is hacks pilled upon hacks
<stintel>
I might need CONFIG_BT_HCIUART_INTEL
<oliv3r[m][m]>
robimarko_ but I also agree and understand, better to have the 'vendor-ish' crap and have support out there for users, and get started on cleaning it up; then to get it 'right and upstreambale' and wait for 10 years before its useable
<oliv3r[m][m]>
(which is also the reason I re-submitted a 'somewhat stirpped down' version of birger's patchset, as it does mostly work)
<robimarko_>
oliv3r[m][m]: The issue is that targets that used that approach before pretty much all ended up never getting upstream
<oliv3r[m][m]>
I know, I have the wdr4300 and see tons of patches there too
<oliv3r[m][m]>
in the end, you loose left way or right way around; I get that
<oliv3r[m][m]>
I wouldn't mind cleaning up lots of that crap if someone where to $$ for it :)
<mangix>
stintel: i did that before with a QCA card. results were bad.
<robimarko_>
oliv3r[m][m]: Good luck with that, I got some minor donations from users for IPQ807x to get some HW
<robimarko_>
But probably spend x3 that myself so far
<robimarko_>
All I got are various chinese ODM-s that are asking if "I can send them" OpenWrt support
<oliv3r[m][m]>
robimarko_yep; labor of love :(
<\x>
Mangix: those mini pcie 8260, 9260, ax200, ax210 are done by adapting m.2 1216 to mini pcie
<\x>
i have one of the early ones, 8260
<\x>
make sure you get HE-NSS2, VHT-NSS2 since some of these arent wired properly
<\x>
since we have to wait for some months still for MT7922 m.2 to hit the market
<\x>
well whichever happens first I guess
<\x>
stintel: just gotta get some very stable hands hah
<\x>
you can use a tweezer to push them into place, thats what I do
<stintel>
I need to get tweezers :P
<stintel>
I aligned the connector and used a screwdriver to apply pressure
<f00b4r0>
holy crap I give up.
<f00b4r0>
I looked at drivers/net/ethernet/mediatek, drivers/net/dsa/mt7530, even net/dsa; I just can't figure out what causes the differing behaviour between 5.10 and 5.15.
<f00b4r0>
This needs a more trained eye than mine, maybe nbd or dangole
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
<f00b4r0>
aparcar[m]: I meant to add a tongue-in-cheek smiley there. I would say 8.8kb is not exactly bloat. Especially now that 4M devices are out of the game
<f00b4r0>
:)
<f00b4r0>
that reminds me I need to patch the IPV6 config
* f00b4r0
gets on with it
aiyion has quit [Remote host closed the connection]
<PaulFertser>
tmn505: can't tell, I'm not a real wiki admin, sorry.
<f00b4r0>
aparcar[m]: neat :)
aiyion has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
<tmn505>
PaulFertser: np, thanks for responding.
<rsalvaterra>
ynezz, pepes, stintel: will merge this evening, thanks for the feedback, everyone. :)
<robimarko_>
thanks
Borromini has quit [Ping timeout: 480 seconds]
<oliv3r[m][m]>
if I build my target, are any of the generic kernel patches, etc applied? or is the starting point always a vanilla 5.10/5.15; and then only the local patches applied/
<slh>
generic will be applied (first)
<oliv3r[m][m]>
ok thanks :)
<oliv3r[m][m]>
I suppose there's not an easy way to get a 'patched' kernel tree? e.g. i'd have to manually do the git am, git cherry-picking, copying 'files-5.10' etc, to get a nice openwrt-ized tree (with the individual commits) or is there a script i can run that does that? :)
<oliv3r[m][m]>
hmm, a little painful :) What I want to avoid; is doing my normal git-kernel workflow; then at the end, git-format-patch -> openwrt/patches-5.10; really slows down the worflow; but I suppose as an 'inbetween' solution that somehwat could work
<slh>
there is no way around using quilt
<oliv3r[m][m]>
sad :(
borek has quit [Ping timeout: 480 seconds]
<svanheule>
oliv3r[m][m]: maybe you could try CONFIG_EXTERNAL_KERNEL_TREE, but you would still have to backport patches in the end
MaxSoniX has quit [Quit: Konversation terminated!]
<oliv3r[m][m]>
the 'in the end' part i don't mind; what what I could do, prepare the kernel tree; store everything as a single dumb commit; and then iterate ontop of that
<oliv3r[m][m]>
but the externel tree is a important starting point for sure
<oliv3r[m][m]>
less looking forward to writing something uppon 5.10; then submitting it to mailine; but such is life
ekathva has joined #openwrt-devel
<oliv3r[m][m]>
LINUX_KERNEL_HASH-5.10.136 = 1c099d0d59e7d9f671dfc947e16891b7a3a45efd7dfcc6b1e55a194961e45159 is not the actual git-hash from upstream is it?
<stintel>
it's not the git hash, it's the hash of the release tarball
<oliv3r[m][m]>
ahh, fair nuff; ok so git checkout v5.10.136 is good :)
torv is now known as Guest235
torv has joined #openwrt-devel
Guest235 has quit [Ping timeout: 480 seconds]
aiyion has quit [Remote host closed the connection]
<mrnuke>
robimarko_: I comperstand that there's a lot of ipq60xx stuff missing. I do want to find and add the missing bits, and leverage any prior art you may have made on the matter -- hence my line of questioning on guthub
<robimarko_>
mrnuke: I get it, its just that there is more stuff missing than probably expected
<mrnuke>
robimarko_: I found the switch { mdio-bus=<> } property and all the problems that solved. Or in more Star Wars fashion: "You underestimate my power!" -- right before I crash and burn :p
<robimarko_>
mrnuke: Did you backport stuff that Baruch upstreamed?
<robimarko_>
He did some work, mainly MDIO in DTS and PCI support
<mrnuke>
robimarko_: negative. MDIO has been working in upstream c5.15 (I just added the DTS node)
Misanthropos has joined #openwrt-devel
<robimarko_>
mrnuke: That is what I meant, backport the DTS changes
<robimarko_>
As he upstreamed the MDIO node already
<mrnuke>
You mean "* a2d2c809cfee arm64: dts: qcom: ipq6018: Add mdio bus description" ? I did not pick up the patch, just implemented the same thing in a more hacky manner :)
<robimarko_>
Yeah
<robimarko_>
Il probably get back to IPQ60xx after redoing the 5.15 tree with backported stuff.
<robimarko_>
Luckily most of the clock stuff will get backported in 5.15.61
<hauke>
robimarko_: It would be nice to have ipq807x support in OpenWrt master ;-)
<robimarko_>
Yeah, I will make a PR after redoing the 5.15 tree with all of the stuff that got backported
<robimarko_>
That code is way nicer than what is currently used
<robimarko_>
I am waiting on 5.15.61 to avoid manually backporting some stuff that was picked
ekathva has quit [Quit: Leaving]
<hauke>
robimarko_: thanks
<schmars[m]>
the issue with firewall4 dependency on removed kmod-nft-nat6 in 22.03-snapshot persists even though firewall4 was rebuilt earlier today. can't build anything involving firewall4 right now. any cues to why buildbot doesn't seem to recognice that dependency has been removed?
<robimarko_>
hauke: Wanted to upstream more stuff, but QCA guys are so slow
<hitech95>
Do you guys know a way to dump a spi nand chip?
<hitech95>
My programmers dot support nand ones.
aiyion has joined #openwrt-devel
<philipp64>
schmars[m]: thanks for the pointer.
<hauke>
hitech95: dumping an SPI annd should be possible with GPIOs
<hitech95>
I've tried with a RPI and it's spi bus but no luck so far...
<hauke>
I do not know of any HW dumper, but there are probably some
<hauke>
spi nand uses different commands than spi nor
<hitech95>
hauke, i know some HW but they are a bit too expensive just to try to find a root password of a device ...
<hitech95>
I know that they use different commands that the reasons why I asked. I'm using the spinnand kmod and a custom DTS overlay
<hauke>
hitech95: hmm, I would have tried the same ;-)
<hitech95>
I might have fried the chip tho. It was soldered to a 6 layer board... With a lot of heatsinking vias
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
<neggles>
hitech95: doubt it
<neggles>
you have to try *really* hard to murder spi flash chips, i've only managed to cook one to death and not for lack of trying
<neggles>
the case started to flake off...
robimarko_ has quit [Quit: Leaving]
<hitech95>
neggles, Hope so, I've really had to use a hot plate and a hot air gun to desolder the chip
<neggles>
sounds about right
<neggles>
as long as you let it cool down before you hooked it up, it's *probably* okay
<neggles>
SPI NAND is really annoying to deal with, though
<hitech95>
Yea, all of this just to see if we can dump a root password of a EPON ONT...
<hitech95>
Free mobile made a mess in the Italian deployment... Especially with net neutrality regulations ...
<neggles>
I guess the bootloader's locked?
<neggles>
who makes it? and... did you check if it's a 1.8V chip? :P
<jayk>
\x: i like speed and routers on amphetmines
<hurricos>
oliv3r: > store everything as a single dumb commit < this is what I did to bisect an issue with smp ppc32, works fine, quite easy if scripted
<hurricos>
bonus points if you use git bisect run on top of the kernel tree, and have the script do the OpenWrt Make stuff for you
<hurricos>
don't forget you have to interact with patches already in the tree tho
<hurricos>
in OpenWrt's tree*
<hurricos>
slh: I've never used quilt. I'm a bad person aren't I?
<slh>
nope, but it is useful - quite a bit. and for OpenWrt, you do need it - or need to emulate its behaviour manually (and badly) ;)
<hurricos>
aparcar: :O lava ... hmm
<hurricos>
slh: that's what I've done, I think "\
<hurricos>
aparcar: I've recently had to get emacs' tramp running against a socat-redirected serial console. I'm sure you're beyond this already but if not I highly recommend piping everything through socat -v and writing some helpers to read the output
<slh>
I guess we all started out that way in the past (in my case via cdbs/ simple-patchsys.mk, which kind of works similar enough, just much less convenient)
<slh>
quilt is good at keeping an extra patch stack, stuff clearly separated from upstream, and does help with the rebasing quite a bit
<aparcar[m]>
hurricos: you did that for emacs?
<rsalvaterra>
Alright, 5.15 for mvebu is merged.
<aparcar[m]>
hurricos: do you run some lava dispatchers?
<schmars[m]>
buildbot must be having some cache issue. i just built a fresh openwrt-22.03 myself and firewall4's dependencies are fine
<hitech95>
neggles, no idea about the bootloader, UART output is there, shell is prompted. But password is required.
<hitech95>
Chip is from mx
Tapper has joined #openwrt-devel
Misanthropos has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]