**** BEGIN LOGGING AT Mon Mar 01 02:59:57 2021 Mar 01 03:36:43 build #13 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mediatek%2Fmt7623/builds/13 Mar 01 03:42:25 guidosarducci: i had an iproute2 build failure on oxnas/pogoplug-v3, a weird message complaining that libbpf was version 0.3.0 but it needed at least 0.1.0 Mar 01 04:00:21 russell--: that does sound weird. Is the log online somewhere? Mar 01 04:02:51 not yet, i worked around it by hacking the configure script to always pass Mar 01 04:03:13 building the full version Mar 01 04:06:01 russell--: could something be broken in the environment? Or causing problems with shell arithmetic or test utilities? I'll have a look at the sources, but know it built fine on mips, arm, x86... Mar 01 04:06:31 build #14 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mediatek%2Fmt7622/builds/14 Mar 01 04:27:40 build #13 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/bcm63xx%2Fgeneric/builds/13 Mar 01 04:30:46 CONFIG_TARGET_oxnas=y Mar 01 04:30:46 CONFIG_TARGET_oxnas_ox820=y Mar 01 04:30:46 CONFIG_TARGET_oxnas_ox820_DEVICE_cloudengines_pogoplug-series-3=y Mar 01 04:30:57 CONFIG_PACKAGE_ip-full=y Mar 01 04:46:43 guidosarducci: https://personaltelco.net/~russell/iproute-full-compile.txt Mar 01 04:47:19 russell--: right-o, let's see... Mar 01 04:53:29 russell--: not much there I'm afraid. From the configure, it's failing a test compile against libbpf. Do know libbpf built OK? Mar 01 04:54:17 russell--: maybe also edit the compile invocation in "configure" to save its output instead of to /dev/null. Mar 01 04:55:37 yeah, bpftools built fine Mar 01 04:55:48 russell--: weird box BTW, naked PS inside with exposed mains power. Mar 01 04:56:43 i replaced the power supply in mine Mar 01 04:56:56 russell--: could you try saving the failing compiler output as above? (I tried a build but still making toolchain) Mar 01 04:57:18 my build box is doing something else at the moment Mar 01 04:57:53 damex: ping Mar 01 04:58:20 Grommish: pong Mar 01 04:58:50 damex: So I finally pulled a dts file for the device. cn7020 Mar 01 05:00:25 russell--: mine's still making gcc. After your workaround/hack did ip-full build OK? Mar 01 05:00:37 yes Mar 01 05:01:09 damex: https://gist.github.com/Grommish/07fcbb5f95599d657792de0bf055469a I think I want to incorp it, does it look like it should work? Mar 01 05:01:49 i probably am not exercising anything related to libbpf at runtime though Mar 01 05:04:27 Grommish: looks a bit unformatted and seem to have redundant definitions but overall looks like it should work. Mar 01 05:05:10 damex: I pulled it from the running system, so it wouldn't surprise me Mar 01 05:05:33 ah, okay Mar 01 05:05:53 russell--: the fact it linked is OK for now. I have test script I can share if you want some exercise. :) Mar 01 05:06:06 russell--: gcc build done.. now kernel. Mar 01 05:06:09 if pulled from running system then yes, it should work. it might be broken though. due to how kernel patches up device tree on the fly Mar 01 05:06:18 but that one seem to be ok Mar 01 05:08:57 it seems to fail first time, make package/iproute2/compile again and it seems to succeed Mar 01 05:10:54 guidosarducci: I'd consider it... though my fu for generating the new configs probably needs work... Mar 01 05:11:45 build #13 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mvebu%2Fcortexa53/builds/13 Mar 01 05:13:40 /usr/lib/libgcc_s.so.1: file not recognized: file format not recognized Mar 01 05:13:40 collect2: error: ld returned 1 exit status Mar 01 05:14:22 that's the output of the configure line Mar 01 05:15:09 $CC -o $TMPDIR/libbpf_test $TMPDIR/libbpf_test.c $LIBBPF_CFLAGS $LIBBPF_LDLIBS >/tmp/libbpf.log 2>&1 Mar 01 05:16:02 philipp64: I missed something I think, you're referring to my earlier ping re: x86_64? Mar 01 05:16:53 russell--: ld complaining about libgcc doesn't sound good, how would things even get that far? Mar 01 05:17:18 build #13 of mpc85xx/p1010 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mpc85xx%2Fp1010/builds/13 Mar 01 05:19:36 guidosarducci: yes regarding x86_64 Mar 01 05:20:48 philipp64: great, thanks. a couple of folks are working on a 5.10 update for x86_64 and running into build problem related to libelf Mar 01 05:21:10 Is there a thread about it? Mar 01 05:23:17 philipp64: tools/libelf is actually an ancient lib unneeded on Linux, and can break builds looking for the modern elfutils. TL;DR it's fixed by the first 3 commits of my PR https://github.com/openwrt/openwrt/pull/3855, which has links to the x86_64 PRs. Mar 01 05:24:20 philipp64: was hoping you, ldir- or someone caring for x86 might take a look Mar 01 05:25:29 russell--: my build. finished. successfully. I see ip-full, libbpf packages all there. Mar 01 05:26:54 guidosarducci: could you have a dirty build environment, considering I just built mine new? Mar 01 05:27:52 ^^ I meant russell-- Mar 01 05:28:16 this is the command line that failed: arm-openwrt-linux-muslgnueabi-gcc -o config.Ow9olb/libbpf_test config.Ow9olb/libbpf_test.c -I/home/openwrt/src/lede/staging_dir/target-arm_mpcore_musl_eabi/usr/include -L/usr/lib -lbpf Mar 01 05:28:50 i'll try a dirclean for giggles Mar 01 05:29:30 russell--: OK, I'll rebuild the package just to see... Mar 01 05:30:25 build #13 of ipq40xx/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ipq40xx%2Fmikrotik/builds/13 Mar 01 05:31:01 i could get it to fail reliably with make package/iproute2/{clean,compile} with the four line .config stub above Mar 01 05:34:48 russell--: my rebuild was also successful. One difference is my config builds all the iproute2 packages, but I don't see that making a difference. ip-tiny, ip-full, tc are different variants getting built in different dirs. Mar 01 05:36:01 russell--: I'll turn off all but ip-full from iproute2... Mar 01 05:42:10 russell--: that also worked. Mar 01 05:44:34 russell--: earlier you said it would succeed compiling after failing the first time. How does that mesh with reliably failing now? Did something change? Mar 01 05:52:19 russell--: This still bothers me: /usr/lib/libgcc_s.so.1: file not recognized: file format not recognized Mar 01 05:53:35 russell--: to be clear, did you edit the path, or is it trying to use the system libgcc rather than cross-compiled one in staging_dir? Mar 01 05:59:37 guidosarducci: that is what came out of the configure compile command Mar 01 06:00:25 same error after a make dirclean world Mar 01 06:00:39 the build machine is an up-to-date archlinux box Mar 01 06:06:21 IPT_LIB_DIR=/usr/lib/iptables XT_LIB_DIR=/usr/lib/iptables ... not clear what those are used for, but they are the build host's Mar 01 06:08:28 build #12 of gemini/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/gemini%2Fgeneric/builds/12 Mar 01 06:11:18 that looks normal Mar 01 06:12:18 guidosarducci: the only thing i edited was that configure line Mar 01 06:18:25 russell--: yeah, understood. the other difference is I'm using a bigger .config normally used for iproute2/bpftool/kmod testing. Why that should make difference I'm not sure. Maybe I should try your 4-line .config? Mar 01 06:30:32 yes, please for sanity sake Mar 01 06:31:39 russell--: Can you try editing something? I have an idea... Mar 01 06:32:11 russell--: vi staging_dir/target-arm_mpcore_musl_eabi/usr/lib/pkgconfig/libbpf.pc Mar 01 06:33:08 russell--: change the line to be: libdir=${exec_prefix}/lib Mar 01 06:33:50 russell--: from libdir=/usr/lib Mar 01 06:35:10 russell--: pkg-config for iptables also doesn't seem right, save later Mar 01 06:35:42 russell--: try rebuild after edit, and also capture that configure output? Mar 01 06:39:57 Hey everyone! Just built a firmware image from the latest main source for WRT32X Venom and was curious if it's useful to anyone that it worked great! I've been searching around due to the kernel size/partition size changes to see where to provide feedback that it's working for venom as of latest main source. I used a sysupgrade.bin with 'force Mar 01 06:39:57 upgrade' & wipe settings coming from an OpenWRT image [19.07.6 r11278-8055e38794] Mar 01 06:54:02 build #12 of mxs/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mxs%2Fgeneric/builds/12 Mar 01 06:54:43 russell--: Any news? I'll need to go soon, but definitely spotted problems in 2 pkg-config files. Mar 01 07:12:44 bob82: You could pop in a message at https://forum.openwrt.org/t/increasing-mamba-and-venom-kernel-partition-to-6mb/87807 Mar 01 07:13:28 bob82: Also, I'm also from Cincy :) Mar 01 07:16:17 Grommish awesome, will do! Haha, cool! Just moved to Ohio actually! Sorry, it keeps kicking me out over and over Mar 01 07:16:57 bob76: Ignore the weather and you'll be fine :D Anyway, welcome here as well Mar 01 07:20:29 guidosarducci: sorry, back at keyboard Mar 01 07:23:36 initial try worked Mar 01 07:26:14 command line becomes: arm-openwrt-linux-muslgnueabi-gcc -o config.Btp06J/libbpf_test config.Btp06J/libbpf_test.c -I/home/openwrt/src/lede/staging_dir/target-arm_mpcore_musl_eabi/usr/include -L/home/openwrt/src/lede/staging_dir/target-arm_mpcore_musl_eabi/usr/lib -lbpf Mar 01 07:26:53 and the compile is silent, no error Mar 01 07:27:39 (in the configure script in have_libbpf_basic) Mar 01 07:28:16 russell--: glad to hear it. Still don't understand why it worked on my build. Mar 01 07:29:23 so, why does libdir have /usr/lib? Mar 01 07:29:59 russell--: considering I don't have a host libbpf installed. And why did your second compile sometimes work? I give up -- too late. Will send a fix tomorrow and cc you. Mar 01 07:31:16 russell--: /usr/lib is usually the host default, but most config files use a $prefix variable that can be overridden e.g. for cross builds. Mar 01 07:31:45 CONFIGURE_ARGS usually do this automatically Mar 01 07:32:44 Check ./include/host-build.mk and package-defaults.mk Mar 01 07:32:58 If you aren't using it, or overriding it, it can cause issues (i've had both happen) Mar 01 07:33:11 i do have some /usr/lib/libbpf*'s on my build host Mar 01 07:34:42 build #12 of at91/sama5 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/at91%2Fsama5/builds/12 Mar 01 07:36:21 russell--: I think this slipped by because nothing used libbpf's pkgconfig before. You happy now that the electrocution router works? :-) Mar 01 07:37:44 I need a networking diety to help me figure out why dnsmasq doesn't work unless the WAN port is UP and connected via DHCP ;p Any volunteer? Mar 01 07:40:17 the advantage of living on the bleeding edge is you find bugs when they are fresh in the perpetrators mind Mar 01 07:41:18 russell-- haha Mar 01 07:41:47 russell--: at least I discovered a new, truly dangerous router. :) clocking out now, take care Mar 01 07:42:23 guidosarducci: g'night1 Mar 01 07:47:27 build #12 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/octeon%2Fgeneric/builds/12 Mar 01 08:18:22 Anyone know if I should be concerned my ethernet ports don't have a ring buffer? I'm seeing packet drops, and the common fix is up the buffer, but I don't seem to have one.. Mar 01 08:19:17 *shrug* Cannot get device ring settings: Not supported Mar 01 08:27:50 Grommish, isnt increasing buffers what lead to "problems" like bufferbloat ? in case of dropped eth frames shouldnt other stuff like the (buggy) pause frames be used Mar 01 08:28:55 No idea. The CPU doesn't spike and the device doesn't chug, but I get dropped packets Mar 01 08:30:01 I'm not sure if I just have a dodgy device build (like missing something), or if it's not supposed to be there, etc. I do know that the common "fix" for the dropped packets seems to be to increase said ring buffer Mar 01 08:32:34 dunno what hardware you are using - but investigating sth like https://forum.openwrt.org/t/mt7621-mt7530-programming-disabling-flow-control-on-all-ports/76006 Mar 01 08:33:10 maybe its sth similar Mar 01 08:33:17 I can't tell you how many times I built an image without the ethernet driver :D Mar 01 08:34:26 plntyk: Thanks :) That doesn't seem to apply, but I appreciate you looking! Mar 01 08:47:32 dropped packets might also be hardware defect or some other issue Mar 01 08:48:52 its spread across the 3 eth ports.. eth0 is wan, eth1 and eth2 are bridged Mar 01 08:49:13 getting half from 1 and half from 2 to equal the eth0 dropped number Mar 01 08:53:02 creating a ticket with affected eth-hardware and maybe ask in forum if someone with same unit or same eth hardware on other devices might replicate Mar 01 08:53:18 doing iperf might be enough to trigger Mar 01 08:58:43 nice more build breakage hihihi Mar 01 09:28:27 plntyk: driver should have rings big enough & support BQL, to let kernel deal with queues (and bufferbloat) Mar 01 09:29:03 plntyk: see if driver has netdev_sent_queue() and netdev_completed_queue() calls - that it what's needed for BQL Mar 01 09:29:32 with that, kernel knows exactly how many bytes and queued and handles packets wisely Mar 01 09:57:37 seems this autoconf-lean thing broke a bunch of packages Mar 01 10:03:09 Now if only everyone can move to meson/cmake Mar 01 10:06:55 rmilecki: I think that is directed at me :) The original question was should my ethX ports have ring buffers, because ethtool tells me to go away Mar 01 10:07:25 Grommish: every Eth driver has ring buffers Mar 01 10:07:38 Grommish: my guess is your driver doesn't allow configuring them dynamically Mar 01 10:07:54 Cannot get device ring settings: Not supported Mar 01 10:08:02 I Mar 01 10:08:12 right, I think most drivers have hardcoded ring sizes Mar 01 10:08:18 err I'm seeing dropped packets, and the common advice was to increase it Mar 01 10:08:22 Bah Mar 01 10:08:38 Grommish: you need modify driver and recompile it (and whole image) Mar 01 10:08:51 Oh, that isn't an issue if I can find it Mar 01 10:09:01 but boo Mar 01 10:09:10 Anyway to find out why I'm getting the dropped packets? Mar 01 10:10:10 do you see dropped packets in interface statistics on a router? Mar 01 10:11:07 https://gist.github.com/Grommish/ce297d829763c946a75b0050b8a8874a Mar 01 10:11:27 eth0 is WAN, eth1/eth2 are bridge in br-lan Mar 01 10:11:35 there isn't a Switch chip on the device Mar 01 10:11:41 at least that I could ever find Mar 01 10:12:35 I removed teh IP's from the WAN, it's connected Mar 01 10:14:11 Grommish: do I see correctly you have 0,0186779593459% dropped packets on br-lan? Mar 01 10:14:58 Probably, the issue is that it comes in batches, whcih freezes the eth1 and eth2 traffic Mar 01 10:15:23 So I get notiable hitches in things like video Mar 01 10:16:02 you should add some debugging to the ethernet driver Mar 01 10:16:14 sure, you can increase rings sizes, but I'm not sure it's going to help Mar 01 10:16:48 Grommish: maybe start observing IRQs, see if RX IRQs stop appearing at some intervals or sth Mar 01 10:16:48 Yeah, i'd like to find out why it's happening, it's being a pain Mar 01 10:16:59 and it itsn't consistent Mar 01 10:17:16 i'l add dev_info_ratelimited to the irq handler Mar 01 10:17:23 and let it run Mar 01 10:17:57 once you see a hiccup, see if IRQs stopped appearing during that timeframe Mar 01 10:23:22 Grommish: also try to trigger a stall using iperf Mar 01 10:23:34 Grommish: put a machine running "iperf -s" on the WAN port Mar 01 10:23:46 Grommish: then run "iperf -c" on LAN connected machine Mar 01 10:29:01 I get 920/240 to the ISP. Like I said, it just isn't consistent :( Mar 01 10:29:16 I will have to see about the driver though Mar 01 10:32:48 Grommish: octeon still? Mar 01 10:33:00 yeah Mar 01 10:34:03 I'm getting dropped packets and I'm not sure why, even though it's very small in ratio :p Mar 01 10:35:06 Grommish: i guess that on high traffic, when you e.g. run out low on free RX buffers, sth "Bad" happens Mar 01 10:35:28 That's my guess, which led me to the ring buffers hehe Mar 01 10:35:41 Grommish: i got such a problem on BCM908 recently: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=d313d16bbaea0f11a2e98f04a6c678b43c208915 Mar 01 10:36:48 Mines a cavium driver, so I'm not enthused about mucking about in there Mar 01 10:37:28 :P Mar 01 10:38:44 Grommish: did that Ubiquiti Octeon guy already talk to you? Mar 01 10:38:52 the one in the forum looking for a paid port Mar 01 10:39:04 Oh, no.. The ER6 guy? Mar 01 10:39:51 yeah Mar 01 10:41:18 Nah, I told him to send me one and I'd work on it, but I doubt he'll want to do that Mar 01 10:41:28 He was confused about what he even wants to do Mar 01 10:42:15 but, if he wants to mail me one, I'd work on it and return the device when done Mar 01 10:44:05 Or, if someone wants to help me with my dnsmasq issue, that would certainly speed up my deve time hehe Mar 01 10:44:20 not being able to work on the device here is a PITA Mar 01 10:56:41 morning Mar 01 10:57:06 can openwrt be built on non-x86 architecture? (target irrevelant) Mar 01 10:57:27 sure. Mar 01 10:59:41 thanks Mar 01 11:04:48 Grommish: I can send you an ER10X if you want to work on something ... (mt7621) Mar 01 11:06:06 My only experience, such as it is, is with the octeon SoC. But I'm persistent at things. in reality,there are better folks to send gear to for results. Mar 01 11:06:24 Don't get me wrong, I'd be all for it, just giving you the standard disclaimer Mar 01 11:07:40 Grommish: the ER10X is actually an EdgeRouter X but with a 5 Port Switch RTL8367RB for ports 5-9 (via rgmii) Mar 01 11:08:30 Does RealTek release the drivers? Mar 01 11:09:09 Grommish: yeah integrated in the opensource download from Ubiquiti Mar 01 11:09:47 So whats the bottleneck? What issues are you having building it? Mar 01 11:11:32 Grommish: I've started working on it about a year ago - kernel 4.14 Mar 01 11:11:53 decke: what issues are you running into? Mar 01 11:12:24 Borromini: the main issue back then was to get an initramfs image for testing which was too big at that time Mar 01 11:12:42 Do you have the image/Makefile target? Mar 01 11:13:01 I can build it in about an hour or so if you do Mar 01 11:13:03 that issue got solved some months ago - also documented in the edgerouter wiki pages Mar 01 11:13:08 decke: that sounds a bit weird, the initramfs being too big? Mar 01 11:13:27 ok so what is the main issue now? Mar 01 11:13:46 Borromini: that all the stuff that I have is out of date, old and for a different kernel Mar 01 11:14:14 you got a dts? Mar 01 11:14:16 and that it's my first device to hack on it myself Mar 01 11:14:19 ok :) Mar 01 11:14:20 yeah for 4.14 Mar 01 11:15:38 Borromini: https://github.com/decke/openwrt-er10x Mar 01 11:18:28 was that all needed to get the board to work on 4.14? Mar 01 11:18:28 decke: did you actually start building the target? Mar 01 11:19:50 I found it Mar 01 11:27:35 guidosarducci: You're bloating my builds, now I need libbpf in addition to libelf… :P Mar 01 11:29:25 … and all because of sqm-scripts and tc… I wonder if would be possible to have a "light" variant of tc… Mar 01 11:35:51 Hauke: ping Mar 01 11:41:52 heh. why openwrt does not produce logs per built component... Mar 01 11:42:08 'oops, failed. rerun with -j1 V=s and hope for best' Mar 01 11:42:28 because it runs at $(nproc) by default Mar 01 11:42:36 and that means the error won't be at the end Mar 01 11:42:47 so does several other build systems Mar 01 11:44:24 hrw: it does, you need to ask for it Mar 01 11:44:45 hrw, BUILD_LOG=y config Mar 01 11:44:46 BUILD_LOG=1 Mar 01 11:44:50 tx Mar 01 11:45:02 ok, once it fail, will add it Mar 01 11:45:04 make foo BUILD_LOG=1 works as well Mar 01 11:45:21 Grommish: yes, about 12 months ago https://github.com/decke/openwrt-er10x/actions Mar 01 11:45:50 ynezz: I can haz "mvebu/omnia: fix the device tree" for 21.02? :) Mar 01 11:47:21 Grommish: with some minimal changes (flash layout, console) it is compatible with the regular edgerouter, igoring the 5 upper LAN ports Mar 01 11:49:23 rsalvaterra: git cherry-pick -x foo; git send-email foo :p Mar 01 11:50:19 Oh… I had sent it with a note to apply to 21.02 too… :/ Mar 01 11:50:29 I can resend, though. Mar 01 11:50:31 decke: I've added the target, let's see if it builds, then we can plug in the extra stuff Mar 01 11:50:44 I copied the ERX target for now Mar 01 11:50:56 rsalvaterra: I can do it if you give me the commit hash Mar 01 11:51:14 Sure, let me see… Mar 01 11:51:35 ynezz: 6fe6b631ef91a8a44d7324329ad6aaec6f08ada6 Mar 01 11:52:05 rsalvaterra: I made a SysBench package for testing and quantifying changes :P Mar 01 11:53:03 Grommish: SysBench? Mar 01 11:53:07 It compiles, I jiust need to figure out the install Mar 01 11:53:17 yar, sytem benchmarks Mar 01 11:53:42 There has been debate about code and its detriment to my device.. I want to see if its true :) Mar 01 11:53:52 https://github.com/akopytov/sysbench Mar 01 11:54:22 Well, you can't optimise what you can't measure, that's for sure… :) Mar 01 11:55:04 Indeed.. I wonder how resource heavy it is.. Mar 01 11:55:13 I jumped to package before I ran it Mar 01 11:55:43 Grommish: that dts should be interesting: https://github.com/decke/openwrt-er10x/commit/de5f5bd383531ec5ed3cf962594c2b02b84ae814 Mar 01 11:56:14 I want to build the target, then I can add the dts and whatnot Mar 01 11:56:16 ok - package/boot/arm-trusted-firmware-mvebu fetches cross compiler instead of using existing one. so it fails on non-x86 Mar 01 11:56:56 decke: it should build since it's a direct copy of the ER-X.. then we can break it Mar 01 11:57:16 decke: but I don't have that toolchain built, so I'm going to go do that first Mar 01 12:00:58 hrw: congratulations, you've just earned corner case badge :P https://github.com/openwrt/openwrt/pull/2521#discussion_r341187914 Mar 01 12:02:04 ;D Mar 01 12:02:18 ynezz: just selected same target as I recently did on x86-64 ;D Mar 01 12:02:45 ynezz: espressobin v5 runs nice with 5.10.18 kernel. replaced my ath79 wndr4300 Mar 01 12:04:55 hrw: what do you use as your build host? Mar 01 12:05:05 clearfog? Mar 01 12:07:35 ynezz: honeycomb Mar 01 12:08:43 how long does it take to build the image? Mar 01 12:08:48 Grommish: all the dirty secrets how ubiquiti integrated the 5 port Realtek chip can be seen in the GPL download Mar 01 12:08:57 Grommish: it is all in https://gist.github.com/decke/3798ed3b3ec5edaa73b20d39e7b4c2b5 Mar 01 12:09:33 ynezz: need to choose different target ;D Mar 01 12:09:44 ah, yes Mar 01 12:10:42 hrw: anyway it would be nice to report that breakage as people still live in their Linux x86/64 only bubbles https://lists.openwrt.org/pipermail/openwrt-devel/2020-October/031694.html Mar 01 12:10:55 Grommish: please share, so i can run on the erlite too :) Mar 01 12:11:36 ynezz: ath79/wndr4300 then Mar 01 12:12:59 hrw: don't know how much space/time you've, but can you try it with https://downloads.openwrt.org/snapshots/targets/ath79/generic/config.buildinfo ? Mar 01 12:13:14 curl https://downloads.openwrt.org/snapshots/targets/ath79/generic/config.buildinfo > .config; make defconfig; make -j$(nproc) Mar 01 12:13:33 ok Mar 01 12:14:23 ynezz: it is more to check how/does openwrt work on non-x86 then for use. Mar 01 12:15:01 ynezz: espressobin works so I do not plan to build updates for it (can fetch from repos) and wndr4300 waits for being reconfigured to be just AP Mar 01 12:16:52 btw - can someone change gcc check to check for <= 4.8 rather than > 4.8? Mar 01 12:16:59 Fedora 34 uses gcc 11 Mar 01 12:17:11 it should be 6+ soon Mar 01 12:17:32 whatever. check 'is it too old' rahter than 'is it new enough' Mar 01 12:19:22 it's just bunch of regexps defined in include/prereq-build.mk Mar 01 12:19:43 which need changes on each new gcc version Mar 01 12:19:48 yes Mar 01 12:19:58 which is wrong way Mar 01 12:20:07 patches are welcome :) Mar 01 12:20:13 ;P Mar 01 12:25:18 ynezz: https://bugs.openwrt.org/index.php?do=details&task_id=3654 - feel free to tell what I wrote/marked wrong Mar 01 12:25:43 hrw: thanks Mar 01 12:26:16 Grommish: and that code uses the rtl8367c driver to integrate the 5 port switch .... which seems to work fine on kernel 5.10 \o/ https://github.com/openwrt/openwrt/tree/master/target/linux/mediatek/files-5.10/drivers/net/phy/rtk/rtl8367c Mar 01 12:27:12 ynezz: btw - https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/ Mar 01 12:27:13 decke: Ok.. I'm thru the toolchain and building the target, no issues so far, but i don't expect any at this point Mar 01 12:27:36 If it's in the 5.10 kernel, I'll see what ramips is building for Mar 01 12:27:41 hrw, regarding gcc change - upstream gcc explicitly mentions versions when bootstrapping - so a "feature detection" does not seem that viable Mar 01 12:27:44 https://gcc.gnu.org/gcc-11/changes.html Mar 01 12:27:53 Grommish: i'm just looking at the special stuff and that looks promising so far Mar 01 12:28:03 decke: 5.4 doesn't? Mar 01 12:28:28 If you can find the patch set for it, I can backport it to 5,4 for testing Mar 01 12:29:12 Borromini: don't know, ubiquiti stock fw is still using 4.14 Mar 01 12:29:44 Got all the way to the end and borked :D Lets see why Mar 01 12:29:55 Grommish: all there as it seems https://github.com/openwrt/openwrt/tree/master/target/linux/mediatek/files-5.4/drivers/net/phy/rtk/rtl8367c Mar 01 12:30:07 so 5.4 might be fine as well Mar 01 12:30:14 Ok Mar 01 12:30:23 O Mar 01 12:30:36 I'll have to see how to call that in the defines Mar 01 12:31:20 Grommish: the archer c2 v1 uses an external realtek switch as well, if that could help Mar 01 12:31:22 Grommish: and there is some code that we don't seem to have in the tree yet which is called rtl8367s Mar 01 12:31:23 plntyk: depends how much time you want to waste on every gcc update? as I did not say 'openwrt needs to change gcc version' but 'gcc version check' Mar 01 12:31:36 it bypasses the internal 100 Mbps one altogether i think. Mar 01 12:31:38 Borromini: correct, that is the same Mar 01 12:33:54 hrw: https://git.openwrt.org/4b926ac1ee8aa5cb24d6361547924529f86614da and you would need this one as well https://git.openwrt.org/7242f5c7e9cd746454394a0500bf7d5452d3b544 Mar 01 12:34:22 ynezz: did first one locally by hand Mar 01 12:34:50 when it said that my gcc/g++ are not working ok Mar 01 12:34:56 alternative to version checks are probably doing feature/toolchain checks like buildroot.net does Mar 01 12:35:02 while they compiled hello.c properly Mar 01 12:36:08 we've now some time until gcc-20 Mar 01 12:37:46 decke: On the dts file, does the 10x have all the partitions the x does? Mar 01 12:39:44 Except for the 740000 partition? Mar 01 12:40:05 the ubi partition is larger it loos like Mar 01 12:40:12 Grommish: yes, correct - that partition is just bigger because the flash is 512m Mar 01 12:40:41 ah rootfs size Mar 01 12:40:52 Grommish: i've digged it out of their GPL code Mar 01 12:41:06 Gotcha Mar 01 12:41:47 from wrt54gs with 8MB flash and 32MB ram I went (with some other routers on a way) to wndr4300 with 128/128. Now Espressobin has 1GB of ram and 16GB rootfs (as it was smallest microsd card I have) Mar 01 12:41:51 rsalvaterra: done Mar 01 12:42:52 Grommish: for reference you can download the GPL code easily https://www.ui.com/download/edgemax/edgerouter-10x/er-10x Mar 01 12:43:51 Grommish: https://www.ui.com/download/edgemax/edgerouter-10x/er-10x/edgerouter-er-xer-x-sfpep-r6er-10x-firmware-v209 and then "Download GPL Archive" Mar 01 12:44:09 which leads to: https://dl.ui.com/firmwares/edgemax/v2.0.9/gpl/GPL.ER-e50.v2.0.9.5346345.tar.bz2 Mar 01 12:49:53 decke: So.. Mar 01 12:49:55 -rw-r--r-- 1 grommish grommish 4237026 Mar 1 07:49 openwrt-ramips-mt7621-ubnt_edgerouter-10x-initramfs-kernel.bin Mar 01 12:49:55 -rw-r--r-- 1 grommish grommish 4322441 Mar 1 07:49 openwrt-ramips-mt7621-ubnt_edgerouter-10x-squashfs-sysupgrade.bin Mar 01 12:50:04 With the dts for the er10x Mar 01 12:50:11 I dunno if it works, but.. eh Mar 01 12:51:03 Grommish: did you also take the other changes from my er10x dts? Mar 01 12:51:34 I took your file https://raw.githubusercontent.com/openwrt/openwrt/de5f5bd383531ec5ed3cf962594c2b02b84ae814/target/linux/ramips/dts/mt7621_ubiquiti_edgerouter-10x.dts and put it into the build system, yes Mar 01 12:51:48 Grommish: awesome Mar 01 12:51:59 on 5.4 Mar 01 12:52:39 Grommish: so that is about the same state when I left it Mar 01 12:53:09 Except its 5.4 instead of 4.19 yes Mar 01 12:53:11 because it actually did only build the squashfs file and not the initramfs - but I was not brave enough to just flash and break it Mar 01 12:53:32 You shouldn't Mar 01 12:53:34 Hold on Mar 01 12:53:56 the good thing is the uboot can handle initramfs from TFTP to RAM Mar 01 12:54:01 Does the ER10x have the vfat partition that it loads the kernel from? Mar 01 12:54:37 Grommish: http://sector5d.org/openwrt-on-the-ubiquiti-edgerouter-x.html a bit down to uboot ... Mar 01 12:54:47 Grommish: "1: Load system code to SDRAM via TFTP." Mar 01 12:55:09 Grommish: that is what we want right? Mar 01 12:55:51 openwrt-ramips-mt7621-ubnt_edgerouter-10x-initramfs-kernel.bin is the initramfs file Mar 01 12:56:12 That is what you flash, yes Mar 01 12:56:14 but Mar 01 12:56:28 Unless you now how to revive from a brick with that device, I wouldn't Mar 01 12:56:59 I have no idea if this is going to work or not and i don't want to lose the 7 minutes of sleep feeling bad about it Mar 01 12:57:10 Grommish: the device has a proper console port on the front Mar 01 12:57:11 Grommish: initramfs wouldn't kill it would it? Mar 01 12:57:26 Good do you have a rj45 rollover: Mar 01 12:57:27 a lot of ubiquitis have a nice rj45 to serial port Mar 01 12:57:56 Grommish: i have a cable for it yes and tested it with the stock firmware Mar 01 12:57:57 I've got the RJ45 and I'm making breakout headers to attach it to serial pins Mar 01 12:58:56 take one of these (https://www.monoprice.com/product?p_id=7280&gclid=Cj0KCQiAvvKBBhCXARIsACTePW-b2Q9AskAZnquTSQT7ArfYV1NGwqov691Hw0wzcVbIhQ6_iEOZbw8aApH6EALw_wcB) split it in half and solder extensions do it :) Mar 01 12:59:26 You get two adapters per single unit Mar 01 13:00:17 Grommish: loading the initramfs should be safe even if it doesn't work properly right? Mar 01 13:00:18 Borromini: I hesitate to flash any device that isn't mine. THe recovery for mine (and the ER4) is ludiciously easy I forget others don't have it as good Mar 01 13:00:53 decke: As long as you can return it to stock in case the worse happens, yes it's safe.. uboot would still be there Mar 01 13:01:08 and that image is just the ER-X rebadged with your dts file included Mar 01 13:01:40 Grommish: yeah I assume it would boot and don't detect the upper 5 ports Mar 01 13:01:57 Well, if the switch driver was introduced in 5.4 Mar 01 13:02:08 If it isn't automatic, we can add the kmod call if needed Mar 01 13:02:27 Hello all!! Mar 01 13:02:33 Grommish: but as I said in the beginning, I'd be happy to send you an ER10X straight away Mar 01 13:02:44 but given you've already found the .c driver file in the upstream Mar 01 13:03:00 Grommish: yeah but initrams is meant to be loaded from the bootloader 9 times out of 10 no Mar 01 13:03:18 Borromini: right, it won't effect uboot regardless Mar 01 13:03:48 Unless it flashes over the uboot partition, but the only change in the partitions was the ubi size Mar 01 13:03:55 So that shouldn't be an issue either Mar 01 13:04:09 decke: I'm always down for the challenge, as I told the guy with the er6 Mar 01 13:04:49 decke: But you've got the knowledge to flash, it shouldn't be any different than testing the ER-X Mar 01 13:05:07 Hello all! As you may guess from my ML message I was looking around in the AVM QCA routers. Was wondering what difficulties where being met in booting directly from EVA, and so hat led to the creation of the second-stage u-boot bootloader. Mar 01 13:05:13 If you brick it, then you can mail it to me Mar 01 13:05:29 Since you would be without it anyway Mar 01 13:06:12 mrkiki: I'm not familar with that device :( Sorry! Mar 01 13:06:17 Grommish: for longer term - especially getting the upper 5 ports working it would probably be wise if you have one around Mar 01 13:06:34 Grommish: "longer term" as in in two days Mar 01 13:06:47 decke: Eh, maybe, but you should test to see if they work first ;p Mar 01 13:07:00 I mean, I don't mind hardware.. I'd just setup a new segment Mar 01 13:07:04 Grommish: thanks! oh well, this was a generalquestion Mar 01 13:08:01 mrkiko: You might want to try the Forum (https://forum.openwrt.org/c/hardware-questions-and-recommendations/13) Mar 01 13:08:13 That's the HW Question section Mar 01 13:09:23 Grommish: thanks a lot. Well, you're right. I'm using IRC most of the times since it's more confortable for me to use but I acknowledge it might help to get to the Forum, r maybe posing this same question in ML. Mar 01 13:10:22 blocktrron: I guess you tried without u-boot as well ? Mar 01 13:11:19 mrkiko: what is your goal? Mar 01 13:12:13 blocktrron: oh, currently no specific goal, wanted to learn a little bit how things worked; the device works really great Mar 01 13:12:31 yes you can boot them without the U-Boot by appending the DTB to the kernel and enabling legacy booting Mar 01 13:13:39 For the NAND models two problems arise: The KErnel is limited to 4M, you have to deal with the dualboot mechanism and the kernel is not stored in UBI, therefor you don't have any wear leveling for the flash at hand Mar 01 13:14:25 blocktrron: so using u-boot made things more elegant and clean. Thanks. Mar 01 13:14:41 Having the second-stage U-Boot allows us not to deal with AVMs ecosystem Mar 01 13:16:03 The non-IPQ devices (lantiq as well as QCA) don't use a second-stage loader. Mar 01 13:16:40 blocktrron: Very nice! Thanks. BTW, now VLANs works fine as well. Mar 01 13:17:12 good to hear :) Mar 01 13:20:26 how can I refresh kernel patches of every kernel? Mar 01 13:20:32 *every target Mar 01 13:24:36 I'm so ready for bed. Night/Afternoon all :) It's 0830 here.. Oy.. Blasted sunlight Mar 01 13:25:42 rmilecki: probably the easiest way is to use update_kernel.sh from maintainer-tools repo Mar 01 13:32:07 ynezz: thanks! Mar 01 13:32:17 ynezz: built. Mar 01 13:32:17 real 71m58,602s Mar 01 13:32:17 user 570m8,730s Mar 01 13:32:17 sys 78m54,594s Mar 01 13:33:13 hrw: ah, nice, thanks Mar 01 13:33:46 ynezz: note that some sources were already fetched, probably similar for some host tools Mar 01 13:34:20 still would expect faster time Mar 01 13:35:06 aha Mar 01 13:35:55