<slh>
philipp64: it's very questionable if any ath79 board could provide enough processing power to maintain 802.11ax connections (servicing interrupts alone), or had enough RAM (at least ath11k eats RAM for breakfast, 512 MB is borderline too tight; mt76 is less RAM hungry, but you'd still want at least 512 MB anyways) - another topic would be beyond-Mini-PCIe-spec power consumption and heat dissipation
<slh>
easy for new devices, but a hard issue for retrofitting 802.11ax cards into existing/ older devices not designed with those additional requirements in mind
<slh>
and yeah, hardware availability for mini-PCIe/ M.2 802.11ax cards (apart from Intel, which is useless as AP) is pretty much non-existent as well, with lead times even for single quantities beyond half a year
<slh>
if you look at compex' qcn9074 offerings (pretty much paper launches), you're also looking at 200 USD for 2.4 GHz, 250 USD for 5 GHz, 250 USD for 6 GHz, with heat dissipation issues and tx locked down to 6 dBm due to power constraints
<philipp64>
slh: okay, so not doing that...
<philipp64>
btw, what do I need coova-chilli for?
<slh>
compared to ~100 USD for the Belkin rt3200 (mt7622bv+mt7915e), ~70 USD for the Xiaomi ax3600 (ipq8071a+qcn5024+qcn5054+qca9887) or ~250 USD for the Xiaomi ax9000 (ipq8072a+qcn5024+qcn5054+qcn9024+qca9887)
<slh>
isn't coova-chilli a captive portal? (so basically useless, unless you want that functionality)
<slh>
hardware wise, QNAP QHora-301W could be a great contender as well
dangole_ has quit [Ping timeout: 480 seconds]
<mangix>
slh: i'm satisfied with my e7350
<slh>
mangix: mt7621a would be a little too slow for my needs (430/220 MBit/s), don't really need sqm, but I'd like to have the option
<slh>
that said, the e7350 is virtually non-existent around here (.de)
<slh>
and I'm not going to pay 140 EUR for the rt3200, while it's selling for 79 GBP in the UK with all taxes included
<slh>
(and yes, no 802.11ax on 2.4 GHz isn't really a convincing argument pro rt3200 either)
<mangix>
slh: it's equivalent to the rt1800. anyway, I'm using hardware offload
<mangix>
it has ax on 2.4ghz
<slh>
mangix: my luxury problem is, my nbg6817 (pq8065) can do my WAN speed without sqm, so I don't /need/ to upgrade now, but I'd like the extra-headroom for sqm should I need it (and that's what offloading or mt7621a can't do at that speed)
<mangix>
right. I don't value SQM
<slh>
easily and without resorting to softwaer flow-offloading or nss on the nbg6817
<slh>
I haven't actually used it either, I'd just like the headroom to test it. so far my ISP's have all been sane enough to keep lags at a very sensible level, so no hard need for me to dabble into it
<slh>
and 1000/500 MBit/s would be just a phone call away, should I decide to pay twice as much as I'm doing now (so, no, not anytime soon), that's why I'm idly looking for gear that can cope with 1 GBit/s wirespeed and sqm
danitool has quit [Ping timeout: 480 seconds]
<slh>
no need to rush it, just keeping my eyes open, waiting for a convincing device within a sane price bracket
<philipp64>
anyone see anything obviously wrong with my SQM config?
<mangix>
I see nothing
philipp64 has quit [Quit: philipp64]
philipp64|work has joined #openwrt-devel
philipp64 has joined #openwrt-devel
philipp64|work has quit []
<philipp64>
mangix: and the weird switch architecture with WAN being on eth0.2 ... that's not going to confuse SQM and TC?
<hurricos>
I've fixed some mistakes in the device tree (flash is 0x4000000, not 0x2000000 wide)
<hurricos>
Let's see where that gets me.
<philipp64>
mangix: DSA?
<slh>
at least qca8k is the easy part of migrating ath79 from swconfig to DSA
<slh>
well, 'easy'...
<hurricos>
Oof. `make clean` isn't enough to flush changes in a dts file?
<hurricos>
I guess it's make `distclean` for me?
<hurricos>
Or am I misinterpreting this? ... maybe the register changes I was making weren't sufficient to cause a change in the resulting fdt ...?
<hurricos>
Well, let's just start from scratch and find out.
<mangix>
philipp64: each switch port becomes its own interface. It also happens to be faster for some reason
valku has quit [Quit: valku]
<slh>
mangix: did you check if there are devices apart from qca8k supported ones or błocktrron's dsa-ar9344 branch that would block complete swconfig removal from ath79? (and apart from rtl8366rb-->realtek_smi for the tl-wr1043ndv1)?
B0z has joined #openwrt-devel
snh_ has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
<mangix>
slh: blockttron's branch is a complicated issue. It doesn't implement phy-swap, which is needed for several devices
<mangix>
qca8k is probably 90% done with support for ath79
<mangix>
I think the last major part that needs to be figured out and fixed is suspend/resume support
<mangix>
which is interesting. not even ag71xx supported that
<mangix>
sorry, ar71xx
<mangix>
personally I can live without it, but he wants to get it working.
<mangix>
LED support is also a bit question. upstream rejected it. So will it be kept for OpenWrt? who knows.
<mangix>
*big
<slh>
functionality trumps cosmetics (LEDs) for me personally
snh_ has quit [Ping timeout: 480 seconds]
<mangix>
slh: as the qca8k branch stands right now. qca8k is working except for whichever port lan1 ends up on. Once Ansuel fixes up suspend/resume support, it'll probably be done.
<slh>
I really need to look into the new split branches (still running the pre-split PR4036 on my nbg6817 (ipq8065)), also for my tl-wdr3600 and tl-wdr4300 - pretty interesting
<philipp64>
mangix: well, now I can't even get it to build the kernel without IPv6 being turned on...
<mangix>
that's expected
<mangix>
IPv6 should not be turned off
pmelange has joined #openwrt-devel
danitool has joined #openwrt-devel
cp- has quit [Ping timeout: 480 seconds]
<hurricos>
I don't know what else to try; no matter what I do, I can't get a copy of OpenWrt to boot on the WS-AP3825i. The kernel doesn't even get as far as early printk once it's started loading, to give me any more messages.
<hurricos>
I have tried (from experience working with QorIQ): 1) Following the memory regions used by the original bootloader as closely as possible; 2) using the original fdt instead of the generated one; 3) poking kernel options; 4) stripping kernel optoins away from the oem kernel to see if the kernel breaks (it does not).
<hurricos>
for 3) specifically, manually specifying the console device in the cmdline.
<hurricos>
I may have to do some additional tweaks in what I think is called the Mach files? in `target/linux/mpc85xx/files/arch/powerpc/platforms/85xx/ws-ap3825i.c`. I don't, however, know where to start, because I don't have any console messages at all ...
dangole_ has joined #openwrt-devel
<hurricos>
I'll push to a remote and link that and go to sleep. I can post logs there as well, obviously me blathering about it in IRC is useless without receipts.
<russell-->
hurricos: do you have the vendors kernel source?
<hurricos>
russell--: That was going to be the next thing. I did read that the Russian guy working on it had difficulty getting it. It's kernel 2.6.35.
<hurricos>
What were you working on in this post? Definitely a QorIQ board, almost certainly a P1020, but which one?
<hurricos>
Slimey: stintel mentiond that (fairly sure?) T10XX had U-boot support dropped recently -- sometime in early 2021 -- but that just means no easy u-boot replacements. You should try Stintel's new QorIQ target, which is made for 64-bit ppc; see e.g. http://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036106.html
<Slimey>
https://pastebin.pl/view/3e2a2c33 which i have gotten the image for sophos red 15w to boot but no network at all and cant access flash
<hurricos>
ouch .... I'd bet you'll see difficulties, the only other P101X board Openwrt has, which is on a P1014, hsa been broken for a while: https://github.com/openwrt/openwrt/pull/1773
<hurricos>
Oh, but you got it booting.
<hurricos>
And now that I actually read, the wdr4900's issue is unrelated.
<Slimey>
i have the u-boot source and the rest of the GPL code from the manufacturer
<hurricos>
Great! Would you be so kind as to post them to Github? :^)
<hurricos>
blocktrron: Not layerscape, thankfully. Still powerpc :)
<hurricos>
not that powerpc is good ... you get these giant QorIQ processors but no golang and so many weird bugs :(
<hurricos>
Slimey: So you boot the 15W initramfs on that board? The rest should just be device-tree work.
<hurricos>
Slimey: Find other boards with identical chips and tweak the device-tree to match, is the usual way to improve an initramfs which cannot see flash into an initramfs which can.
<hurricos>
I have only one experience where I turned a non-booting qoriq board into a booting one, and it had to do with properly activating DPAA drivers (P2041RDB -- the P1020 does not have DPAA at all.)
<hurricos>
I'm not sure how I'd even go about detecting where the CPU halts at in the boot process. I don't have any openocd-compatible hardware and have no experience there.
<hurricos>
I do, however, see the JTAG interface on my Extreme Networks WS-AP3825i.
<hurricos>
I'd also like to avoid embarrassing myself like this https://github.com/openwrt/openwrt/pull/3731 again. Better to get something working and then post it than the other way around, imo
<Slimey>
i dont have any experience in working with openwrt development and editing dts files, my biggest problem ;)
<hurricos>
Slimey: Ahh. Well, are you familiar with how to use the build system directly from openwrt.git?
<Slimey>
yup
<hurricos>
And you have some experience with git, herpahs?
* hurricos
wonders how I misspelled that
<Slimey>
not really
<Slimey>
i used it once for something else and forgot cause i didnt have to do it that often
<hurricos>
Alright. Now that you're at the stage you are at, you need, basically, two main tools with git --
<hurricos>
you want to find a previous commit which does what you want (looking at the Sophos board to see when that was ported ....), which you can find using `git blame` ...
<hurricos>
Sadly, the Sophos 15W is back from commit 97e4311fc, 2019-01-13 .....
<hurricos>
... so pick something more recent in the same tree. The Enterasys AP3710i is slightly better but I can also point you at my patches for the AP3825i (despite the fact that they do not boot): https://github.com/hurricos/openwrt/tree/ap3825i
<hurricos>
The second tool you really need is git diff (though I will lump in other tools, like `git am` and `patch -p1 < $patch_file` here.)
<hurricos>
Basically, look at what changes I apply to take openwrt.git@master -> openwrt.git@ap3825i.
pmelange has joined #openwrt-devel
<hurricos>
For mpc85xx, you need 1) a device tree compiled from .dts; 2) a "mach" (??) / platform file (someone correct me: that *is* what you call e.g. `target/linux/mpc85xx/files/arch/powerpc/platforms/85xx/ws-ap3825i.c`, right?); 3) a patch to the Linux kernel version you're building (linux-5.4.y) which actually builds #2 (plus updated Kconfig and config.default to cause that build to
<hurricos>
happen when building the kernel for this target), and 4) updates to OpenWrt build config, in your case centered around `target/linux/mpc85xx/image/p1010.mk` (in mine, `p1020.mk`).
<hurricos>
Slimey: I would start by copying the .dts file from `target/linux/mpc85xx/files/arch/powerpc/boot/dts/red-15w-rev1.dts` into e.g. `.../adtran-bluesocket-2030.dts` and making sure you can compile from source and boot the result.
<Slimey>
ok im taking notes :P
<hurricos>
That will be the biggest hurdle for you, and getting that nicely and neatly done is really important.
<hurricos>
If by some chance in hell you use Emacs, I highly recommend magit and dts-mode for all of this ...
<Slimey>
ok
<hurricos>
Not to go off topic, but I find it funny that so many boards use the same design, QorIQ plus atheros with a cisco-compatible crossover cable.
<hurricos>
.... the one in the WS-AP3825i*, sorry. Same skyworks PAs and board layout.
<Slimey>
yeah im pretty sure its a senao clone of some sorts
<stintel>
hey folks :)
<hurricos>
There are so many of the same clones it's insane. AP3825i uses the same, Aerohive AP370 ... omg.
<Slimey>
hey hey
<hurricos>
Hey stintel, long time no chat! I may be quitting soon
<stintel>
yeah been a while
<stintel>
how's life :)
<hurricos>
Exhausting, but I'm getting the goods now ... I just came back from Europe; if not for COVID I'd have come cut out a few days to come through Romania and get a coffee, heh
<hurricos>
On a new rush now, working on the Next New EOL Device so I can buy 100 of them and deploy them on our mesh, lol
<hurricos>
since Meraki MR16's are drying up :(
<hurricos>
Unfortunately, the Extreme Networks WS-AP3825i isn't booting for me yet; and I'm not sure why, but once U-boot hands off to Linux I get no further console output. It could be crashing very early, it could be that I'm not properly setting console variables .. not sure.
<PaulFertser>
hurricos: what about Meraki MR-18?
<hurricos>
PaulFertser: Too expensive, and no outdoor case compatibility.
<hurricos>
Actually, the problem is less that MR16 is drying up. They're not, they're still very available. But the outdoor case -- MR62 or MR66 -- are now impossible to get when once they were quite easy.
<PaulFertser>
hurricos: outdoor, I see.
<hurricos>
EOL for those isn't still until 2024.
<hurricos>
We're also hitting very occasional concerns about RAM and flash. We have yet to do anything about it, but we've had one oom crash in the last month among ~50 nodes (64MB RAM)
<hurricos>
The last thing: availability of diretional ath9k is pretty much zero. The best we can do right now is ath10k (SXTsq 5 ac @ 50$USD, Nanostation AC 5 Loco EOL, etc).
<PaulFertser>
hurricos: are you buying them new?
<hurricos>
SXTsq's, we would be. Nanostations, perhaps secondhand. Everything else, used.
<stintel>
hurricos: is it ppc based? there have been some reports of ppc devices not booting with gcc10
<hurricos>
stintel: WS-AP3825i is based on the P1020 RDB board, so yes.
<stintel>
hurricos: have you retried since gcc 11 was made default?
<hurricos>
stintel: Ouch, that may be it. I went to my MX60W to reject the possibility but I checked -- Linux version 5.4.143 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16279-5cc0535800)) #0 Tue Aug 31 22:20:08 2021
<hurricos>
I am building on top of master, so gcc-11 thankfully.
<stintel>
ok but that's only since this week ;)
<hurricos>
Or maybe I am misreading and these patches are backported? no ... `./build_dir/toolchain-powerpc_8540_gcc-11.2.0_musl`
<hurricos>
Definitely gcc-11.2.0
<hurricos>
Maybe I can try reapplying this patchset on top of right before we dropped gcc-8.
<hurricos>
Since that's what 21.02.0 apparently used to build apm821xx, I can't imagine that default is that far back.
<hurricos>
Unless you think gcc-11 [should have] no issues. Documentation and links would help me :P
<hurricos>
Let me kick off a build on top of 21.02.0 instead.
<stintel>
let me find the report
<olmari>
PaulFertser Other than the oddball alone unrepticatable index generating, the master image works fine on wdr4900
<olmari>
kernel 5.4
<PaulFertser>
olmari: nice :)
<olmari>
I still have the log if someone ever interested to dig, my FU ended long ago there
<olmari>
..assuming there exist much more life on wdr4900 anyway, (the other bug/issue about the simpleboot stuff)
Borromini has joined #openwrt-devel
<philipp64>
mangix: well, if I don't have IPv6 and I'm packing an image into 13MB...
<hurricos>
No problem! My build still isn't done ;)
<hurricos>
stintel: That is ........ oddly specific, isn't it.
<hurricos>
Build is done. Let me test. I bet it'll "just work."
<hurricos>
Do we have any virt ppc targets like we do mips (malta) or ARM
<hurricos>
I wonder if the kernel is the problem and not the bootloader.
dangole_ has quit [Remote host closed the connection]
<hurricos>
No boot, though it's with an uncompressed kernel.
<hurricos>
and I probably haven't set the bootargs variable properly anyhow.
<hurricos>
No dice with the OEM device tree either.
<hurricos>
I remember FIT images being almost a requirement. Let me try building one of those instead.
Tapper has joined #openwrt-devel
<hurricos>
FIT image decompresses just fine (yay, no Aerohive hack!), but still doesn't boot. Tried with a few various combinations, incl. using oem fdt to silence that weird L2 cache fixup message, but no luck.
<hurricos>
Struggling to think what else would prevent booting of *any* initramfs. Maybe the device tree is poking a GPIO that is linked to something fatal?
<hurricos>
Well, wait. That wouldn't stop me. I've been trying to boot in each of these instances with my fdt and with the vendor's.
<hurricos>
well, I need to port over all of the little extra bits (usb, eth2) from the vendor's device tree anyhow. Maybe something will come up.
<hurricos>
The more I make standard, the less likely something weird will bite me. Vendor's tree also doesn't override bootargs
<mangix>
Had to modify the patches to get them to build with 5.10
<blocktrron>
thanks
<hurricos>
hmm ... maybe I can kexec to a different kernel?
<hurricos>
sigh. This is killing me. The GPL dump would be nice but I doubt I'll ever get it, Extreme Networks has always been one of 'those' companies.
<blocktrron>
hurricos: can you boot the vendor image using bootm?
<hurricos>
yes!
<hurricos>
It boots just fine:
<blocktrron>
One thing i could think of - the vendor bootloader might replace the root-compatible of the device-tree, in which case it might not select one of the arch-setup files
<hurricos>
(both using bootm and using boot, which runs a U-boot script which performs A/B partitioning)
<hurricos>
It doesn't bootm with my device-tree, however
<hurricos>
blocktrron: Fortunately (?unfortunately?) the arch-setup (I think I called it 'platform file' or 'mach' above) is almost identical to the base P1020RDB one.
<hurricos>
blocktrron: Would r2ing the u-boot binary help me figure out whether it manipulates the device-tree?
<blocktrron>
hurricos: have you tried removing the dt-compatible check of the arch-setup to always return true for a platform?
<hurricos>
I'll do that
<hurricos>
The kernel it does boot is old - 2.6.35 - might be too old to expose the device tree in sysfs
<hurricos>
not that that matters, would be handy tool to tell though