<pkgadd>
mangix: there are basically only two options, ipq807x with qcn5024/ qcn5054 or mt7915e with either mt7621a or mt7622a underneath. the former exists, but is expensive - the later hasn't really reached the market yet (there are some underpowered APs with mt7621a+mt7915e announced, but I don't think you can get them yet)
<pkgadd>
ipq807x has basic target support, and there are some efforts around adding support for the Xiaomi Mi AIoT Router AX3600 - but that isn't really available yet. hnyman seems to have scored the Netgear rax120, due to its price the ax3600 seems to have a little more backing behind it
aszeszo has quit [Quit: aszeszo]
<pkgadd>
it's in sight, but not really there *yet*. ipq60xx and ipq50xx will be cheaper, but that's still very volatile (patches are still in the process of getting processed mainline, both basic SOC support and for ath11k)
<pkgadd>
due to the well-known SOCs underneath, Mediatek m7915e might be quicker to get OpenWrt support - once some devices shipping it arrive on the market (although I'd skip anything with mt7621a in favour of waiting for mt7622a+mt7915e). but ipq807x pretty much has a head start so far
<pkgadd>
Xiaomi Redmi Router AX6 would be a cheaper variant of the AX3600, only two radios instead of three (the third radio is a 1x1 ath10k 2.4+5 GHaz WLAN card, originally meant for Xiaomi's AIoT ecosystem) - but lower tx power (half of the ax3600 values)
<blocktrron>
pkgadd: mt7621 + mt7915 is available since months in form of the D-Link DIR-X1860
<pkgadd>
blocktrron: ah, o.k., thanks
greearb_ has quit [Remote host closed the connection]
greearb_ has joined #openwrt-devel
<blocktrron>
It's niche i admit
<blocktrron>
And mt7915 support isn't there in master yet, but i think this is the path of least resistance atm
<blocktrron>
Also i assume the MT7915D+MT7621 will be the most prominent choice for sub-100 2x2 DBC designs.
<pkgadd>
I've seen a lot of activity around it on linux-wireless@vger, so I just assume it won't be too far away. and obviously using a well-known SOC underneath will make supporting it easier ('just' the new wireless driver to take care of), but at least mt7621a imho feels too slow for an 802.11ax capable router
<blocktrron>
Well, certainly a upgrade considering 2x2 802.11ac gear with 100 Mbit/s ports
<pkgadd>
the ax3600 with ipq8071a and 4*1.4 GHz cortex a53 is kind of tempting me, considering its price to performance ratio
andi- has quit [Remote host closed the connection]
andi- has joined #openwrt-devel
swalker has quit [Remote host closed the connection]
swalker has joined #openwrt-devel
hbug has joined #openwrt-devel
victhor has quit [Ping timeout: 260 seconds]
gch9812131 has joined #openwrt-devel
hbug___ has quit [Ping timeout: 240 seconds]
gch981213 has quit [Read error: Connection reset by peer]
<mangix>
pkgadd: i asked as gch981213 added an mt7621 unit with ax
<mangix>
that specific unit seems to have pretty little RAM though...
tchebb has joined #openwrt-devel
<pkgadd>
mangix: hmm, which device?
Devastator has quit [Quit: ZNC 1.8.1+deb1~bpo10+1 - https://znc.in]
Devastator has joined #openwrt-devel
swalker_ has joined #openwrt-devel
caravel has quit [Quit: Konversation terminated!]
swalker has quit [Ping timeout: 260 seconds]
<pkgadd>
ah, https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=23be410b3d1267c752bf9f6e5c8f5a514dc562c4 -- the lower-end ipq50xx/ ipq60xx devices will probably also ship with 256 MB RAM (hopefully few)
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
<pkgadd>
e.g. Xiaomi Mi AX1800, IPQ6000, 4*1.2 GHz, 128 MB flash, 256 MB RAM
<mangix>
maybe ath10k devices need more RAM because of the firmware. who knows.
<mangix>
erm eth11k
<pkgadd>
at least the proprietary driver doesn't seem to be that bad, looking through the early ax3600 reports suggests around 256 MB RAM usage (of 512 MB)
<pkgadd>
using xiaomi's OEM firmware
daregap has joined #openwrt-devel
nitroshift has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
daniele- has joined #openwrt-devel
skolev has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
skolev has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
<russell-->
blogic: in netifd's system-dummy.c, shouldn't line 60 be "bridge" instead of "brctl"?
<xback>
the boards contain a onboard ath10k and we've placed a ath9k 2x2 in the pcie slot
<xback>
ps. I;m running latest 19.07
<f00b4r0>
xback: fwiw there seems to be very few people interested in keeping mikrotik devices afloat, to the point I wonder if we should just drop them going forward
<xback>
drop Mikrotik?
<f00b4r0>
drop support for their devices
<f00b4r0>
to boot, the NAND-based device support is completely broken-by-design.
gch9812132 has joined #openwrt-devel
<xback>
I'm more than willing to aid in keeping them alive
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
<f00b4r0>
if anything we should advertise that and not mark these devices as "supported" in a way that can confuse prospective buyers into believe the support is on par with anything else
<f00b4r0>
believing*
gch981213 has quit [Read error: Connection reset by peer]
gch9812132 is now known as gch981213
<f00b4r0>
xback: those 922 are NAND-based, right?
<damex>
f00b4r0: there is really interesting devices from mikrotik...
<f00b4r0>
damex: sure, but nobody really cares and mikrotik is (actively or passively) making it very hard for us to deal with their stuff
<damex>
hEX PoE (RB960PGS) is quite unique
<damex>
f00b4r0: hmm... i thought people still use them and add support for their boards (from time to time?)
feriman has quit [Quit: WeeChat 2.9]
<damex>
what kind of support do you need for it to be justified? :)
<f00b4r0>
damex: it's commit and forget, and most of the time it's "commit garbage and forget"
<zorun>
there definitely is interest to keeping them supported
<f00b4r0>
good to hear
<karlp>
are you saying that only mikrotik support is "garbage and forget"? that seems particularly prejudiced.
<zorun>
but I agree these revision changes are really annoying (we are considering changing vendor just because of this)
<f00b4r0>
karlp: lol; touché
<damex>
i see that they're kinda 'generic target' that supports all of them. would it be better if they would get split and build would be per device
<zorun>
damex: that's a sensitive discussion :)
<f00b4r0>
damex: we've already been through that avenue. I suspect this is going to make things even worse, but I'm not keen to reopen that debate
<damex>
maybe if we (or someone) pay more attention to each device in question - quality of the outcome might be better
<f00b4r0>
...
<damex>
f00b4r0: uh... okay :(
<f00b4r0>
xback: anyhow, those NAND device, ISTR you're deploying them in the field. It's probably best if you're aware you're sitting on a ticking timebomb with each of them
<xback>
f00b4r0: yes. they are NAND
<xback>
we currently roughly have about 100 of them running in the field offshore
<f00b4r0>
ugh
<f00b4r0>
don't update them too often then :P
<xback>
the only issue ever seen so far is that sysupgrade sometimes fails
<xback>
something appeared to be changed in nand
<xback>
and I need to set sysupgrade executable bit again at that point
<f00b4r0>
well
<xback>
I did not encounter that with rb912 (also nand)
<f00b4r0>
that sounds pretty harmless in comparison to what can (and will) happen
<f00b4r0>
the kernel partition will eventually die abruptly. We do not manage badblocks _at all_ on that partition.
MarioH has joined #openwrt-devel
<f00b4r0>
thanks to the extremely stupid kernel2minor "workaround"
<xback>
is that patch backportable to 19.07?
<f00b4r0>
the one I linked?
<f00b4r0>
I suppose so
<xback>
just tried and didn't apply. checking now
<xback>
ah. 19.07 is at v0.3 still :-)
<f00b4r0>
heh
<f00b4r0>
note that this is still not in master
<f00b4r0>
not sure why it's not so.
<xback>
no worries. I'll take care of it
<xback>
I've been absent for quite some time due to other tasks
<f00b4r0>
i can't guarantee this'll fix your woes, it's possible mikrotik once again did something clever ;P
<f00b4r0>
no worries, I'm currently rather busy setting up shop (I quit my job and am going full freelance ;)
<f00b4r0>
john-tho has been extremely helpful in the meantime, btw
<stintel>
f00b4r0: congrats!
<f00b4r0>
stintel: heh, we'll see how that pans out :)
<f00b4r0>
but thanks
<xback>
I followed the discussion from a distance with john-tho
<xback>
very interesting stuff
<xback>
and congratz with your shop :-)
<stintel>
going full freelance + moving to Bulgaria (10% tax) were some of the best decisions I ever made
<f00b4r0>
he basically implemented everything I was looking forward.
<f00b4r0>
native compressed elf boot, and he also has a rather neat fix for the 4K_SECTORS nightmare
<nick[m]>
is there an example how to findout the correct settings for rgmii ethernet interface?
<f00b4r0>
stintel: i hope it'll be the same for me. I guess the timing is tricky (right for me, not so right for the rest of the world), but I feel confident :)
<damex>
nick[m]: maybe stock will have it in device tree? or uboot?
<f00b4r0>
stintel: out of curiosity, you moved to Bulgaria from ?
<stintel>
f00b4r0: Belgium
<f00b4r0>
oh wow. I see, quite a jump.
<stintel>
well 50% tax is pure theft
<stintel>
so yeah, quite the jump from 50 to 10 :P
<f00b4r0>
heh. I lived and worked in Belgium (BXL) for 6 months. Didn't like it one bit ;P
<stintel>
bxl is horrible
<f00b4r0>
but yeah, I thought France had a brain damaged tax system; that was until I went to Belgium ;P
<stintel>
hahaha
<Namidairo>
> he also has a rather neat fix for the 4K_SECTORS nightmare
<Namidairo>
but I love spending 10 minutes waiting for the kernel to flash
<f00b4r0>
heh
<f00b4r0>
I wish he'd get some feedback from linux-mtd. If any one of you knows someone there, it'd be a nice help to raise awareness to his posts
<f00b4r0>
xback: actually I htink he's about to resend. Maybe tell him he should CC someone?
feriman has joined #openwrt-devel
<nick[m]>
damex: then I have to extract the devicetree frist ;) what do u mean with uboot? never heard of that
<nick[m]>
u can extract the values from there
<damex>
nick[m]: does device have uboot?
<damex>
how does it boot and what kind of device is it?
<nick[m]>
damex: yes it has uboot
<damex>
uboot can help with extracting device tree and it might be different from what your OS sees
<xback>
f00b4r0: just resend. I can pickup and ping from there
<nick[m]>
damex: it is a ar9342 soc (nanstation ac loco)
<nick[m]>
damex: okay, nice :) so I just google a bit? :D
<f00b4r0>
xback: don't tell *me* :)
<damex>
nick[m]: i think `fdt print /` is the one you're looking for
<damex>
in uboot
<nick[m]>
nice I will try! thanks :D
<damex>
varies so might be just `fdt print`
<Borromini>
good luck and congrats f00b4r0 :)
<f00b4r0>
thx :)
Skeleswant has quit [Remote host closed the connection]
Swant has joined #openwrt-devel
<nitroshift>
nbd, ping
<nick[m]>
damex: my uboot on the device does not have fdt :/
Swant is now known as Skeleswant
<damex>
nick[m]: you can try to dump uboot binary and do binwalk/extract-dtb
<damex>
uboot binary partition*
<damex>
nick[m]: if it boots - you can extract dt from running system if it runs with dt
<nick[m]>
damex: the device tree is in the uboot partition? I always thought that it is the firmware section
<nick[m]>
damex: I have a working openwrt on the current device. but I have rgmii-id, and I would like to switch to rmii ;)
<damex>
nick[m]: depends. some devices have device tree embedded with uboot. that way you have uboot initalize device using dt
<nick[m]>
damex: okay, I will boot and make dumps of the uboot partition. and try to find a dts there :) and I will flash airos again and try to dumb the flash there, too
<nick[m]>
thanks! :)
<damex>
nick[m]: you can try to use binwalk on airos firmware
<nick[m]>
ahh okay :O
<damex>
might find (and extract?) what you're looking for (or not~)
dedeckeh has joined #openwrt-devel
<nick[m]>
damex: should there popup something like "device tree image (dtb)"? Cause it does not xD
grift has joined #openwrt-devel
<damex>
nick[m]: yeah, should be
<nitroshift>
i've brought mvebu to 5.9
<nick[m]>
damex: tried "extract-dtb" and nothing useful :/
<nick[m]>
I will try duming uboot :D
<nick[m]>
damex: or is there some source there u can find datasheets for ar9342 socs?
<damex>
nick[m]: not sure about that one. you need info about your mdio? ag71xx as in AR8216/AR8236/AR8316 ?
<rsalvaterra>
nick[m]: I have for 9331 and 9344, but not for 9342… :/
<damex>
or something else?
<dengqf6>
I think 5.10 will be the next LTS
grift has quit [Ping timeout: 260 seconds]
<nick[m]>
damex: isn't the mdio between MAC and PHY? so u mean that tx and rx delays are for the mdio and not the the actual phy?
<nick[m]>
rsalvaterra: same xD
grift has joined #openwrt-devel
<nick[m]>
damex: I need Atheros AR8035
<nick[m]>
I found a datasheet, not sure which is the correct value, I would believe it is "tmdelay" "MDC to MDIO output delay", that is min 0 and max 4ns...
Redfoxmoon has quit [Ping timeout: 260 seconds]
<blocktrron>
nick[m]: see which registers at803x.c touches depending on the phy mode
<blocktrron>
The AR934x and subsequent chips are also capable of introducing delays on the mac side
MichaelOF has joined #openwrt-devel
andi- has quit [Remote host closed the connection]
<nick[m]>
blocktrron: thanks for the tipp! :) Just locking at the driver and on the datasheet damex linked on page 48 "rgmii rx clock delay control". so the driver just sets this to enabled if rgmii-id or a different delay mode is configured
victhor has joined #openwrt-devel
<nick[m]>
so this is only phy mode delays, and I wanted what blocktrrron describes, the delays on the mac side :)
<nick[m]>
or am I compltely wrong? if I set the mode to rgmii on a ar9342 soc, they don't work anymore. So I thought I have to set the delays manually to the correct value?
Redfoxmoon has joined #openwrt-devel
Redfoxmoon has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
<nick[m]>
I read something like ""rgmii" should be the preferred mode, which allows the mac layer to turn off the dealys completely if they are not needed." ?
<nick[m]>
MAC (add delays "rgmii") <-> Phy (add delays "rgmii-id")
<nitroshift>
stintel, ping
stintel has quit [Remote host closed the connection]
stintel has joined #openwrt-devel
muhaha has joined #openwrt-devel
grift has quit [Ping timeout: 260 seconds]
<xback>
f00b4r0: it seems latest master has issues with RB922 (nand ..)
grift has joined #openwrt-devel
<xback>
will need to sort that out first
<f00b4r0>
xback: as I said, we don't do badblocks management. From that, anything goes.
<f00b4r0>
xback: if you want to rule out storage in your wifi tests, you can always netboot :)
<xback>
got it running now
<f00b4r0>
i'm curious if my patch will fix it for you, that would suggests they're deploying the new scheme in existing devices
<xback>
well. I want to test it right away. as I got various revisions laying around now
<f00b4r0>
s/existing/old/
<xback>
made 2 builds. one without and one with your latest patch
<xback>
currently running without the patch
<f00b4r0>
note that the patch is a NOP on old-style hardware
<f00b4r0>
i tried to be thorough in the commit message, let me know if it needs improvement
<xback>
interesting .. on master even without the patch. the radio's are recognized.
<xback>
on 19.07 they are not. only on this board
<xback>
other boards behave well
madwoota has quit [Ping timeout: 244 seconds]
<xback>
I've already made some backporting efforts in my staging. but I guess it's still lacking some more ports
<xback>
probably the extraction script
<zorun>
f00b4r0: thanks, I missed that patch. I had to apply the previous one to 18.06, and that was enough for the newer revisions I got
<f00b4r0>
zorun: no worries, the new patch isn't in master yet, i wouldn't be comfortable backporting somethign that hasn't lived at least a few weeks in master
<f00b4r0>
i don't quite remember what has and hasn't been backported
<zorun>
yes, sure, it's just that if newer hardware doesn't work as expected, I know where to look ;)
<zorun>
mostly everything you sent has been backported to 19.07
<zorun>
18.06 has less changes, but this is to be expected
<f00b4r0>
sure. 18.06 is EOL, right?
<f00b4r0>
xback: in any case, if master works for you, that means my work is done :D
<xback>
very true
<xback>
thanks for being a listening ear ;-)
<zorun>
more or less, a last 18.06 release has been planned for months (but nobody got the time to push it through :/ Hauke did some work on it recently)
<f00b4r0>
:D
daniele- has joined #openwrt-devel
madwoota has joined #openwrt-devel
madwoota has quit [Changing host]
madwoota has joined #openwrt-devel
<zorun>
f00b4r0: in your patch, you mention the need for adaptation in hotplug scripts, did you send such a patch already?
<f00b4r0>
zorun: no; because so far no supported device use that new scheme. This patch is needed by ipq4019 devices which are still in PR
<f00b4r0>
the PRs have that change.
muhaha has quit [Ping timeout: 260 seconds]
grift has quit [Ping timeout: 260 seconds]
<zorun>
ah, right, that makes sense
madwoota has quit [Read error: Connection reset by peer]
madwoota has joined #openwrt-devel
madwoota has quit [Changing host]
madwoota has joined #openwrt-devel
<damex>
https://github.com/openwrt/openwrt/pull/3519 only issue that i have had with that one is naming. any idea if something else needs to be done before it could be merged ? it is a pretty simple upstream supported board
<damex>
so i named it exactly as uboot and kernel upstream expects it to be
grift has joined #openwrt-devel
valku has joined #openwrt-devel
samantaz_ has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
grift_ has joined #openwrt-devel
grift has quit [Read error: Connection reset by peer]
grift_ has quit [Client Quit]
grift has joined #openwrt-devel
<grift>
ok so i have it do dns over tls using the google servers
<grift>
too worn out to fork, took me the whole day to get unbound running
<aparcar[m]>
ok
<adrianschmutzler>
flash layout is in DTS; we should try to prevent redundancy here
<adrianschmutzler>
The idea is to provide complementary information
<adrianschmutzler>
or at least information that is general but cannot be extracted by a general approach
<adrianschmutzler>
like flash size
<aparcar[m]>
yep
<adrianschmutzler>
therefore, also leds/buttons are a bit redundant for my taste
<aparcar[m]>
wow the amount of usb standards is awkward
<aparcar[m]>
yea a parser could extract that automatically
<adrianschmutzler>
while e.g. narrowing down usb ports to just mode and size might actually create a benefit
<aparcar[m]>
agree
<adrianschmutzler>
LEDs/Buttons could be something worth keeping optionally ...
<adrianschmutzler>
But personally I would not add that to yaml file when adding a device
aszeszo has quit [Quit: aszeszo]
<adrianschmutzler>
btw I still have the old version of your size_compare.sh in my staging
<adrianschmutzler>
do you plan working on this again?
<aparcar[m]>
adrianschmutzler: yea I could give it another spin
<aparcar[m]>
is plural of usb "USBs"?
<adrianschmutzler>
busses?
<aparcar[m]>
nevermind
<adrianschmutzler>
I would then add a noun, e.g. usb_ports, usb_adapters, ...
Slimey has quit [Read error: Connection reset by peer]
<aparcar[m]>
I just go ith usb now
Slimey has joined #openwrt-devel
<aparcar[m]>
adrianschmutzler: btw thomas just joined the github PR discussion. I hope we find a compromise that keeps bloat out of the files but is valuable for wiki maintainers
<rsalvaterra>
Hauke: But with squashfs you only have to compress once. If the decompression speed is still the highest at the highest compression ratios, it could be an interesting choice.
<rsalvaterra>
The buildbot won't be happy, though. :P
<Hauke>
yes, it could improve the situation
<Hauke>
the compression also depends on the content
<Hauke>
it alos depends on the decompression speed and ram usage
<Hauke>
someone has to try it and do some mesurements
Night-Shade has joined #openwrt-devel
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<pkgadd>
in the grand scheme of things, zstd support is still very recent, while lzma and xz are well known. it'll take a bit until someone really tries getting it working as well
<pkgadd>
hard enough to find bootloaders that can read xz - and not pre-mainline squashfs lzma (yes, I know, only the kernel needs to be readable, but still)
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aparcar[m]>
Kernel allows zstd file systems since 4.14 I think. So that should be a problem. I don't mean to change kernel compression itself