<Borromini>
i'm weighing the er4 against the gl.inet brume 1000 as a new edge router
<Borromini>
brume is mvebu 88F3720
<damex>
i don't use openvpn on that device and it will be rather complicated to test with
<damex>
lemmi: could you help providing some numbers for wireguard?
<lemmi>
damex: er-4?
<damex>
lemmi: yeah
<Borromini>
damex: i'm mostly interested in wan to lan with and without sqm :)
<lemmi>
with iperf3 running on the thing: towards er-4 400-450mbps single connection, from er-4 250mbps single and about 400mpbs multiple connections
<Borromini>
but whatever numbers you guys can produce, i'll take. there's a 40 EUR difference between both devices. i'd like to weigh whether the er-4 is worth the extra money
<rsalvaterra>
The EdgeRouter 4 looks similar to the APU2C4…
<Borromini>
lemmi: thanks, is that wan to lan?
<Borromini>
sorry, you said on the er-4. so i assume that's just lan?
<damex>
i was able to get with iperf (multiple connections mode) lan -> wan (nat, no offload) with sqm - 520Mbit, without 942Mbit (line rate)
<damex>
depends on circumstances - using no bridge let me get up to 600Mbit at times
<damex>
with sqm ofcourse
<Borromini>
damex: cool, that sounds pretty neat. so definitely more headroom than the 88F3720
<damex>
i still use one core for irq
<damex>
we could probably get more out of it if we manage to balance queues across cores
<Borromini>
:)
<rsalvaterra>
damex: Have you tried irqbalance?
<damex>
rsalvaterra: yeah, does not help
<rsalvaterra>
I have the same problem on mvebu. I think only the PCIe interrupts can be moved, the other ones are fixed.
<lemmi>
Borromini: since iperf3 was running on the thing, it's possible that the forwarding speed is actually higher.
<lemmi>
Borromini: everything else i tested: gre/gre6/vxlan was doing linerate
<Borromini>
lemmi: neat, thanks a lot.
<lemmi>
and there might still be some performance lying on the table as the cpu wasn't fully utilized
<Borromini>
:)
<lemmi>
but a quick renumbering of the interrupts and receive packet steering didn't help
dopje has joined #openwrt-devel
<damex>
thats because of octeon-ethernet driver
daniele- has quit [Quit: daniele-]
muhaha has quit [Ping timeout: 256 seconds]
victhor has joined #openwrt-devel
<damex>
probably such tests are not as consistent as one you would do with that flent tool
grift has quit [Quit: Bye]
grift has joined #openwrt-devel
Borromini has quit [Ping timeout: 246 seconds]
daniele- has joined #openwrt-devel
daniele- has quit [Client Quit]
daniele- has joined #openwrt-devel
<nitroshift>
nbd, are you around?
daniele- has quit [Quit: daniele-]
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
daniele- has joined #openwrt-devel
daniele- has quit [Client Quit]
kab-el has quit [Ping timeout: 256 seconds]
<rsalvaterra>
I finally bit the bullet and ordered another AR5418 card (AzureWave AW-NE770)…
<rsalvaterra>
The one I got before doesn't have an EEPROM and is basically useless without it.
kab-el has joined #openwrt-devel
<Namidairo>
did it just assume you would pull caldata out of the nether
<rsalvaterra>
Nah, it's just one of those cards which fetches the caldata from elsewhere (it's Apple branded).
<rsalvaterra>
If I had known it didn't have an EEPROM, I wouldn't have bought it (it was very cheap, though).
<nbd>
nitroshift: pong
<nitroshift>
nbd, based on your work on kernel 5.9 i have updated mvebu target to 5.9 too
<nitroshift>
is there an e-mail address where i can send you the patches?
<nitroshift>
i have 2 left hands when it comes to doing pull requests
<nbd>
you can send it to nbd@nbd.name
<nbd>
i usually prefer git send-email as well
<nitroshift>
also, there was a regression in mvebu-pcie.c, patch 407 fixes it
<nitroshift>
message sent
<nitroshift>
i'm running it on both my wrt3200acm's since yesterday
<nbd>
nitroshift: can you make a git patch for me with your signed-off-by, patch description, etc?
<nitroshift>
nbd, for the pci-mvebu regression?
<nbd>
for the 5.9 support
<nitroshift>
oh
<nbd>
openwrt tree
<nitroshift>
i'll try my best
<nbd>
thanks
<nitroshift>
nbd, master or your branch?
<nbd>
against my branch
<nitroshift>
ok
kab-el has joined #openwrt-devel
<nitroshift>
nbd, got as far as git commit, don't know what commit message should say :|
daniele- has quit [Ping timeout: 260 seconds]
dedeckeh has quit [Remote host closed the connection]
daniele- has joined #openwrt-devel
daniele- has quit [Quit: daniele-]
<nitroshift>
i managed to pass the commit phase, what next?
* nitroshift
is an idiot
<rsalvaterra>
nitroshift: What do you need to know?
ldir has quit [Quit: *.net *.split]
ldir- has joined #openwrt-devel
<nitroshift>
rsalvaterra, i need to make a git patch against nbd's staging tree and send it to him
<rsalvaterra>
Ok, you cloned his staging tree, created a new branch and made your commit against this new branch, right?
kab-el has quit [Ping timeout: 265 seconds]
<nitroshift>
ummm... nope
<nitroshift>
i cloned his tree and done all work directly there
<rsalvaterra>
Hmm… is it a one-off patch? If so, it's probably alright.
<nitroshift>
it's a set of patches
<rsalvaterra>
So, it's a series of commits, right?
<nitroshift>
i'm cloning the tree again and create a new branch
<owrt-snap-builds>
build #311 of ath79/mikrotik is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/311 blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Roman Kuzmitskii <damex.pp@icloud.com>, Leon Maurice Adam <leon.adam@aol.de>
<rsalvaterra>
You don't need to clone again, you could just branch from where you were, but ok. :)
grift has quit [Quit: Bye]
kab-el has joined #openwrt-devel
<rsalvaterra>
But don't sweat it, I was exactly where you are about two years ago. Git was a complete mystery to me (and some parts still are).
daniele- has joined #openwrt-devel
<nitroshift>
rsalvaterra, thanks for helping!
<rsalvaterra>
My pleasure. ;)
<nitroshift>
right, i got the clone and a new branch
<nitroshift>
rsalvaterra, can we go in pm so i don't spam the main channel?
<rsalvaterra>
Sure, bring it on! :)
daniele- has quit [Quit: daniele-]
daregap has quit [Quit: daregap]
Tapper has quit [Ping timeout: 240 seconds]
Slimey has quit [Read error: Connection reset by peer]
<damex>
probably not even related, just need a blamelist fixup
kab-el has quit [Ping timeout: 240 seconds]
f00b4r0 has joined #openwrt-devel
<f00b4r0>
adrianschmutzler: ping?
<adrianschmutzler>
pong
<f00b4r0>
adrianschmutzler: I'll reply here instead of on GH for reasons that will be obvious in a sec:
<f00b4r0>
kernel2minor is absolute garbage. It's "documented" in cyrillic, the code is buggy as hell and it's a plague to the mikrotik target that I would very much find the time to get rid of ;P
<f00b4r0>
tl;dr: I'm not interested in reviewing any change to it and I'd recommend that updates be only accepted if they _fix_ anything
kab-el has joined #openwrt-devel
<karlp>
aren't you the same person who just wants to remove mikrotik support? :) are you entirely neutral?
<f00b4r0>
karlp: I don't want to remove support per se.
<adrianschmutzler>
okay, then I'll just leave it be
<f00b4r0>
adrianschmutzler: that's my 2c, others may disagree :)
<f00b4r0>
but that piece of code really is an abomination, I think most will agree on that. I know for a fact that the firmware-minor splitter (which I wrote) needs to work around some of its bugs.
<f00b4r0>
it's also the reason why we no longer properly handle mikrotik NAND devices
kab-el has quit [Ping timeout: 264 seconds]
<f00b4r0>
adrianschmutzler: for full context, the upstream author ('adron-s') is the same one who butchered the uboot sources as a 'loader' to boot mikrotik ipq devices in current PRs.
<f00b4r0>
Hopefully, john-tho's work will make that irrelevant soon enough.
kab-el has joined #openwrt-devel
<ynezz>
damex: it simply builds batch of commits, if it fails, all are to blame, no bisecting is done to find offending commit
kab-el has quit [Ping timeout: 260 seconds]
kab-el has joined #openwrt-devel
grift has joined #openwrt-devel
early has quit [Quit: Leaving]
early has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
kab-el has quit [Ping timeout: 246 seconds]
kab-el has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<anon^_^>
releases/18.06/notes-18.06.9.txt · Last modified: 2020/08/30 17:09 by zorun
kab-el has quit [Ping timeout: 256 seconds]
kab-el has joined #openwrt-devel
feriman has quit [Quit: WeeChat 2.9]
kab-el has quit [Ping timeout: 256 seconds]
kab-el has joined #openwrt-devel
pstef has quit [Ping timeout: 265 seconds]
pstef has joined #openwrt-devel
Borromini has quit [Quit: leaving]
f00b4r0 has quit [Quit: This computer has gone to sleep]
kab-el has quit [Ping timeout: 240 seconds]
kab-el has joined #openwrt-devel
eduardas has joined #openwrt-devel
<eduardas>
hello, I am trying to cross-compile Qualcomm's u-boot from QSDK sources on CodeAurora on Ubuntu 18.04 with the arm-linux-gnueabihf-gcc pre-packaged toolchain and failing
<eduardas>
specifically the configuration for the IPQ6018 chip
<russell-->
eduardas: /me vaguely recalls similar ... maybe need to specify the c standard the code adheres to or find an older gcc or build host
kab-el has quit [Ping timeout: 260 seconds]
<m4t>
not positive but you might want to use e.g. arm-none-eabihf-gcc instead as it's bare metal
<eduardas>
m4t: will do... was not aware it exists.... did not really want to use crosstool-ng as I'm on a weak laptop right now
<russell-->
we built upstream u-boot recently for mt7628 and used the openwrt toolchain
kab-el has joined #openwrt-devel
<eduardas>
russell--: can the OpenWrt toolchain be used standalone somehow?
<eduardas>
just so you know, I'm not specifically doing OpenWrt, so I know little about it.... I actually tried to put together a Yocto-based BSP
<eduardas>
I just thought people here know more about vendor-u-boot-forks
<pkgadd>
the corresponding QSDK toolchain 'should' be able to build it, on an adequately old Ubuntu(?) version (i'd venture something from 2014 or 2015)
<pkgadd>
but yes, OpenWrt toolchains can be re-used for other purposes - if you integrate correctly, which isn't necessarily easy
* russell--
looks for what i did
<pkgadd>
that doesn't mean the QSDK u-boot will actually be functional on a real-world OEM device (you can expect -always- that the vendor has made changes to the source), so make sure to have a reliable fallback (I don't know of any method to fix an ipqxxxx device with a shot pbl or sbl, if you're very lucky it comes with api-nor and can be flashed externally, for NAND you'd be …)
<Hauke>
I used the OpenWrt toolcahin to successfully build U-Boot for other boards, but mostly mainline U-Boot
<eduardas>
pkgadd: I am aware there are more problems ahead... just trying to do one little step at a time :)
<m4t>
actually tools/sysupgrade.c seems to be built with HOSTCC so the arm toolchain shouldn't be the issue i think
<eduardas>
m4t: yes, I noticed that too, but was not 100% sure
<m4t>
i wonder if there is a way to get u-boot to output gcc cmd being used
<m4t>
like V=s on openwrt
<pkgadd>
beyond u-boot, mainline kernel and ath11k are still missing a lot for ipq60xx (and even more for ipq50xx) - expect a lot of work in front of you
<eduardas>
pkgadd: is basic ipq60xx support in mainline at all?
<eduardas>
i.e. at least to get serial login
<pkgadd>
incomplete and still in the process of getting merged (which doesn't mean that it will ever be complete)
<m4t>
'make V=1' seems to work on 2019
<eduardas>
m4t: thank you, it gives me something
<m4t>
2019.07*
<m4t>
eduardas: then you could run the identical cmd and play with cflags like -std= and -l... until maybe it works :D
<eduardas>
m4t: oh dear... such a mess... thanks a lot for finding that
<eduardas>
m4t: though not sure how I am supposed to correctly use that
<m4t>
do you have libbsd-dev installed?
<eduardas>
m4t: yes, does not help
<eduardas>
m4t: result is the same
<eduardas>
m4t: perhaps the linking flag is necessary
<eduardas>
and I don't really provide it
kab-el has quit [Ping timeout: 246 seconds]
<m4t>
might need to add -lbsd then, could edit Makefile and add -lbsd to the end of the HOSTCFLAGS = line. but it doesn't seem those are applied to the final 'cc' cmd in that paste
<m4t>
or possiblly add it to 'HOSTLOADLIBES_dumpimage' in tools/Makefile
kab-el has joined #openwrt-devel
<m4t>
eduardas: okay i got it to compile (cloned it locally)
<m4t>
added: HOSTLOADLIBES_mkimage += -lbsd
<m4t>
but spoiler, the build then fails elsewhere :P
<m4t>
added to line ~138 in tools/Makefile
<eduardas>
m4t: thanks a lot
<m4t>
it might be that i'm trying to compile for x86 and they have stuff hard-coded for the qualcomm crap
kab-el has quit [Ping timeout: 264 seconds]
<m4t>
(kinda seems that way, based on the errors)
black_ant has quit [Ping timeout: 265 seconds]
<eduardas>
m4t: I don't know, it kinda did not error out for me :)
<m4t>
yeah. must be compiling for the sandbox/x86 target then
<eduardas>
m4t: I have both u-boot.bin and u-boot files now
<m4t>
well hopefully they work and don't just brick your board
<m4t>
hehe
<eduardas>
file command gives u-boot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
<eduardas>
m4t: this is hopefully correct?
<m4t>
well u-boot.bin is the one you'd normally want i think
<eduardas>
sadly, I don't have equipment now... it's actually 1:58 here
<m4t>
one of the few times i built u-boot myself i ended up bricking the board and had to get a jtag
<eduardas>
file says u-boot.bin is u-boot.bin: COM executable for DOS... lol ...why? :D
<m4t>
iirc it had a different env location in flash compared to what was already on the board, so 'saveenv' corrupted the executable
<m4t>
probably because 'file' only goes by a few bytes and it randomly matches it