rua has quit [Read error: Connection reset by peer]
rua has joined #openwrt-devel
Borromini has joined #openwrt-devel
Atomicly- has joined #openwrt-devel
AtomiclyCursed has quit [Read error: Connection reset by peer]
Atomicly- is now known as AtomiclyCursed
<rsalvaterra>
daemon.err modprobe: no module folders for kernel version 5.15.44 found
<rsalvaterra>
Mind if I tone this down? Not having module folders isn't an error.
<rsalvaterra>
Also, "folders"? This isn't Windows. :P
<Borromini>
:P
<Snuupy>
hi Borromini
<Snuupy>
I compiled openwrt master with the 5.15 kernel, applied a patch for DFS bands on the MT7612U dongles, and rebuilt kernel/images/installed ipks
hubvu has quit [Quit: Connection closed for inactivity]
* neggles
sobs in snapdragon
Grommish_ has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
valku has joined #openwrt-devel
Grommish_ is now known as Grommish
schwicht has joined #openwrt-devel
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #openwrt-devel
cp- has quit []
cp- has joined #openwrt-devel
schwicht_ has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
srslypascal has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
srslypascal has joined #openwrt-devel
<mrnuke>
robimarko_: I'm looking at your branch(es) for ipq807x. I'm royally confused about the networking stuff.
<robimarko_>
mrnuke: What is confusing you?
<mrnuke>
robimarko_: all of it
<mrnuke>
Then I see "qcom,phy-mdio-addr = ". Whait? WHat? Isn't there supposed to be a phy-handle?
<robimarko_>
mrnuke: Yeah, in ideal world
<robimarko_>
But those are QCA drivers, so they are still using the old school connect the PHY by using the bus name string
<mrnuke>
How did qualcomm get away with shippung suuch a driver?
<robimarko_>
How would anybody stop them?
<mrnuke>
Client: "Umh, vendor, your code doesn't make sense"
<mrnuke>
I imagine some poor engineer at Senao. Must have gone to the hospital for severe face injuries from facepalming when he got the code dump from qualcomm
<mrnuke>
Is the ess switch stuff necessarry to get ethernet packets? I got my WAX218 to the point it finds the phy and established a link, but no packets flowing
csrf has joined #openwrt-devel
<robimarko_>
Yeah, without proper ess-switch config networking wont work
<robimarko_>
Cause that configures the switch and UniPHY
<robimarko_>
They like all vendors have the stance that clients should be happy that they give them code
<robimarko_>
They couldnt care less if its of any quality
srslypascal is now known as Guest1175
srslypascal has joined #openwrt-devel
<mrnuke>
robimarko_: Do we have an understanding of what the switch and uniphy do?
<robimarko_>
mrnuke: In what sense?
<robimarko_>
They are the ethernet switch and PHY block that connects to your ethernet PHY-s
Guest1175 has quit [Ping timeout: 480 seconds]
<mrnuke>
Is this a correct description: RJ45 <-> PHY <-> phy-block <-> switch <-> cpu/openwrt?
<robimarko_>
Yeah
<robimarko_>
Plus the ethernet controller that sits between the switch and CPU
<mrnuke>
Holy smokes. Looks like I do have to copypasta that weird ess node from the vendor dtb
<robimarko_>
Yes
<robimarko_>
Most of the ess-switch node is required
<mrnuke>
Are there any hopes of ever having aproper upstream driver?
srslypascal is now known as Guest1177
<robimarko_>
Hope is there
srslypascal has joined #openwrt-devel
<robimarko_>
But its same thing as IPQ40xx
<robimarko_>
Until somebody takes it up it aint gonna happen
<mrnuke>
I take it nobody took up the IPQ40xx either?
<robimarko_>
Well, company that I work for did
<robimarko_>
But only recently
<robimarko_>
As it was the only thing not upstream for IPQ40xx, as we upstreamed everything else
<robimarko_>
Ethernet driver is being upstreamed right now by Bootlin
<robimarko_>
And there is a working DSA driver and driver for the weird PSGMII PHY-s
<robimarko_>
We are planning to upstream both of those
Guest1177 has quit [Ping timeout: 480 seconds]
<mrnuke>
Yay! DO you happen to know if the ipq807 hardware is significantly different?
<robimarko_>
Yeah, its rather different
<robimarko_>
It shares some stuff like PSGMII from IPQ40xx
<robimarko_>
But the switch, ethernet controller and PHY are heavily updated
<robimarko_>
To support 2.5G SGMII and 10G Base-R
<mrnuke>
I miss the days when hardware made sense
srslypascal has quit [Ping timeout: 480 seconds]
<robimarko_>
It still makes sense, just not without a datasheet
<mrnuke>
I woke up this morning thinking "hey, you know what would be cool: to patch the qcom,phy-mdio-addr to use a phy-handle". But I realize now that how futile that effort would be
<robimarko_>
It can be done
<robimarko_>
And it is not actually that hard, I did that for IPQ40xx with the QCA driver
<mrnuke>
If you think it's not a terrible idea, I can give it a try
<mrkiko>
robirmarsorry, maybe I already asked but - will in future be any chance to use that hw in openwrt in general? Or are bootloaders in general hostile / locked ?
<robimarko_>
Yeah, the PR branch is moving slowly to being ready for a OpenWrt PR
<robimarko_>
We are sorting out some ath11k bugs
<robimarko_>
Most of the code has been sent upstream and there is decent board support
<robimarko_>
The goal is to get it into OpenWrt soon-ish
Borromini has quit [Ping timeout: 480 seconds]
<robimarko_>
Bootloader situation really depends on the vendor, some utilize secure boot but you can just change the env to not use the default bootcmd
<Slimey>
some :P
<mrnuke>
" that hw in openwrt " is the reference for ipq807x ?
<mrkiko>
robimarko_: so the situation is not much worse than it is in general
<robimarko_>
mrnuke: You are gonna have to give me more context to that
<robimarko_>
mrkiko: Well yeah
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<mrnuke>
robimarko_: It was in reference to mrkiko's question about upstream openwrt support. I didn't catch if your following answers about the PR branches refer to ipq807x or another arch
<robimarko_>
Its IPQ807x
<mrnuke>
Yay!
<mrkiko>
robimarko_: and, absolutely unrelated at some extent - what happened with the project to support the Xiaomi AX9000 from a board-related / bootloader related perspective? Considering the situation with the bootloader and all, I tought one might be better in waiting a device with same performance hoping things are better
<robimarko_>
mrkiko: Well I have an AX9000 and its running fine
<robimarko_>
Minus the current ath11k limitation about AHB and PCI at the same time
<mrkiko>
mrnuke: guess the answer was yess; sorry, didn't catch you where talking with me
<mrnuke>
mrkiko: I just pulled a qualcomm by mistake: I made things confusing. Glad we got it sorted out :)
<mrkiko>
robimarko_: but support isn't upstream right? And to flash it you should open it and do it via uart I guess
<robimarko_>
No, nothing IPQ807x is in OpenWrt yet
<robimarko_>
You dont have to use UART for AX9000, there is an exploit to enable SSH
<robimarko_>
Its documented on the wiki
<mrnuke>
(re wiki entry for ax9000) "Make sure that your UART adapter is 1.8V I/O level, 3.3V or 5V adapters will kill your SoC" -- who tried at and killed their SOC?
<robimarko_>
I hope nobody, but I made sure to make it clear
<mrnuke>
Looks like I was playing with fire when I connected a 5V UART to my WAX218 -- didn't kill it though. All is fine :D
<mrkiko>
robimarko_: ok, so then UART will be needed only in case you flash a bad image and openwrt's failsafe doesn't rescue you as well
<robimarko_>
mrnuke: Then your board has a logic level shifter or your UART can do 1.8V as well
<robimarko_>
mrkiko: Hopefully, though I will move to expanding the rootfs into a single one to not waste like 75% of the NAND
<mrnuke>
robimarko_: I suspected as much. I measured the VCC -> GND on the UART footprint, and it was 3.3V. Figured I'd give it a try :D
<mrkiko>
robimarko_: thanks
<robimarko_>
mrnuke: Then it has a level shifter for sure as SoC I/O is only 1.8V with the exception being SDIO
<mrkiko>
BTW - a person is asking for help on the gl-b2200 thread of the openwrt forum; I can not answer easily. If someone might point him to IRC to talk with me or via mail ...
srslypascal has joined #openwrt-devel
tchebb has joined #openwrt-devel
<csrf>
although I understand that it's not recommended for general use, can I edit the config_generate script as a quick&easy way to change the default IP for the lan interface on a custom build?
<dwfreed>
why not just use uci-defaults?
<mrnuke>
robimarko_: Will the future upstream OpenWRT ipq807x use the nss-packages feed until a proper driver is available?
<Slimey>
heh the wireless standards group needs to add a flag that can tell people connected to a SSID to not use the mac address randomization that some devices offer :P
<f00b4r0>
that would kinda defeat the purpose, wouldn't it?
<Slimey>
yes but it makes it harder for wireless network administrators to block or track users via mac address
<f00b4r0>
which is exactly the point ;)
<Slimey>
but for police asking for logs its a bummer lol
<f00b4r0>
also the point :)
<f00b4r0>
police gets randomized macs logs. Not the admin's problem I'd say.
<dwfreed>
iirc, the randomized macs are all only locally unique, so an admin could just captive portal them and tell them to turn it off
<nick[m]1234>
jow: how can I accept a packet without traversing the firewall4 hook again?
<nick[m]1234>
goto dores not work :/
<nick[m]1234>
If I hook with priority INPUT - 1, I can not "final" accept a packet?
<robimarko_>
mrnuke: SSDK and NSS-DP will be moved to the main tree and those will be used until a better solution exists
<mrnuke>
robimarko_: thank you for the info. Now that I have an understanding of how the development for this chip works, I'm better prepared to enable the WAX218 properly
csrf has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
<mrnuke>
robimarko_: Your help today has enabled this :https://pasteboard.co/d8t2nsLddHV0.png (screenshot of luci on WAX218). Thank you!
<Borromini>
which I believe should do that although the 'preinit' makes me unsure.
srslypascal has joined #openwrt-devel
<csrf>
Borromini, yeah, I was under the impression that preinit was for some kind of failsafe mode, but I'm not sure
<Borromini>
yeah. I do set it to a 10.x subnet myself, but I also got UCI defaults setting that 10.x network. Has been ages since I configured that so cannot tell for sure. The preinit might be just for failsafe e.g.
<jow>
nick[m]1234: you can't
<jow>
nick[m]1234: a huge design flaw of nft imho
<jow>
nick[m]1234: we probably need to sprinkle includes over the entire ruleset to offer various include places for users to stage rules inside chains before/after the default routes and into the fw4 table context as well as outside of it
<slh>
mrnuke: I remember at least three or four instances on the forum where people destroyed their ax3600 or ax9000 with 3.3V UARTs
<slh>
so the warning is needed and real
<slh>
depends on the vendor/ device if they added a level shifter or just brought out the bare 1.8V UART lines from the SOC
<Habbie>
noob question: could those have been prevented by using a multimeter first?
<slh>
the archer c2600/ ipq8064 already needed 1.8V UART, so this isn't really a new story either
<slh>
yes
<Habbie>
ok, cool
<Habbie>
then that's my personal takeaway here :)
<slh>
but many of those affected don't have a multimeter and just ordered some usb2serial 'thingy' from the internet
<Habbie>
ack
<Habbie>
i do try to be more methodical
<Habbie>
as a result i might also be unreasonably slow at doing things with devices
<Habbie>
but i haven't destroyed any yet
<slh>
dito, multimeter I have (and use, several actually), when it comes to logic analyzer, scope or spi-nor writers, I'd have to pass as well
<slh>
there are also some devices with 2.5V UART (but that's even less common)
<slh>
(and so far none in the ipq807x target)
<dwfreed>
Habbie: serial is inverted logic (0 results in the normal "high" voltage level, and 1 is 0v), so when the TX line is idle, it'll be sitting at the voltage level the UART expects
<Habbie>
yep
<Habbie>
i recently learned that
<Habbie>
from you perhaps even
<dwfreed>
I feel like I've mentioned it to you before
<dwfreed>
so voltmeter between TX and ground, which there's usually pin of in the serial connector will tell you exactly what the UART voltage is
<Habbie>
ack
<dwfreed>
I have a mini radioshack multimeter, bought not long before radio shack completely died off
<dwfreed>
does AC and DC volts, amps, and ohms, and has a forward voltage and continuity tester
<dwfreed>
can also auto-detect AC vs DC
<dwfreed>
reminds me I should make one of those handy 3.5mm serial adapters one day
<slh>
I never really liked 3.5mm jacks for that - but don't really have a replacement either...
<dwfreed>
the contact sliding may be problematic if not planned for
<Habbie>
same - i think they're a very cute hack but i wish we had a better idea
<Habbie>
dwfreed, contact sliding?
<dwfreed>
on insertion, tip will touch all 3 contacts
<Habbie>
oh yes
<slh>
my preferred setup would be https://www.ebay.com/itm/382203903751 but I haven't actually implemented that either (and some devices might not like serial connected very early during the boot)
<dwfreed>
as well as ring 1 may find itself touching the contact for both rings on the way in if the tolerances are off
<Habbie>
slh, (why not? how would they know?)
<Habbie>
that's a neat small board, btw - but indeed, might be harder to fit than a jack
<dwfreed>
ooh, that is nice
<slh>
Habbie: some devices are picky (as in not properly designed in terms of pull-up/ pull-down resistors), on those the voltage feeding from rx into the SOC can be enough to get the SOC into a weird state that makes it fail to boot (no problem if you only connect a split second after applying power to the board), most devices don't have that problem though
<Habbie>
wow, ok
<Habbie>
ah, rx is active high too, of course
<Habbie>
eh, idle high
<dwfreed>
slh: a smarter chip that doesn't bring up serial until the USB serial device has been opened, perhaps?
<Habbie>
dwfreed, so, don't connect Vcc? :)
<slh>
the permanently mounted mico-usb usb2serial just appears more sensible to me than an audio-jack (with its potential to short out the contacts)
<dwfreed>
Habbie: correct, this should get power from the USB
<dwfreed>
slh: agreed
<Habbie>
yes, agreed
<slh>
dwfreed: yeah, that would be the ideal solution (albeit rarely really needed)
<slh>
(but I do have some devices falling into that category, e.g. o2 box 6431)
<dwfreed>
wish the gl.inet devices could do serial over their USB power ports
<dwfreed>
though the bigger ones that might be annoying to do
<Habbie>
i recently pondered soldering something to the right pins on the power port on a device, indeed
<Habbie>
why would the bigger ones be a problem/
<Habbie>
?
<slh>
I never liked soldering audio jacks either, part of the reasons why I'd favour the micro-usb2serial approach - they need a lot of heat, and then easily melt away