<Tapper>
How far off a working build for the Xiaomi AX3600?
<Tapper>
I have seen some talk about it but did not read all the forum posts
<Tapper>
Last time people were still messing around with stock FW and getting ssh access
<lmore377>
Last time I heard there's no officialy supported wifi 6 routers at all. There is a build but it's just built from qualcomm's sdk (which only builds openwrt 15.05 or a custom build of linux with a 4.x kernel.)
<lmore377>
Also the ath11k driver for the wifi card looks like it's really buggy
<pkgadd>
Tapper: *if* those issues can be solved, kind of as in a light-bulb going off, it could happen rather quickly (as in "weeks") - maybe błogıc has some ideas to sort this out as well. but right now there is no solution in reach
<pkgadd>
Tapper: but it should be possible, in theory the necessary bits and pieces are available - but they still need quite some re-assembling to form a functioning prototype
<pkgadd>
Tapper: there have been some attempts of staying closer to the QSDK sources, which appear to have been kind of successful - but getting those issues fixed in a way closer to mainline/ OpenWrt compatibility seems to be difficult
<pkgadd>
Tapper: what you can get now, is an english language international OEM firmware from xiaomi - and with some hacking working (persistent) ssh/ telnet and serial console access, underneath is a typical QSDK firmware, based on an old OpenWrt source and then heavily butchered up
<pkgadd>
but it's cheap in comparison to other ipq807x devices (and already uses the v2 chips, which should make a lot of things easier), roundabout 100 EUR for 2*1.5 GHz ARM64, 512 MB RAM and 256 MB flash - no USB, only 3+1 1000BASE-T Ethernet ports, 802.11ax wireless
<pkgadd>
due to its price, it is rather popular at the moment
<funman>
related: any idea why I need to build toolchain (most likely, just libgcc) with PIE ? if I don't most of userspace tools including busybox segfault on exit
<funman>
target is ramips
valku has joined #openwrt-devel
ivanich has joined #openwrt-devel
Borromini has quit [Ping timeout: 246 seconds]
misterhsp has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
<funman>
ah this also: /usr/bin/ld: /home/fun/openwrt/openwrt/staging_dir/host/lib/libcrypto.a(libcrypto_la-c_all.o): in function `OpenSSL_add_all_digests':
<funman>
c_all.c:(.text+0xa03): undefined reference to `pthread_once'
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
ivanich has joined #openwrt-devel
linzst has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Swant is now known as Swanta-Claus
sergiomiguelrp_ has joined #openwrt-devel
noltari_ has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
swex has joined #openwrt-devel
ivanich has quit [Read error: Connection reset by peer]
ivanich has joined #openwrt-devel
ivanich_ has joined #openwrt-devel
ivanich has quit [Read error: Connection reset by peer]
Borromini has joined #openwrt-devel
dorf has joined #openwrt-devel
<hurricos>
The APM82181 apparently doesn't support MSI-X. I see a patch, target/linux/apm821xx/patches-5.4/802-usb-xhci-force-msi-renesas-xhci.patch, which helps one such board initialize a PCIe to USB3 Renasas chip.
<hurricos>
To do the same thing with a brcmfmac chip, would I look into the drver init code?
<hurricos>
And similarly, can brcmfmac even work without MSI / MSI-X?
<hurricos>
Another question might be whether anyone has any good introductory reading for how PCIe initialization works other -- other than reading source, anyhow.
<hurricos>
I dealt with similar issues initializing an ath10k chip. This was easier since ath10k_pci accepts irq_mode=1 argument, enabling legacy (no-MSI) irq's.
<jow>
nbd: I've now been bitten multiple times by the fact that libuci's uci_delete() does not zero the flags on the given pointer
<jow>
nbd: given a sequence like struct uci_ptr *ptr = ...; uci_delete(ctx, ptr); ptr->value = ""; uci_set(ctx, ptr); - uci_set() will invoke uci_delete() which in turn will invoke uci_expand_ptr() which returns ptr->s since the first delete has zeroed ptr->o but not ptr->flags
<jow>
nbd: question: is there any reason for uci_delete() to *not* zero ptr->flags?
<nbd>
i think it should probably be ptr->flags &= UCI_LOOKUP_EXTENDED
<nbd>
instead of zeroing it
<jow>
I mean it nullifies ->o or ->s depending on the context
<nbd>
but i agree, this should be fixed in libuci
<jow>
so at the very least it should mask UCO_LOOKUP_COMPLETE
urjaman has quit [Read error: Connection reset by peer]
<jow>
so that subsequent uci_ptr reuse does not attempt to use freed memory
<nbd>
i haven't looked at the code in a long time, so i'm not sure if we should mask just UCI_LOOKUP_COMPLETE or also UCI_LOOKUP_DONE
urjaman has joined #openwrt-devel
<nbd>
one question though
<nbd>
why do you call uci_delete before uci_set?
<nlowe>
jow How can I most sensibly use o.depends against the channel dropdown under _freq to check if a 2.4 GHz channel has been selected or not?
<nlowe>
jow I don't think that LuCI should unconditionally show UI to disable 802.11b (so also where a 5 GHz channel is chosen which is N/A) so I am looking to improve this
<jow>
nbd: rpcd calls uci_delete() before uci_set() if the given value is a string and the existing option a list or vice versa
<jow>
this is to ensure overwrite semantics
<jow>
more specific: if type(existing) == list && type(uservalue) == string then uci_delete(), uci_set()
<jow>
elseif type(existing) == string && type(uservalue) == list then uci_delete(), uci_add_list() foreach item in uservalue
<jow>
nlowe: not sure you can
<nbd>
if i remember correctly, you should be able to overwrite a list item with a regular string using just uci_set
<nbd>
and if you want to create a list, you can probably do set, add_list, add_list, ...
<jow>
nbd: downside of the latter approach is that one-element lists will be stored as options then
<jow>
which is not whgat I want
<nlowe>
jow Just tested. That works perfectly. Will/could you merge that? :-)
goliath has joined #openwrt-devel
Immanuel has quit [Quit: Connection reset by reptilians]
<jow>
nlowe: will do
<jow>
nbd: so that libuci fix is not super urgent, will add manual flag clearing to rpcd now
<jow>
nbd: however in the long run I'd say uci_delete() shouldn't leave uci_ptr in an inconsistent state (that is potentially zeroing .o or .s while retaining the UCI_LOOKUP_COMPLETE flag)
linzst has quit [Quit: Leaving]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
ivanich_ has quit [Ping timeout: 272 seconds]
blb4393 has joined #openwrt-devel
Night-Shade has joined #openwrt-devel
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
ivanich_ has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
black_ant has quit [Ping timeout: 256 seconds]
feriman has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
victhor has joined #openwrt-devel
feriman has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
ivanich_ has quit [Ping timeout: 240 seconds]
feriman has joined #openwrt-devel
Ycarus has quit [Quit: Ycarus]
feriman has quit [Read error: Connection reset by peer]
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
feriman has joined #openwrt-devel
ivanich_ has joined #openwrt-devel
ivanich_ has quit [Read error: Connection reset by peer]
ivanich_ has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
feriman has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
figgyc has joined #openwrt-devel
feriman has joined #openwrt-devel
ivanich_ has quit [Ping timeout: 240 seconds]
ivanich_ has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
gch9812133 has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
feriman has joined #openwrt-devel
lmore377_ has joined #openwrt-devel
lmore377 has quit [Ping timeout: 260 seconds]
slh_ has quit [Quit: gone]
feriman has quit [Read error: Connection reset by peer]
<Borromini>
blogic: ping. was there a realtek dev channel? there's someone in #openwrt looking at adding support for another switch
<Borromini>
svanheule[m]: ping
feriman has joined #openwrt-devel
<svanheule[m]>
Borromini: o/
<svanheule[m]>
Borromini: that channel is #rtl83xx
<Borromini>
svanheule[m]: hey, cool, thanks
akira25[m] has joined #openwrt-devel
black_ant has quit [Ping timeout: 272 seconds]
nlowe has quit [Quit: Leaving]
Darkmatter66 has quit [Ping timeout: 260 seconds]
feriman has quit [Read error: Connection reset by peer]
gch981213 has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
feriman has joined #openwrt-devel
victhor has quit [Quit: Leaving]
swex has quit [Quit: swex]
dedeckeh has quit [Remote host closed the connection]
<mangix>
Borromini: did you experience the ramips issue during the 5.4 bump?
feriman has quit [Ping timeout: 260 seconds]
<Borromini>
mangix: as in?
<mangix>
the pcie one
<Borromini>
well it used to be the 2,4 GHz radio just got reset the whole time
<Borromini>
like in the mt76 #444 issue on github
<Borromini>
just a few weeks ago i tried to set up a wds with the dir-860l on the 2,4 GHz radio, and a master build from around that time. and all i saw was that reset issue.
<Borromini>
now the radio isn't found altogether
<mangix>
did you run kernel 5.4 before?
<Borromini>
yes, for testing purposes (mainly to see what DSA would do)
<Borromini>
i never really set up the n radio though. only tried to do that a while ago.
<mangix>
Hmm OK. These pcie problems were getting sorted out by paraka during the bump.
<Borromini>
i'm running master on a DIR-878 A1 and an RT-AC57U, both mt7621 SoCs
<mangix>
it's unfortunate they're stuff here
<mangix>
*still
<Borromini>
mangix: yeah, i had opened a bug report about it in may. but that somehow sorted itself out
<Borromini>
the mailing list thread i found and linked to in the PR also talked about the devices on the bus coming up sometimes, but more often not.
<mangix>
note that the 5.10 PR has more changes applied to the pcie driver upstream than 5.4 has backported.
<Borromini>
i have no C or kernel chops whatsoever so i won't dispute when paraka says that thread was unrelated though.
<Borromini>
mangix: i considered that. but 5.4 will be stable with 20.xx for ramips i suppose. So if this can be fixed it better be, right?
<Borromini>
i considered testing 5.10 as well and i will be
<mangix>
sure but you're posting in a 5.10 PR. If it works with 5.10 and doesn't with 5.4, then we know it's fixed upstream
<mangix>
if 5.10 works, then we know some extra patch(es) need backporting
<Borromini>
sound reasoning.
<Borromini>
i will try testing that in the next few days
<mangix>
anyway all of this is very nice. upstream is listening and fixing bugs.
<mangix>
meaning core openwrt devs don't need to :P
<Borromini>
:P
<Borromini>
i get the impression mediatek is very cooperative compared to a lot of other companies
<Borromini>
is paraka on mediatek's payroll?
<mangix>
no
<Borromini>
ok
<mangix>
mediatek only works on their new ARM stuff
<mangix>
ramips in general is kind of abandoned by them
<mangix>
but because of unrelated reasons (GnuBee devices), other devs picked up the slack.
<Borromini>
ok
<mangix>
the end result being that all local mt7621 drivers were upstreamed
<mangix>
so they don't need to be maintained
<Borromini>
yeah that's pretty neat
<mangix>
next up would be mt7620, but I doubt anyone is interested in that
<Borromini>
aren't those flash and ram starved in comparison?
<rr123>
am I the only getting a broken master(after commit 1302bee12a) on tp link ac1750?
<rr123>
s/only/only one/
<Borromini>
rr123: define 'broken'?
<Borromini>
since i just bricked a tl-wr1043nd v2 with a recent master
<rr123>
can't boot up , have to do tftp recovery
<Borromini>
mine is bootlooping all over the place.
<Borromini>
so yeah. that ac1750 is ath79 as well i reckon?
<rr123>
i was just saying 'master branch is fairly stable and ready for daily use', look what I got...since then I spent 5 hours trying to figure out why a new build did not boot up :(
<Borromini>
:P
<rr123>
yes, ath79, quite a lot of checkin in last one day or two
<Borromini>
i think mine's ready for the trash unfortunately, my makeshift serial wasn't able to salvage it.
<Borromini>
rr123: might be as easy as a typo in some script that breaks stuff.
<mangix>
Borromini: this is why I recommend breed bootloader
<mangix>
impossible to brick that
<Borromini>
mangix: replacing the bootloader requires serial as well no? :)
<mangix>
no
<mangix>
requires the mtd-rw driver
<Borromini>
oh :(
<mangix>
there are instructions on the wiki
<rr123>
magnus1: what's blocking that? breed or those never-die-uboot-with-webserver-to-upload-new-firmware is very useful
<Borromini>
well... i tried to replace the bootloader once on the 1043 v1. bricked that one as well :P
<Borromini>
mangix: frankly, the 1043 wiki page is a mess.
<mangix>
I did that by flashing the wrong one once
<rr123>
s/magnus1/mangix
<rr123>
i absolutely can't type these days
<mangix>
rr123: breed is closed source. you're also touching the bootloader, which is potentially dangerous
<Borromini>
mangix: it's too late i'm afraid. at least the newer stuff i have either has a decent serial connection, or a tftp server, or another sturdy built-in recovery method.
<Borromini>
mangix: got a link to the breed wiki page?
<rr123>
mangix: if memory serves me...the same author did some never-die u-boot before he/she turned into closed breed
<Borromini>
or are you talking about the project's wiki and not openwrt's
<mangix>
pkgadd: yeah so does the archer c7v2. doesn't work.
<mangix>
tftp recovery is hit and miss
* Borromini
hates tp-link recovery procedures
<pkgadd>
mangix: always worked on my tl-wdr4300 and tl-wdr3600 (after retrofitting the necessary OEM update) - I needed to use it multiple times, but I've switched to uboot-mod a couple of years ago
<mangix>
I actually bought this router bricked. The guy sold it after he couldn't figure out how to solder a serial connector.
<rr123>
mangix: for tplink tftp recovery, it will fail after about 10 recoveries for me, i had to use oem stock firmware once, then it's ok for another 10 runs :)
<pkgadd>
same with my tl-wdr3600, it arrived in bricked state (but fortunately the installed bootloader was recent enough to recover without serial console access)
whitewolf has quit [Remote host closed the connection]
<Borromini>
might get something like a GL-MT1300 :)
<mangix>
pkgadd: so for the archer c7v2, tp-link had two bootloaders. the first one had a joke tftp recovery that didn't work. the second one fixed it I believe.
<mangix>
but I was stuck with the first one.
<mangix>
meaning I needed serial.
<pkgadd>
ah, never had a c7 - I always delayed buying one, until I've finally skipped it in favour of ipq806x
user890104_ has joined #openwrt-devel
<rr123>
sad news, it appears the snapshot image from openwrt.org for tplink c7 is broken indeed
user890104 has quit [Ping timeout: 268 seconds]
<mangix>
ipq806x is a special kind of hell. you're lucky if something works :)
goliath has quit [Quit: SIGSEGV]
<rr123>
4 hours "wasted" for me :(
<Borromini>
rr123: i know how that feels.
<pkgadd>
mangix: I really like my nbg6817, no target specific issues at all - I bought it with 100/40 MBit/s in mind, but it still works nicely with 400/200 MBit/s (although I hope to switch to ipq8071a/ ax3600 in the medium future)
whitewolf has joined #openwrt-devel
<Borromini>
pkgadd: the v2's reset button didn't seem to do anything, tried it multiple times. it just kept bootlooping straight through it