**** BEGIN LOGGING AT Sat Feb 13 03:02:54 2021 Feb 13 05:01:50 mangix: Hey.. What's up? Feb 13 05:02:51 Borromini: Most uboot I've seen also support YModem, which is faster, if that might be an option Feb 13 05:30:07 mangix: hit me up when you see it.. I'm heading to bed and will catch it in the morning :) Feb 13 06:53:20 nbd: Would you mind a question or three about minstrel_ht? Feb 13 06:55:41 I notice something of a 'lock-on' effect in the rate control on a standard ath9k chip -- `watch -n2 -d cat rc_stats` while iperf3'ing with the ath9k as tx-mostly, I can see how once I lock on to MCS15 I keep it easily, but when I lose it and drop back to one of the one-chain MCS indexes it takes a while to get back onto the 2x2 ones. Feb 13 06:56:38 is this expected from minstrel_ht, or is there some hardware quirk expected with MIMO here? Feb 13 06:57:34 The one thing I notice most shockingly is that when MIMO stops it really stops -- rc_stats shows an increase of a few dozen attempts but *none* are successful Feb 13 06:57:51 I also suspect my client chipset too (intel 8265). Feb 13 07:01:22 whereas when MIMO starts again it really starts -- goes from 5% to about 85% avg(prob) in two or three seconds. Feb 13 07:02:09 Finally, what are the meanings of ABCDPS under 'best rate' in /sys/kernel/debug/ieee80211/phy*/netdev:wlan*/stations/$STATION/rc_stats? Feb 13 07:27:12 Grommish: I'd like a test on https://github.com/openwrt/packages/pull/14728 . I don't have the hardware. Feb 13 07:56:08 hurricos: ABCD are the 4 best throughput rates (in order), P is a reliable rate with decent throughput, S is a rate that will be tested next Feb 13 07:57:11 regarding your MIMO issues, i suspect that this has nothing to do with rate control, but might be SMPS (powersave mode that turns off extra receive/transmit chains to conserve power) on the intel side Feb 13 07:57:22 if i remember correctly, many intel clients make aggressive use of that Feb 13 08:02:19 hurricos: i think some changes might be needed to either minstrel_ht or mac80211 for smps to work properly Feb 13 08:02:22 i will look into it Feb 13 08:43:38 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.) Feb 13 09:00:49 hurricos: here's a completely untested ath9k patch that might take care of your issue: http://nbd.name/560-ath9k-tx-smps.patch Feb 13 09:01:22 please let me know if it works for you Feb 13 09:01:26 if it does, i'll send it upstream Feb 13 10:12:28 mangix: Sure, I can test it. I'm not sure what it is, but I can run a build on it Feb 13 10:18:18 mangix: just target all the boost libraries to see what happens? Feb 13 11:01:19 mangix: cp: cannot stat '/home/grommish/openwrt/build_dir/target-mips64_octeonplus_64_musl/boost_1_75_0/ipkg-install/lib/libboost_fiber*.so*': No such file or directory <- There is only a libboost_fiber.a MIPS64 is a dynamically linked arch Feb 13 11:04:48 In any case, its looking for the .so in your Package/install and erroring because it can't find it Feb 13 11:28:02 Grommish: locally the PR compiles Feb 13 11:28:16 I was talking mostly about run testing :) Feb 13 11:30:07 Yeah, I'm going to unselect boost fiber and check.. Did you test all libraries in it? Feb 13 11:30:34 and I'm game to test whatever you need.. Like I said, I don't know that I've use those libs for anything, so any suggestions? Feb 13 11:30:43 The PR only concerns boost-context Feb 13 11:31:00 actually, hmmm. that's interesting Feb 13 11:31:44 I should find a way to setup a isolated box you can use to test a box. I've got a serial connection for them Feb 13 11:31:57 and I've got 2 shields sitting here Feb 13 11:32:23 but it seems like an awful lot fo work and i'm pretty lazy honestly hehe Feb 13 11:32:38 well, I think QEMU also works Feb 13 11:32:46 erm malta target Feb 13 11:32:57 isn't that just mips though? Feb 13 11:33:09 it's 4 things Feb 13 11:33:12 Ah Feb 13 11:33:14 MIPS32/63 BE/LE Feb 13 11:33:18 *64 Feb 13 11:33:29 Gotcha.. Mine is a 64BER Feb 13 11:33:31 err BE Feb 13 11:33:58 I'm rebuilding without the fiber to see what happens Feb 13 11:35:14 I find it interesting that boost on mips64 has been broken since forever Feb 13 11:35:20 O64 is the wrong ABI Feb 13 11:35:42 which musl has no support for Feb 13 11:36:00 libunwind is broken for mips64 too.. it isn't in the deps for it, but works Feb 13 11:36:14 Hmm? Feb 13 11:36:45 I use libunwind for suricata6, but I had to add a mips64 dep check on it Feb 13 11:37:06 locally anyway Feb 13 11:40:03 That was as an aside "things mips64 is "broken with" comment, not related to boost Feb 13 11:40:22 the libunwind depends line is pretty funny Feb 13 11:40:48 Yeah.. I put in a PR but got pissy over the comments I got (my fault) and never bothered to redo it Feb 13 11:41:42 I'm probably to blame for the DEPENDS not being DEPENDS:=!arc Feb 13 11:42:21 removing boost_fiber seems to let it go and build.. Now.. what can I use to test these in a way that is meaningful for ya? Feb 13 11:43:28 pdns Feb 13 11:43:30 erm Feb 13 11:43:32 pdns-recursor Feb 13 11:43:57 Ok.. I'll run a build with that too :) Will that conflict with default packages? Feb 13 11:44:13 just running it with a --version parameter is good enough for me Feb 13 11:44:18 i don't think so Feb 13 11:44:32 Ok.. Gimme a few :) Feb 13 11:44:57 I'll look into the fiber issue Feb 13 11:45:13 ICU is taking forever to compile... Feb 13 11:46:43 just pdns-recursor? Feb 13 11:47:47 yeah. only pdns-recursor uses boost-context Feb 13 11:48:02 there was another series of packages but I nuked them Feb 13 11:48:33 Ok Feb 13 12:02:14 I just realized I'm not using ccache... Feb 13 12:02:21 no wonder compilation is slow Feb 13 12:10:12 mangix: you're good.. https://gist.github.com/Grommish/4bad9a1dfc7594652a58bc7fa84d3133 Feb 13 12:12:44 Error: opcode not supported on this processor: mips64 (mips64) `pause' Feb 13 12:12:45 I don't use ccache, it seems to cause more problems than not for me Feb 13 12:13:01 I've fixed all of them :) Feb 13 12:13:27 good for me Feb 13 12:13:42 Nice.. I'll have to give it a go again then Feb 13 12:14:02 Anything else you need tested? Feb 13 12:15:33 no that's all. I'll fix up boost fiber and update the PR Feb 13 12:16:07 Alright. I'll keep an eye out and update to test Feb 13 12:18:00 hmmm.... Feb 13 12:21:22 asm volatile ("pause" ::: "memory"); Feb 13 12:21:30 why does this fail under mips64? Feb 13 12:21:47 Check to make sure that opcode is in octeon+ Feb 13 12:22:06 Remember, Openwrt lumps everything under octeon+ Feb 13 12:23:32 Borromini: how does the 'testing kernel' case work -- ever an installable package? alternate "build" images installable exchangably? Feb 13 12:24:12 enyc: Testing kernel is the alternate version in the target Makefile Feb 13 12:24:32 enyc: turning it on simply builds out the alt major version listed Feb 13 12:24:50 ie: 4.19 might be the KERNEL_VERSION but 5.4 would be the Testing version Feb 13 12:25:09 Grommish: so manual build of separate image for the target... and that affects the set of kmod- packages .......... Feb 13 12:25:33 Anytime you change the kernel or toolchain, it all has to be wiped and rebuilt, yeah Feb 13 12:25:53 So if you buikd with the Testing version, it'll rebuild all the kmods Feb 13 12:25:56 Grommish: where do i find a lost of opcodes? Feb 13 12:25:58 it woud have to Feb 13 12:26:16 Grommish: hrrm I'm used to x86 linux distros and having quite a wide range of kernels possible to work ........ Feb 13 12:26:51 mangix: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MIPS_Architecture_MIPS64_InstructionSet_%20AFP_P_MD00087_06.05.pdf Feb 13 12:27:21 enyc: Keep in mind OpenWrt is considered embedded though Feb 13 12:27:45 Grommish: right yes =) so not designed for kernel to be interchanged at all, other than "upgrade whole image" Feb 13 12:27:50 enyc: So i'm not sure you can just swap kernels like in a PC distro Feb 13 12:29:10 I had a mess of a time with Suricata6 and Rust because of MIPS64 issues with things like statically vs dynamically linked libs Feb 13 12:29:58 It would compile fine and when I went to run it, it would dump.. I had a hell of a time trying to debug it Feb 13 12:30:12 turns out a copy opcode was being used that it didb't support Feb 13 12:31:04 Its how I learned about the remote-dgb script hehe Feb 13 12:31:12 PAUSE opcode is listed there Feb 13 12:31:21 guess octeon is broken in more than one way Feb 13 12:31:54 What is throwig the error? Feb 13 12:33:39 https://github.com/boostorg/fiber/blob/develop/include/boost/fiber/detail/cpu_relax.hpp#L50 Feb 13 12:34:13 what's strange is that the octeon compiler returns 1 for __mips_isa_rev Feb 13 12:34:22 and it's still evaluating to true Feb 13 12:35:03 enyc: new image, can't just replace the kernel Feb 13 12:35:18 ok Grommish already answered you :) Feb 13 12:35:49 Borromini: from what you were saying... 21.02 to be all kernel 5.4 and thus, testing-kernels are only about helping master in preparation for 22.x Feb 13 12:36:48 Does the build system separate MIPS64 vs MIPS with that flag? Feb 13 12:36:57 or does it assume MIPS64 is just "MIPS" Feb 13 12:37:35 enyc: they are a stepping stone to the next kernel to be used in master, yes Feb 13 12:37:38 BOOST_ARCH_MIPS evaluates to 32 or 64 Feb 13 12:37:48 not that is should matter, PAUSE was introduyced into MIPS32 in 2008 Feb 13 12:37:49 or 0 Feb 13 12:38:01 erm, undefined i mean Feb 13 12:38:19 Borromini: when is the bost useful time to test 21.02 in prep for release, are there specific rc? images or just daily builds, etc? Feb 13 12:39:41 enyc: once it get branched you'll get prepped pre-21.02 images Feb 13 12:39:48 did you see the e-mail on openwrt-devel? Feb 13 12:40:04 Borromini: *goes looking* Feb 13 12:40:22 i see this elsewhere in boost code: #if !defined(__mips_isa_rev) || (__mips_isa_rev < 6) Feb 13 12:40:31 wonder if I should just do that Feb 13 12:40:34 Wait.. Feb 13 12:40:52 PAUSE wasn't introduced until revision 2.60 Feb 13 12:41:37 Revision 2.60: June 25, 2008: added PAUSE instruction Feb 13 12:42:08 Pg370 https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00086-2B-MIPS32BIS-AFP-05.04.pdf Feb 13 12:42:48 Would that make a difference? Feb 13 12:44:03 enyc: https://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033718.html Feb 13 12:44:29 Borromini: found thread =) Feb 13 12:44:29 Grommish: run ./staging_dir/toolchain-mips64_octeonplus_64_gcc-8.4.0_musl/bin/mips64-openwrt-linux-gcc -dM -E - < /dev/null | sort -u | grep -i mips Feb 13 12:45:01 note __mips_isa_rev Feb 13 12:45:37 https://gist.github.com/Grommish/ab104afdfb8fe1dbb14e6804e7561515 Feb 13 12:46:07 I use 10.2 FYI Feb 13 12:47:44 oh no Feb 13 12:47:47 i figured it out Feb 13 12:47:47 Bugger. The pca953x GPIO driver from Linux 5.11-rc7 still has the same problem on the Omnia. Feb 13 12:50:15 mips64 supports mips16 Feb 13 12:50:33 so PKG_USE_MIPS16:=0 turns __mips_isa_rev to 2 Feb 13 12:50:56 Borromini: right so it looks like testing the new builds in all their different wifi configs, client mode and other less-usual setups -- r.e. mac80211 change is going to be especially helpful Feb 13 12:51:07 now i need a good way to ifdef it out :) Feb 13 12:51:28 mangix: build system defaults to MIPS16 unless told not to? Feb 13 12:51:34 enyc: yes, especially wireless drivers Feb 13 12:51:56 if you have spare devices it never hurts to run master on some of them Feb 13 12:52:15 especially smaller flash devices tend to break when running into kernel size limits and whatnot Feb 13 12:52:24 Grommish: yes. adjustable under advanced toolchain settings Feb 13 12:52:38 of course better also have serial at hand if things break Feb 13 12:53:31 Guys, anyone running master on an Omnia? Or anything with an Armada 38x? Feb 13 12:54:15 rsalvaterra: Helios 4, AMA Feb 13 12:54:33 mangix: do you see spurious GPIO interrupts? Feb 13 12:54:54 And I mean tons of them, about 50/s. Feb 13 12:54:56 Grommish: lol HAS_MIPS16 depends on depends on (mips || mipsel || mips64 || mips64el) but is not hit under octeon Feb 13 12:55:05 mangix: Do you know your devices triples offhand? xxxx-openwrt-linux-musl? Feb 13 12:55:27 50: 0 0 f1018100.gpio 23 Edge 0-0020 Feb 13 12:55:28 51: 0 0 f1018100.gpio 20 Edge f10d8000.sdhci cd Feb 13 12:55:28 52: 3 0 f1018100.gpio 18 Edge Wake-On-LAN Feb 13 12:55:46 rsalvaterra: that what you mean? Feb 13 12:55:54 52: 26711 0 f1018140.gpio 14 Level 8-0071 Feb 13 12:56:01 And counting. Feb 13 12:56:01 I know it's an aside, but since you'd probably know offhand, I can use it for my rust testing Feb 13 12:56:17 i do not actually Feb 13 12:56:31 i shouldn't be awake right now :P Feb 13 12:56:42 haha me either.. I feel your pain Feb 13 12:56:46 After a while, the kernel just gives up and shuts the handler up, with a stack trace. Feb 13 12:57:02 Borromini: I noticed my BT-HomeHub-v5-Type-A just wouldn't client-mode on ath10k in 19.07 but it DOES work with master and all the updated ath10k-firmware etc etc that includes... I'll definitely test all of these with 20.x ..... Feb 13 12:57:11 err 21.02 ;p Feb 13 12:57:13 And this is happening on the normal snapshot builds, on the Omnia. It's not my config. Feb 13 12:57:50 I'm tempted to just disable the pca953x interrupt controller feature. It "fixes" the problem for me. Feb 13 12:59:08 what kernel? Feb 13 12:59:11 Lunch time. bbl. Feb 13 12:59:28 i'm running 5.9 Feb 13 12:59:32 mangix: 5.4.97, on master. Feb 13 12:59:54 maybe upstream broke it Feb 13 13:00:10 5.4.97 with the pca953x GPIO driver from 5.11-rc7 has the same problem. Feb 13 13:00:27 I backported it yesterday for testing. Feb 13 13:00:36 I updated the kernel on my helios 4 but haven't rebooted. Looks like no kernel 5.10 for me :) Feb 13 13:01:03 [ 1.230581] Kernel unaligned instruction access[#1]: Feb 13 13:01:17 on an mt7621-based dir860l Feb 13 13:01:40 exit Feb 13 13:01:41 was fine about a week ago Feb 13 13:03:26 also, tools/fakeroot build is failing for me Feb 13 13:04:08 libfakeroot.c: In function 'chown': Feb 13 13:04:08 libfakeroot.c:99:40: error: '_STAT_VER' undeclared (first use in this function) 99 | #define INT_NEXT_STAT(a,b) NEXT_STAT64(_STAT_VER,a,b) Feb 13 13:12:52 https://bugs.archlinux.org/task/69572 (patches at the bottom seem to fix my problem) Feb 13 13:14:03 [ 1.178045] mt7621-pci 1e140000.pcie: Parsing DT failed ... that doesn't look good. Feb 13 13:42:11 * enyc wonders about the DSA situation for 21.02, not much mention of that lately. Feb 13 13:44:36 I thought the DSA issues were the reason it's been pushed back for as long as it has been Feb 13 13:46:20 did a make dirclean on the dir860l, still hangs the Parsing DT failed doesn't seem to be related, it showed up in the successful firmware built last week too. Feb 13 13:46:43 Grommish: https://openwrt.org/docs/guide-developer/releases/goals/21.02 links to old thread on the topic... I see jow asking similar on the linked LuCI github pull thread Feb 13 13:49:34 unfortunately, I don't have a Switch in my device, so I can't test anything Feb 13 14:26:36 r15727-c382fe857d works Feb 13 14:26:51 * russell-- suspects the last kernel bump Feb 13 14:52:43 r15731-dba76a85de works Feb 13 14:53:43 yep, next commit dies Feb 13 14:54:57 r15732-e95b1b23f1 kills the dir860l Feb 13 15:12:37 russell--: what are we talking about? Feb 13 15:12:46 * Borromini has a dir-860l as well Feb 13 15:14:15 russell--: oh the kernel bump? Feb 13 15:14:47 i have an eap235-wall (mt7621 as well) working just fine on 5.4.97 Feb 13 15:18:26 russell--: can you get your hands on a boot log? Feb 13 15:31:31 russell--: the pice: parsing dt failed pops up on most mt7621 devices. i think the stacktrace will be more useful Feb 13 15:31:52 i see that every time on otherwise perfectly functional mt7621 hardware Feb 13 16:27:34 Borromini: Did you everget to check if your uboot supports Ymodem? Feb 13 16:29:43 Grommish: no, how so? Feb 13 16:29:56 you mean for the archer c2? Feb 13 16:31:32 i just found out yesterday about kermit. Feb 13 16:32:26 kermit rules them all (lantiq bootrom also speaks kermit, if i'm not mistaking. used ckermit a lot with that back in the days) Feb 13 16:33:13 uboot supports kermit, but most also support Ymodem Feb 13 16:33:19 which is faster and has CRC checking Feb 13 16:33:35 In case it happens again, might be worth checking into Feb 13 16:33:54 sure, uboot gives you choice, depending on what is compiled in. the burn-in romloader in charge of loading uboot from flash to the cpu cache usually doesn't give you choice there... Feb 13 16:33:59 I dealt with the pain of tryig to up a 90Mb image via Kermit haha Feb 13 16:34:05 Grommish: thanks, will keep that in mind :) Feb 13 16:34:15 luckily it was 7 MB only here :P Feb 13 16:34:30 Of course, I'm old enough that my first modem was a 1200 Baud Feb 13 16:34:45 So I remember when Xmodem was it and Zmodem was just coming out Feb 13 16:35:01 and I hate kermit with a paaaasion Feb 13 16:35:11 * dangole grew up in Zmodem days with 36kbit/s Feb 13 16:35:17 dangole: hi! you merged my MT7613 patch into iwinfo but i noticed only afterwards that i might have messed up the order. the PCI ID is 7663 but the device is MT7613 (it's related to the MT7663 though). so i don't know if that needs reordering. Feb 13 16:35:45 Yep.. I had a USR 16.6 that you had to replace the chip with a paperclip to et 19.2 Feb 13 16:35:51 i think we had 56k. but at that point computers were only for the occasional game if my dad let me :P Feb 13 16:36:06 Borromini: if i recall correctly the ordering there wasn't all straight to beging with. would be nice to clean it and make it consistent Feb 13 16:36:08 Looked like a hard-back book :D Feb 13 16:37:32 * dangole was 2:2480/300.38 on FIDOnet, ie. USENET and Mail over UUCP... Feb 13 16:37:56 dangole: oh that makes my finger mistake less bad then :P Feb 13 16:38:36 I remember Fidonet.. and gopher.. and Youngstown Ohio shudder Feb 13 16:39:31 the days of starboards is behind us, thankfully Feb 13 16:40:18 dangole: You got any luck with making uboot compile? Feb 13 16:40:24 * dangole mostly remembers wos.* (World-of-Sound), sdc.* (Sound Distributor Channel), ... FIDO file groups, ordered by netlabel groups people published Amiga MOD, FastTracker2 XM, ImpulseTracker IT, ScreamTracker S3M, ... and me was full on into that when me was 14 ;) Feb 13 16:41:00 Grommish: I got U-Boot 2020.10 and ATF 2.2 built from source running on MT7622 on front of me :) Feb 13 16:41:34 I just donated an old A600 to a retro gmaing channel who restored it after 20+ years sitting.. I've got the A3000 around here somwhere and an original 1084S monitor in front of me :) Feb 13 16:41:45 dangole: is there a trick to compiling it for the CN70xx Feb 13 16:41:54 I can't get it to build and my uboot is 2013 Feb 13 16:42:14 Grommish: probably you need to use an old toolchain matching the epoch of that U-Boot... Feb 13 16:42:31 I can't get even Marvell's Uboot repo to build ;x Feb 13 16:42:41 I'm probably just not doing it right Feb 13 16:42:52 Grommish: that's odd, we got uboot-mvebu building in our tree and it seems to work fine Feb 13 16:43:09 Grommish: package/boot/uboot-mvebu Feb 13 16:43:27 I don't have a mvebu board though Feb 13 16:43:41 uboot-kirkwood then...? Feb 13 16:43:48 cavium octeon3 Feb 13 16:44:06 Because Marvell is difficult in the best of times Feb 13 16:44:21 I'llhave to dig back into it and see what I"m screwing up Feb 13 16:44:36 oh, i imagine... try using the toolchain which comes with it in a OS container sufficiently old... Feb 13 16:45:16 * Borromini broke a tl-wr1043nd v1 that way Feb 13 16:45:21 old uboot, new toolchain :P Feb 13 16:46:40 https://github.com/MarvellEmbeddedProcessors/u-boot-marvell is what they have, but I can't get it to build Feb 13 16:49:40 But then again, they're last kernel is 4.14, so.. Feb 13 17:25:24 Groomish: Feb 13 17:25:42 RE: Cavium U-Boot: You can and should try using Cavium's SDK. Feb 13 17:26:04 It's not public, but for some reason they haven't DMCA'd any copies off Github. Feb 13 17:26:20 https://github.com/hurricos/OCTEON-im8724-SDK Feb 13 17:27:00 Cavium NEVER mainlined their stuff. Or well, they re-hired Aaron Williamson to take another run at it, most recent commits to U-boot mainline were like December 2020. Feb 13 17:27:12 grommish: Feb 13 17:28:40 it doesn't help that Cavium Octeon processors, especially the higher-end ones, are ridiculously overengineered. Feb 13 17:28:52 I think most CN68XX boards are like, 32 cores, 8GB RAM. Feb 13 17:29:07 and CN78XX boards have like 128 cores or something insane like that Feb 13 17:30:11 whatever passes for "embedded" these days. It's like Xeon Phi before Xeon Phi was well-known Feb 13 17:31:53 guys a question: if my board's serial header is 3,3V i shouldn't connect to it right? Feb 13 17:31:56 or am i wrong? Feb 13 17:32:59 so far i've done rx/tx/gnd and that works just fine in general Feb 13 17:34:52 yeah unless you have a voltage translator or something that'd use the reference, it doesnt matter (or a converter to old RS-232 that needs the power...) Feb 13 17:35:14 ok, thanks Feb 13 17:35:31 Borromini: depends on what you're attaching to that UART. In certain (relatively rare) cases UART adapters can adjust their output voltage to a reference (or just be powered externally) and then you need that board's Vcc as a reference. But most USB UART devices have fixed output voltage so you just need to ensure it matches but do not actually connect Vcc. Feb 13 17:35:41 (or well, could even cause issues if you power half of an USB-serial thing from the device accidentally, or try to power the device with an USB-serial dongle ...) Feb 13 17:36:42 Those "self-powered" dongles are often problematic, they keep powering the target through Tx (target's Rx) pin while the target is turned off. So it would be much better in general if USB UART devices were actually using that Vcc pin for the reference. Feb 13 17:36:51 ok, thanks guys Feb 13 17:37:55 In "more professional" settings such as JTAG adapters most often than not connecting target's Vcc is mandatory. Feb 13 17:38:04 yeah i often tack in resistors both ways on the data lines (to limit the cross-powering) if i expect there to be partially powered situations Feb 13 17:40:02 Yep Feb 13 17:40:20 Good workaround, but it's not always handy. Feb 13 17:53:54 Hauke: ping Feb 13 17:57:05 * mwalle doesn't understand the linux/target/. is that loosely based on per SoC? Feb 13 17:57:50 yes? Feb 13 18:02:23 but will that also assume it has the same boot method, for example? Feb 13 18:04:23 mwalle: no, bootloader isn't something openwrt handles? Feb 13 18:07:59 Borromini: its more than just the bootloader, e.g. where does the bootloader get the image from. raw nand? partition? what about device trees, and so on. Can this be different for each target inside a linux/target/ Feb 13 18:09:19 for example, why isn't there an linux/target/armv8 ? there are rockchip boards octeontx boards, and so on, which are all armv8 Feb 13 18:10:01 i think by now all targets are dts Feb 13 18:10:07 * dts based Feb 13 18:11:49 it looks like one major difference are the kernel patches per "SoC/architecture" Feb 13 18:12:17 but what if you'd need no kernel patches at all because everything is upstream Feb 13 18:12:53 then you'd have a clean target Feb 13 18:14:31 right but that target could be a rockchip board or a layercape board. thus why are there different subdirectories for rockchip and layerscape Feb 13 18:16:18 if i look at the Makefiles there is a thing called "FEATURES" which is different across the various architectures, but there seem to be both SoC specifc stuff as well as board specific stuff Feb 13 18:27:20 nbd: pong Feb 13 18:31:29 Hauke: if you want to push the mac80211 update, you can simply remove 300-mac80211-optimize-skb-resizing.patch Feb 13 18:31:44 i don't have time to rework it at the moment and it's not very important Feb 13 18:32:16 nbd: ok Feb 13 18:32:26 are you going to update it to the latest 5.10 stable version as well? Feb 13 18:32:49 I plan to prepare that in the next days Feb 13 18:32:53 ok, great Feb 13 18:33:03 I will first update openwrt to 5.10-rc6 Feb 13 18:33:24 ok Feb 13 19:08:10 nbd: the adapted patch is in the 19.07 branch, see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0a59e2a76e6d58d95b8a0bdeca86090ceb794a59 Feb 13 19:08:24 this more or less reverts the upstream change which conflicts with this Feb 13 19:08:30 should we better remove it there too? Feb 13 20:01:06 Hauke: yes Feb 13 20:05:01 lipnitsk: hi, just wanted to let you know that i've pushed some updates to the flow offload code in my 5.10 patches Feb 13 20:05:15 with a bit of luck there should be no more structural changes coming to the core api Feb 13 20:05:31 hey - I saw - thanks Feb 13 20:05:50 I'll see if I can cobble together PPPoE offload. Feb 13 20:06:29 can someone merge the javascript rewrite of the luci-app-babeld (I'm maintainer)? I would like to go on with further functionality https://github.com/openwrt/luci/pull/4791 Feb 13 20:08:50 nbd: question - why does offload seem to stop at DSA when checking the path? I'm imagining a packet flowing from eth0 (WAN) via LAN bridge to eth1. Reading the code, when walking the net_device_path_stack it seems to break out of the loop if it finds the DSA device - don't we want to continue routing until reaching eth1? Feb 13 20:09:51 both xt_FLOWOFFLOAD (hw?) and nft_flow_offload (sw?) seem similar in that regard Feb 13 20:11:26 so the simple route is eth0->dsa->bridge->eth1 Feb 13 20:11:43 ping aparcar Why do u need those apply acl lua code stuff? Feb 13 20:13:08 what I want to implement is adding a VLAN at eth0 as well as PPPoE, so the route will be something like eth0->eth0.VLAN->pppoe->dsa->bridge->eth1 Feb 13 20:27:48 Borromini: i don't get a stack trace every time, and the messages i do see are different every time Feb 13 20:34:48 it looks to me (from the messages that appear in working boots vs nonworking) like something to do with enumerating the CPUs, possibly some null pointer dereference in an interrupt handler, but just a guess. Feb 13 20:54:19 I would like to discuss the benefits of a stable release branch. I could write a script parsing the github site to find the latest stable release, but when something changes i have to change it. A stable branch would make this unaccessary. In the moment we have tags and releases equal each other. What you people think about that. am i wrong here Feb 13 20:54:26 for such a question? Feb 13 20:55:24 nick: context? Feb 13 20:55:44 aparcar: javascript rewrite of sysupgrade luci app Feb 13 20:55:54 I can link to code Feb 13 20:55:54 1s Feb 13 20:57:10 aparcar: https://github.com/openwrt/luci/blob/master/applications/luci-app-attendedsysupgrade/luasrc/view/attendedsysupgrade.htm#L5-L73 Feb 13 20:57:14 why do u need this? Feb 13 20:57:38 I first used that also in my javascript app, and Jonny removed it Feb 13 20:58:12 the acl seems to work even without doing that lua code Feb 13 20:58:17 It's old code, before the time where it was possible to write everything in javascript Feb 13 20:58:17 https://github.com/openwrt/luci/pull/4145 Feb 13 20:58:20 this is the new code Feb 13 21:02:09 Ah I see thanks! seems like I have to rewrite again ^^ Feb 13 21:03:28 sorry for that Feb 13 21:03:31 what are you working on? Feb 13 21:04:07 yeah, but just need to rewrite the ubus calls and stuff like this. Feb 13 21:04:16 Could u merge for now this: https://github.com/openwrt/luci/pull/4791 ? Feb 13 21:05:33 its definitely better than the lua code I wrote Feb 13 21:07:30 there are multiple comments that aren't marked as resolved Feb 13 21:07:42 build #781 of archs38/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/781 blamelist: Adrian Schmutzler , Stijn Segers , Daniel Golle , Martin Kennedy , Feb 13 21:07:42 Rapha?l M?lotte Feb 13 21:07:45 also the table generation doesn't seem to be particularity pretty, isn't there a better way? Feb 13 21:10:07 this table implementation seems more elegant https://github.com/openwrt/luci/blob/master/modules/luci-mod-status/htdocs/luci-static/resources/view/status/include/10_system.js#L68 Feb 13 21:10:21 eliasmagn: is this not a stable release branch? https://github.com/openwrt/openwrt/tree/openwrt-19.07 Feb 13 21:11:01 lipnitsk: dsa has a handler for the tc flow block setup Feb 13 21:11:11 in the slave device Feb 13 21:11:31 that handler forwards the call to eth0/eth1 Feb 13 21:11:42 okay, so two hash entries instead of one? Feb 13 21:11:53 @apa Feb 13 21:12:11 basically we offload up to dsa and then again dsa and beyond? Feb 13 21:12:11 lipnitsk: same number of flow entries as before Feb 13 21:12:24 no, the full thing gets offloaded Feb 13 21:12:29 just the way it's called is a bit different Feb 13 21:12:39 i preferred the old approach, but pablo really wants it this way Feb 13 21:12:58 well whatever makes it upstream I guess Feb 13 21:14:00 aparcar: I was not able to mark them as resolved. I deleted them now. Yes. this implementation looks more elegant. Feb 13 21:14:16 thanks for pointing me to this Feb 13 21:14:18 I was just confused, because I thought we had to walk the full path from eth0 to eth1 when computing the destination address, but the logic seems to stop short at dsa Feb 13 21:15:28 nick: I'm fine merging that and it's improved in some future, your choice Feb 13 21:32:13 aparcar Nice. Yeah, I just wrote Jonny that he should put also the uci-default into it that enables ubus on babeld. Afterwards, I ping u again. :) Feb 13 21:32:43 nick: ack Feb 13 22:23:23 russell-- you are right i am blind; thank you! Feb 13 22:30:19 eliasmagn: np Feb 14 00:26:57 hurricos: Mine is a CN7020AAp1.2, so it's only a dual-core, its just been impossible to get much out of Cavium, even before the Marvell takeover. I'll check out your link.. Thanks! Feb 14 00:57:38 Grommish: Let me know if you need any help compiling. What is the board btw? Feb 14 00:57:47 I am forgetting now X^) Feb 14 00:58:28 With Cavium it's 100% about the board and not just the CPU. Feb 14 00:58:57 Itus Shield ... Feb 14 01:03:22 Yeah Feb 14 01:03:25 Grommish: See if you can dump your dts Feb 14 01:03:34 There isn't one Feb 14 01:03:39 I don't use a dts/dtb for building Feb 14 01:04:15 I was going to work on one based ont he dtsi that was made for the ER4 Feb 14 01:04:34 and work with damex ((?)) on it Feb 14 01:05:28 There were blobs in the uboot image, but I never coukd get anything out of it Feb 14 01:05:48 I can link ya the Stage1/Stage2 files if you want Feb 14 01:05:56 Yeah, that would be the .dtb. See if you can push to paste.c-net.org Feb 14 01:06:16 I can grep through the SDK. It definitely does look like it's entirely the customer board Feb 14 01:06:24 It is Feb 14 01:06:42 you have a u-boot console/ Feb 14 01:06:53 Of course.. stage 1 and stage 2 Feb 14 01:07:01 gotcha. Can you tmate me into it? :^) Feb 14 01:07:06 Before it decides which slot to boot in stage3 Feb 14 01:07:14 Actually, Maybe.. Feb 14 01:07:29 I'd have to setup the second device and then grab the rollover Feb 14 01:07:45 that one is still running Chaos Calmer though from the OEM Feb 14 01:07:53 but for the uboot stuff shouldn't matter Feb 14 01:08:19 Also, yeah, why the u-boot replacement, it's because the stage2 has some boot variables hardcoded or sth.? Feb 14 01:08:36 THe uboot on device is 2013 Feb 14 01:08:41 No real reason other than that Feb 14 01:08:47 My uboot images are actual images Feb 14 01:08:54 loaded into the vfat partition Feb 14 01:09:17 right ... fwiw, Cavium U-boot has not been merged back in Feb 14 01:09:26 2013 *is* today's U-boot. Feb 14 01:09:54 Aaron Williamson is the person resonsible for getting everything mainlined. He's working on now Feb 14 01:10:15 but most of the patchs he's bringing forward and cleaning up are from 2013. Feb 14 01:10:32 oct2boot.bin https://drive.google.com/file/d/1P6wGBPJw3X3Em8WUkSd1wAjzDPh5YVMG/view?usp=sharing Feb 14 01:11:01 u-boot-octeon_rhino_itus7x.bin https://drive.google.com/file/d/1gyT3Tf7v2-BRfOSL0Yvqtn_8XlGpNEE5/view?usp=sharing Feb 14 01:11:45 rhino? Feb 14 01:11:50 RhinoLabs? Feb 14 01:12:33 Itus went out of Business immedately after delivering the Kickstarter. There were like 500 or less officially made Feb 14 01:12:39 So I've got no idea Feb 14 01:12:54 yes, rhino labs was the odm Feb 14 01:14:06 Cool. Yeah. So ... replacing U-boot is a non-starter just b/c there's nothing to replace it with Feb 14 01:14:25 as it's a customer board and being handled by ODMs who never release their sources DESPITE their obligations under the GPL Feb 14 01:14:53 Ah, gotcha.. That simplifies things immenselyh Feb 14 01:20:44 So, even with the SDK and the correct SoC defines, I still can't do anything about it? Feb 14 01:20:56 Not that I've got a need at this point.. It does everything I need it to Feb 14 01:21:09 Yep, since you have no commit history to build a patchset to rebase Feb 14 01:21:29 No way to binwalk the info out of the images? Feb 14 01:21:35 I've go no knowledge of uboot Feb 14 01:22:04