**** BEGIN LOGGING AT Tue Feb 23 03:00:05 2021 Feb 23 03:27:08 * enyc ponders what https://github.com/greearb/ath10k-ct/issues/178 means for OpenWRT 21.02 .... switch away from -ct firmware? try to get it figured out further? Feb 23 03:53:29 using the same hardware on my archer c5 and I don't see the same thing Feb 23 03:59:11 wonder if it's environment or specific to certain devices Feb 23 04:12:58 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.) Feb 23 04:13:47 build #273 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv8_64b/builds/273 Feb 23 04:25:58 build #864 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/864 Feb 23 04:27:43 philipp64: nope. parallel compilation for autotools is an afterthought. just like make Feb 23 04:28:03 it's possible but not by default Feb 23 04:30:17 meson is parallel by default. I don't think you can turn it off. Feb 23 05:22:36 build #798 of layerscape/armv8_64b is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/798 blamelist: ?lvaro Fern?ndez Rojas Feb 23 05:46:45 Namidairo: hrrm... ok can you put that on the above ticket? Should there be an openwrt tracking bug to look into before release or otherwise? Feb 23 05:47:53 Namidairo: in one case, 3* SSIDs on 5ghz (ath10k) and also 2* SSIDs on 2.4ghz (ath9k) .... but nothing too onerous! Feb 23 05:48:06 Namidairo: will try to see if older logs/versions make apparent where it maybe used to work.... Feb 23 05:49:33 Namidairo: thinking about it i have identical router with similar slightly-older config and older master build, I can swap that in and fix its' update config..., get info on ath10k versions etc. Feb 23 06:32:45 mangix: ping Feb 23 06:47:58 aparcar[m]: in addition to the OWRT build automation, do we support any type of automated run-time testing? e.g. kernel self-tests or home-brewed Feb 23 06:48:25 aparcar[m]: pong Feb 23 06:52:13 mangix: I'm thinking how to detect best modified packages Feb 23 06:52:23 currently it only detects changes in Makefiles/test.sh Feb 23 06:52:40 but since we now have AUTORELEASE modifications to makefile are not always required. Feb 23 06:53:02 it's not always package// Feb 23 06:53:44 but sometimes package/// Feb 23 06:54:53 guidosarducci: not so far, we could run some qemu images I guess via an CI Feb 23 06:55:56 aparcar[m]: that's what I was thinking too. we have malta, armvirt and x86, that together cover *a lot* or archs, word sizes, and endianness space Feb 23 06:56:32 guidosarducci: well do you have experience with those setups? maybe we can setup something Feb 23 06:57:55 aparcar: there is also the case where pkg name != folder name Feb 23 06:58:16 guidosarducci: not really, I've set up my own ad-hoc tests for packages I care about, but using upstream tests would be better Feb 23 06:58:24 lipnitsk: treason! which package? Feb 23 06:58:43 one example is protobuf-c (pkg name is libprotobuf-c) Feb 23 06:59:09 aparcar[m]: I worry that (as usual) much of the testing infra doesn't play well with cross-compilation/embedded stuff. Would need to look at it carefully. Feb 23 06:59:49 guidosarducci: it kinda works well at this point, qemu is kinda mounted and then the arch specific packages are run Feb 23 07:00:11 what runtime tests are you thinking of? Feb 23 07:00:57 aparcar[m]: I meant the upstream's testing infra. Things like kernel self-tests on the networking side, BPF, etc. Feb 23 07:01:32 lipnitsk: ugh awkward. what do you suggest Feb 23 07:01:59 aparcar[m]: even a basic runner based on QEMU would be a good start. There are some simple tests like "modprobe test_bpf" that already exist (and I've packaged the module) Feb 23 07:02:04 aparcar: one way could be to grep for "PKG_NAME.*:=" while walking directories up, until you hit one match Feb 23 07:03:27 aparcar[m]: I just don't understand enough of what exists for OWRT testing to gauge what's possible... Feb 23 07:03:39 guidosarducci: kernel stuff seems difficult with the current setup as it's within a docker setup. but we can run the full redis upstream tests for example Feb 23 07:04:13 anything not kernel related should work Feb 23 07:04:38 aparcar[m]: redis? For kernel stuff could we not simple parse for output as usual? Feb 23 07:04:40 aparcar: actually wait, you want the directory name, not PKG_NAME, since that's what make uses Feb 23 07:05:20 some clever way to find where the Makefile is then get the dirname where it's in? Feb 23 07:06:15 or find all Makefiles, then take off the Makefile part and match that path to what git said changed? Feb 23 07:07:44 lipnitsk: you want to do the thinking? Feb 23 07:07:54 dunno. It's getting late here Feb 23 07:08:00 Let me try. Feb 23 07:12:37 lipnitsk: I can also come up with something Feb 23 07:12:45 give me a few min Feb 23 07:13:39 guidosarducci: do you have actual machines for testing? Feb 23 07:15:29 aparcar[m]: I do my local stuff on an ubuntu box and another VM box. Is that what you mean? Feb 23 07:39:16 guidosarducci: I'll think of something Feb 23 07:39:25 lipnitsk: ping me if you figured something out, thanks for the nightshift Feb 23 07:42:59 aparcar[m]: Thanks. BTW, some simple, concrete targets I was thinking of was: 1. self-contained test script, 2. iproute2 "make check", and 3. "modprobe test_bpf". Appreciate if you have some good pointers to how our current testing is set up. Feb 23 07:51:49 aparcar: https://pastebin.com/8sFjtbAr Feb 23 07:51:58 aparcar: inefficient, but works, I think ;) Feb 23 07:52:34 assumes you are in root of repo. if not, some argument to find is needed Feb 23 07:55:36 I'm sure it could be done faster with awk or something, so feel free to improve. Feb 23 08:10:12 blocktrron: ping Feb 23 08:13:57 guidosarducci: all right I'll think about something Feb 23 08:17:15 aparcar[m]: cheers! Feb 23 08:21:30 aparcar: I can make it into a PR tomorrow and test with CI Feb 23 08:22:11 lipnitsk: oh great please do Feb 23 08:53:28 build #732 of lantiq/xway is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/732 Feb 23 08:59:59 build #739 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/739 Feb 23 09:45:30 Btw channel topic is outdated as 19.07.7 was released Feb 23 09:47:04 aparcar[m]: and there are no Docker images for sdk and rootfs for that version Feb 23 09:55:16 build kicked https://gitlab.com/openwrt/docker/-/pipelines/260335026 Feb 23 09:57:04 both missing steps are documented https://openwrt.org/docs/guide-developer/releases/release-process but we still fail to execute them :) Feb 23 09:57:21 maybe we need to convert it to some kind of task list with [x] ticks or such Feb 23 09:58:45 this is a moment where I miss some usable issue system, where we could create ticket with all the tasks so the state tracking would be much easier Feb 23 10:07:23 Heh… I had to use lipnitsk's big hammer, but at least I now have WireGuard on 5.10, on my Omnia. :) Feb 23 10:08:12 build #735 of bcm53xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/735 Feb 23 10:11:03 zx2c4: How do I know which of the algorithms (scalar or NEON) are being used in WireGuard? I see them in /proc/crypto, but with refcnt at 1 (as WireGuard uses the libraries directly, not the crypto API, right?)… Feb 23 10:29:57 rsalvaterra, https://www.wireguard.com/quickstart/#debug-info maybe ? Feb 23 10:30:23 dunno what "useful output" means Feb 23 10:30:56 Hmm… I'd like to avoid building with debug support… :P Feb 23 10:35:29 rsalvaterra: I don't understand the changes to files-* in the mvebu patchset Feb 23 10:35:40 Which files have actually been upstreamed? Feb 23 10:35:53 build #768 of omap/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/768 Feb 23 10:35:57 Just a few espressobins as it appears? Feb 23 10:37:01 adrianschmutzler: Yeah, git made a bit of a mess, it's not obvious from the diffstat. Feb 23 10:37:43 So, files/ is common to all kernel versions, files-5.4/ is specific to the 5.4 kernel version, correct? Feb 23 10:38:00 so, espressobin-emmc, -v7 and -v7-emmc are upstreamed? Feb 23 10:38:16 Yes, those are upstreamed. Feb 23 10:38:26 rsalvaterra: yes, files/ is common, so your copying of files/ to files-5.10/ does not make much sense ;-) Feb 23 10:38:42 But I will probably just fix that myself Feb 23 10:39:05 It does when you don't want to make big mistakes (and I did :P). Feb 23 10:39:59 So, I first made sure I had files-5.4/ and files-5.10/. Only then I started factoring things into files/. Feb 23 10:40:35 As files-5.10/ ended up empty, I removed it. Feb 23 10:42:52 then it's probably just not distributed well over the patches Feb 23 10:43:09 anyway, as we see files might need special treatment Feb 23 10:43:29 You're the fan of small steps at a time… ;) Feb 23 10:43:36 (And I am too.) Feb 23 10:45:43 btw, how did you do kernel_oldconfig now? (which commands/sequence?) Feb 23 10:46:22 1) make kernel_oldconfig Feb 23 10:46:22 2) make kernel_oldconfig CONFIG_TARGET=subtarget (for each subtarget) Feb 23 10:47:27 I'm assuming the hierarchy is generic -> target -> subtarget. Feb 23 10:48:27 yes, I'm just never sure what exactly kernel_oldconfig does when subtargets are around Feb 23 10:49:09 Yeah, it updates the main target. It's what we want. :) Feb 23 10:49:46 adrianschmutzler: thanks for porting that backport patch from 5.4 to 5.10 Feb 23 10:50:04 adrianschmutzler: unfortunately nbd_ missed more patches, so one should compare both trees Feb 23 10:50:37 adrianschmutzler: 402-v5.12-0001-dt-bindings-mtd-move-partition-binding-to-its-own-fi.patch and 402-v5.12-0002-dt-bindings-mtd-add-binding-for-BCM4908-partitions.patch are mssing too Feb 23 10:50:44 i didn't check what else possibl Feb 23 10:51:31 rmilecki: mom Feb 23 10:52:40 hmm, strange Feb 23 10:54:03 yes, I understand what happened now: the two-level numbering tricked me Feb 23 10:54:29 you add four 402-v5.12-000x Feb 23 10:54:35 and then removed two of them again Feb 23 10:54:48 but I assumed all of them were removed again Feb 23 10:55:08 so I didn't add them during my check a week ago Feb 23 10:55:55 but I only looked at history up to (including) december 2020 Feb 23 10:56:19 maybe it's worth trying diff -u backport-5.4 backport-5.10 Feb 23 10:56:28 so, if something very old slipped, I wouldn't have it Feb 23 10:56:30 not sure how easy to understand outptut will be Feb 23 10:56:48 well, diffing means you have to check for every removed patch manually Feb 23 10:56:55 right Feb 23 10:57:17 may be a lot of work for 5.4 -> 5.10 Feb 23 10:57:24 I tried that first, but then gave it up as it would require a substantial amount of time Feb 23 10:57:46 ok Feb 23 10:57:48 i understand Feb 23 10:57:52 essentially you would have to do the kernel bump _again_ Feb 23 10:58:32 so, I thought checking the history would be a good compromise, assuming the general job done during migration is fine Feb 23 10:59:12 btw I also checked patches and hack dirs Feb 23 11:00:06 so, the main risk would be that nbd_ removed a patch during the process he wanted to work on later, and forgot to do that Feb 23 11:11:07 rsalvaterra: any reason why only one of the 6 functional patches in v5.11 was taken for turris omnia? Feb 23 11:11:16 kab-el: I just noticed, is there any reason we're not exposing the atsha204a at i2c@5, on the Omnia device tree? Feb 23 11:13:31 adrianschmutzler: I told tmn505 I wanted to first get the exact same functionality we had with 5.4, so those patches will be added in the future (when I add support for the LEDs, for example). Feb 23 11:13:49 build #799 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/799 Feb 23 11:14:53 okay. I probably will leave out the turris omnia patches for now, though, anyway Feb 23 11:14:59 adrianschmutzler: In other words, we're at 5.10 plus bug fixes only, minus LEDs. Feb 23 11:15:16 Uhh… no, we need those. Feb 23 11:15:33 reads like enabling a feature? Feb 23 11:15:35 They fix the hardware buffer management and the IRQ storm. Feb 23 11:16:13 Wait, are we on the same page? Which patches? Feb 23 11:17:59 mvebu: fix the Turris Omnia device tree Feb 23 11:18:30 There, it says "enable and fix". This means that without the patch, it's disabled and thus won't hurt :-) Feb 23 11:18:34 These are the patches I'm talking about: 002-ARM-dts-turris-omnia-enable-HW-buffer-management.patch, 100-ARM-dts-turris-omnia-fix-hardware-buffer-management.patch, 101-ARM-dts-turris-omnia-configure-LED-2--INTn-pin-as-interrupt-pin.patch. Feb 23 11:19:51 002 and 101 enable/fix hbm, it's been working for a long time already on Linksys hardware with the same SoC. Feb 23 11:20:51 (I already sent a patch to enable/fix hbm on 21.02 too.) Feb 23 11:21:11 101 fixes the GPIO IRQ storm. Feb 23 11:21:47 I mainly just don't want to have to review these. Feb 23 11:21:53 adrianschmutzler: It hurts network performance, especially at small packet sizes. :P Feb 23 11:21:59 rsalvaterra, o/ Feb 23 11:22:16 Hey, nitroshift! o/ Feb 23 11:22:27 but it will still boot and not explode without them? Feb 23 11:22:36 what hardware buffer manager on mvebu are you talking about? Feb 23 11:22:58 so far there is only software buffer manager Feb 23 11:23:06 adrianschmutzler: If that makes you more comfortable, those patches were approved upstream. Feb 23 11:23:35 well, give me two links and I might be fine :-) Feb 23 11:25:07 nitroshift: I'll get to you, let me just "unstress" adrianschmutzler. :) Feb 23 11:25:17 :)) ok Feb 23 11:25:52 doesn't look like they made it in the 5.12 set Feb 23 11:26:13 Ok, for the IRQ storm fix, reviewed by Andrew Lunn: https://marc.info/?l=linux-arm-kernel&m=161394081106303&w=4 Feb 23 11:28:38 For the hbm, reviewed by Marek Behún: https://marc.info/?l=linux-arm-kernel&m=161357782411611&w=4 Feb 23 11:28:54 okay, and "just" reviewed means we do not know when and whether they will land in kernel Feb 23 11:29:25 but that should be good enough for us at the moment Feb 23 11:29:28 Let's make a bet…? ;) Feb 23 11:29:47 It's all fine Feb 23 11:30:28 It's not a matter of "if", just a matter of "when" (for the IRQ storm patch) and "how" (for the hbm fix, as it's being discussed the possibility of including in the generic SoC .dtsi). Feb 23 11:31:24 but stuff like the "how" would normally be something you would wait for Feb 23 11:31:46 nitroshift: About hbm, you're talking about the WRT1900AC v1, right? Feb 23 11:31:54 anyway, see my nitpickedly fixed version here, while I build-test: https://github.com/adschm/openwrt/commits/mvebu10y Feb 23 11:37:11 nitroshift: Check for something like this on your dmesg: [ 1.536185] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled Feb 23 11:37:54 hmm, that CONFIG_POWER_RESET_LINKSTATION is set up strangely Feb 23 11:38:40 Oh…? I wasn't prompted for that. Feb 23 11:38:52 not your fault, just generally Feb 23 11:38:58 rsalvaterra, got confused, you're right Feb 23 11:39:30 it's =m in modules, but disabled in the subtargets, and not set in the target ... Feb 23 11:39:41 adrianschmutzler: ack for your nitpicks, thanks. :) Feb 23 11:44:24 I have a question which has been bugging me for a while… Let's say I have a system for which the Wi-Fi driver is basically in maintenance mode. Is there any easy way to build an image without the compat stuff? Feb 23 11:48:38 build-testing will require https://github.com/openwrt/openwrt/pull/3896 ? Feb 23 11:49:13 For mvebu? Not at all, I don't have that in my tree. Feb 23 11:49:25 Well, wait. You have WireGuard? Feb 23 11:49:37 In that case, you need a patch, yes. Feb 23 11:49:47 I will just do a test with buildbot settings Feb 23 11:50:02 which would want to build at least kmod-wireguard ... Feb 23 11:51:21 I shamelessly stole this one: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commit;h=39fe90daccb410ab0bbc82227bc3f875c97fe4f0 Feb 23 11:51:54 This won't build the module, but WireGuard will work if you select it (built-in) in the kernel configuration. Feb 23 11:55:07 In either case, the build won't fail. Feb 23 11:56:44 * rsalvaterra eagerly waits for the big-ass WireGuard pull to land… Feb 23 11:58:18 I'm still curious how this will end Feb 23 11:59:37 What do you mean? :) Feb 23 12:00:05 The migration from compat to patches in 5.4? Feb 23 12:00:31 yes Feb 23 12:04:43 I'm *really* looking forward to it. Feb 23 12:05:10 It's so much cleaner… Feb 23 12:14:19 build #10 of layerscape/armv7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/layerscape%2Farmv7/builds/10 Feb 23 12:22:53 adrianschmutzler: i'd like to partially merge https://github.com/openwrt/openwrt/pull/3583 today - with some fixups Feb 23 12:23:04 adrianschmutzler: i think / hope your comments were addressed Feb 23 12:24:29 rmilecki: yes. Feb 23 12:24:40 adrianschmutzler: thank you for looking at that MR Feb 23 12:26:21 I just wonder whether stuff like ucidef_set_led_default is really needed. But probably patching a default-on into DTS is not worth it ... Feb 23 12:28:01 btw, since this LED is selected in diag.sh: Feb 23 12:28:08 will it stay on or off after boot? Feb 23 12:28:24 done) status_led_on ... Feb 23 12:28:40 hmm, looks like the ucidef_set_led_default "logo" "Power" "bcm53xx:white:power" "1" can be just removed Feb 23 12:29:31 but if you don't want to touch the code again, I'm also fine with the current state Feb 23 12:32:28 adrianschmutzler: bcm53xx uses 99% of upsteam DTS code and we don't have some code that is commonly used in OpenWrt, like those aliases Feb 23 12:32:36 i'm not well aware how it looks like Feb 23 12:32:46 I'll have to clean it up somehow Feb 23 12:33:21 that bcm53xx:white:power should be default-on in DTS, weird Feb 23 12:33:36 or should be set by some .sh code Feb 23 12:33:39 i'll check that Feb 23 12:34:22 as I understand it, it's picked up by the code in base-files/etc/diag.sh Feb 23 12:34:33 it should be, i believe Feb 23 12:34:35 so, default-on will only be relevant during first 3 seconds Feb 23 12:34:39 right Feb 23 12:35:04 then diag.sh will blink and after boot is finished, it should make the LED solid-on Feb 23 12:35:48 those ucidef_set_led_default lines are typically put by people so they can only change a value, but don't have to add the full uci block themselves (if they don't use luci) Feb 23 12:36:27 personally, I think that's not really necessary, and particularly not for a LED which is used in diag.sh Feb 23 12:37:25 for the general subject, one could of course just add local patches that insert led-* aliases into the DTS files and then use generic diag.sh Feb 23 12:37:37 but I don't really think that's worth the effort Feb 23 12:38:32 particularly since we still do not know how to use this feature with the new color/function properties, where we cannot determine the LED name from DT anymore Feb 23 12:38:52 which is a big pain in the ... Feb 23 12:39:01 build #10 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/bcm63xx%2Fgeneric/builds/10 Feb 23 13:14:11 I guess now I can start working on the Omnia LEDs… mangix will be happy. :) Feb 23 13:14:24 * rsalvaterra runs Feb 23 13:28:15 adrianschmutzler: any advice on how to move forward with that WireGuard PR? It seems pretty quiet now on the mailing list and in the PR comments. Is it a matter of following up? If so then with who? Feb 23 13:29:21 build #10 of ipq40xx/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ipq40xx%2Fmikrotik/builds/10 Feb 23 13:29:28 well, my advice on that was not valued very highly Feb 23 13:35:44 IIRC correctly, David said he prefers keeping the compat version, and I said you should discuss this on the list ASAP Feb 23 13:36:40 no other committer was seen on the scene yet, and you (plural) decided to do otherwise Feb 23 13:38:02 This does not imply any judgement, just summarizing my perception here ... Feb 23 13:41:25 adrianschmutzler lipnitsk: i don't prefer keeping the compat version Feb 23 13:42:07 I don't like keeping that pile of patches on top of 5.4, but since they simply do poof once 5.4 gets nuked im fine with that Feb 23 13:42:48 I'd rarther have 800 good wireguard backport-patches than one hack patch to say "ARMv8" in procfs Feb 23 13:43:38 lipnitsk: I'll take care of the wireguard part. Either I'll find time today / tomorrow or on the weekenc Feb 23 13:45:26 FWIW, I'd also choose patches over compat any day… Feb 23 13:46:01 Probably because I finally got the hang of quilt. :P Feb 23 13:47:11 I'm not a wireguard user ;) Feb 23 13:48:08 blocktrron: Really? Wow… I can't live without it anymore. Saved my life when I've been to Brazil. Feb 23 13:48:22 (Because homebanking apps on the phone. :P) Feb 23 13:50:07 Never had these issues when traveling in the EU Feb 23 13:50:56 But i can understand people being happy they don't have to put off with OVPN Feb 23 13:51:00 * Borromini is happy wireguard is integrated into his lineageos image Feb 23 13:51:48 You were lucky… Homebanking systems tend to complain loudly when you suddenly log-in from across the ocean… ;) Feb 23 13:52:52 hehe Feb 23 13:53:00 Borromini: I want! ;_; Unfortunately my x2 isn't built with the kernel module (Linux 3.18, unfortunately)… Feb 23 13:54:43 blocktrron: great! Thanks. zx2c4 will be happy to see this too. Feb 23 13:55:55 Ive never used quilt! Feb 23 13:56:17 Been doing kernel dev without it for a long time and somehow never made the leap Feb 23 13:56:26 My loss probably Feb 23 13:56:36 blocktrron: hit that green merge button! :P Feb 23 13:56:39 zx2c4: Quilt is… interesting. :P Feb 23 13:57:27 rsalvaterra: do you roll your own? i'm lucky enough to have the rom devs integrate it Feb 23 13:58:11 Borromini: I thought about it, by only have enough RAM to build LineageOS if I pool all my machines. :P Feb 23 13:58:23 :P :P Feb 23 13:58:30 yeah newer android releases are beasts Feb 23 13:58:38 i remember running into issues with 16 GB of RAM... Feb 23 14:00:16 Is there a way to specify a subtarget in a module DEPENDS? Something like @TARGET_mvebu_cortexa9? Feb 23 14:01:21 Or do we have @SUBTARGET? Feb 23 14:01:49 rsalvaterra: like you said Feb 23 14:01:55 @TARGET_ramips_mt7621 Feb 23 14:02:27 Borromini: <3 Feb 23 14:02:37 ♥️ Feb 23 14:02:44 @TARGET_mvebu_cortexa9 it is. :) Feb 23 14:02:52 * Borromini found an irssi emoji plugin Feb 23 14:03:04 (Makes no sense having Turris Omnia LEDs anywhere else…) Feb 23 14:03:58 :) Feb 23 14:05:16 rsalvaterra: i had this e.g. until we discovered that driver only likes =y and not =m : https://paste.debian.net/plain/1186614 Feb 23 14:07:02 I haven't built the drivers yet… I guess we'll find out soon. Feb 23 14:07:24 this one is 'special', upstream knows it won't work as =m Feb 23 15:40:09 build #9 of x86/geode is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/x86%2Fgeode/builds/9 blamelist: ?lvaro Fern?ndez Rojas Feb 23 15:50:36 rsalvaterra Hi a bit OT sorry, but do you know if there is a build of it for the GS10 yet? Feb 23 15:51:08 Tapper: I have no idea. Feb 23 15:51:15 OK thanks Feb 23 15:51:35 I would like a proper build not some dodgey one from XDA. Feb 23 15:53:06 What graphic did x d a show up as? Feb 23 16:17:43 noltari: I'm curious, is bmips to bcm63xx what ath79 is to ar7xxx? Feb 23 16:18:05 rsalvaterra: yeah, exactly that Feb 23 16:18:33 Great, thanks! :) Feb 23 16:18:49 gs10 router? Feb 23 16:18:58 Tapper: ^^ Feb 23 16:22:14 rsalvaterra: some people will probably hate me for having the same devices supported by two different targets once again :_ Feb 23 16:22:53 well... I did welcome ath79 when it came out... and still do Feb 23 16:23:01 noltari: but bcm63xx will be phased out i presume just like ar71xx? Feb 23 16:23:04 * Borromini does as well Feb 23 16:23:10 if bmips is similar thing, ef the naysayers Feb 23 16:23:31 Borromini: that's the idea Feb 23 16:23:38 noltari: Oh, come on, really? o_O Feb 23 16:23:50 but we need to have working PCI/PCIe and wireless drivers first Feb 23 16:23:57 noltari: cool. Feb 23 16:24:16 oh do wireless drivers differ as well? so it's not just a move to a dts target Feb 23 16:24:20 owrt could jsut drop the "old" thing suddenly so no double thing exist, but tell me again how THAT's going to pan out ;D Feb 23 16:24:28 I'm focusing on upstreaming the few patches that we have right now Feb 23 16:24:57 is it more of driver thing or "just" configuration thing? Feb 23 16:25:01 noltari: One thing bugs me, though… what's missing to start upstreaming all of ath79, device trees, drivers and whatnot? Feb 23 16:25:31 rsalvaterra: what do you mean? Feb 23 16:25:44 olmari: both? Feb 23 16:26:22 I dunno, it was question =) Feb 23 16:26:27 noltari: I mean, getting ath79 in the kernel proper. Feb 23 16:27:04 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 97.8% packages reproducible in our current test framework.) Feb 23 16:27:12 rsalvaterra: I don't know much about ath79. I'm just talking about bmips... Feb 23 16:28:09 noltari: Sorry, I deduced you were involved in ath79, as you said you were afraid people would hate you for doing the same again. :) Feb 23 16:28:39 rsalvaterra: ah, no, sorry! Feb 23 16:29:49 It's just that we're carrying so many patches, drivers, device trees… Feb 23 16:35:39 noltari: from what i gathered ath79 was mostly about moving ar71xx to devicetree. Feb 23 16:35:53 anyone here using the image generator? Feb 23 16:36:39 i'd like to know if it contains tplink-safeloader as well (i suppose so) Feb 23 16:37:50 The question is whether upstream wants a mixed bag of mach and dts Feb 23 16:42:49 adrianschmutzler: No mach-* for upstream. Linus made himself very clear, years ago. Feb 23 16:43:29 Everything must be described with device trees. Feb 23 16:47:04 Borromini Hi know mate I was on about a phone. Samsung GS10 Feb 23 16:47:17 oh Feb 23 16:51:40 adrianschmutzler: It started here: https://lwn.net/Articles/392135/ Feb 23 17:01:33 Is ath79 still mach-y? Feb 23 17:01:45 adrianschmutzler: And up to this point: https://lkml.org/lkml/2011/3/30/379 Feb 23 17:01:47 I thought all of the stuff got dropped there. Feb 23 17:02:27 No, ath79 is device tree based, like God intended. :P Feb 23 17:03:32 Other than that, how big would a PR for ath79 actually *be* though? Feb 23 17:03:45 or sorry. Github terminology bastardization. A patchset? Feb 23 17:03:55 ... wait Feb 23 17:04:24 Never mind. I see. This is about bmips Feb 23 17:04:47 I was beginnig to sweat. "ath79 ... not mainline? What about code rot???" Feb 23 17:04:54 lol Feb 23 17:05:11 hurricos: It would probably be big, but nothing unmanageable, I think. Feb 23 17:05:46 rsalvaterra: So it's not mainline, but also not far. At this point I just have to ask, what even *is* MIPS Feb 23 17:05:53 What is RAM. What are computers. Sigh Feb 23 17:07:11 I like how neat device trees are but they totally conceal a lot of quirks from the bootloader Feb 23 17:07:21 MIPS is actually well maintained upstream, even for really exotic stuff (N64 support was just added, for example). Feb 23 17:07:24 like, it's not what's actually on the board Feb 23 17:07:57 or not just that, but also the variations shimmed in by U-boot. SATA on APM82181 only works if properly initialized by U-boot it seems Feb 23 17:08:09 (as an example) Feb 23 17:14:38 I should stop counting my blessings and be thankful as much works as it does Feb 23 17:23:01 adrianschmutzler: I totally missed the fact that the Omnia's .dts LED node was added in disabled state. No LEDs for 5.10, I guess mangix is safe, for now… :P Feb 23 17:24:51 rsalvaterra: I already wondered, but was not sure whether I missed something Feb 23 17:25:20 mvebu builds fine, so let's throw it in Feb 23 17:26:05 \o/ Feb 23 17:28:23 rsalvaterra: that last lkml link of yours, hm, that's not what happened eventually, right? The "crazy tables" just migrated to dts, but still maintained along with the kernel, as an inherent part. Feb 23 17:32:19 Yes, of course. The point is .dts became the standard way to describe ("platformless") hardware. Feb 23 18:21:59 dedeckeh: Can you please review the one-line patch to firewall3 I mailed out last Friday? http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033907.html Feb 23 18:32:08 FYI, for those using mips/malta for development, kernel 5.10 support comes with PR https://github.com/openwrt/openwrt/pull/3881. Hopefully that gets reviewed/merged. Feb 23 19:38:27 blocktrron: thanks for merging kmod changes - I have rebased https://github.com/openwrt/openwrt/pull/3885 on top of latest master Feb 23 19:45:59 adrianschmutzler: The ESPRESSObin is Cortex-A53… ;) Feb 23 19:46:14 So it's run-tested too. :) Feb 23 19:48:33 looks like I copied that from v3 series ... Feb 23 19:50:18 No worries, it works, that's what matters. :) Feb 23 20:52:12 rsalvaterra: I'd guess the biggest hurdle for getting the rest of ath79 mainlined would be ag71xx, mainline has a stripped down version of it which won't work on most ath79 devices - that's slowly getting expanded, but it's a hell of a maze to get all the necessary bits and pieces refactored and done properly - beyond that big hurdle, it's probably mostly 'just' a huge amount of devices to take care Feb 23 20:52:18 of Feb 23 21:12:45 lipnitsk: pushed https://github.com/openwrt/openwrt/pull/3885/commits/4bcb20cad0687ffcbeaa8f4010d16ac6080ac23c on for good measure Feb 23 21:31:38 zx2c4: thanks, looks like we didn't conflict there with our force pushes :) Feb 23 21:31:44 haha Feb 23 21:31:53 --force-with-lease is a friend Feb 23 21:32:47 ooh that's nice - haven't used that before Feb 23 21:33:03 fails if you haven't fetched latest stuff? Feb 23 22:04:16 pkgadd: I thought ag71xx wasn't even in the mainline, so that's not bad news. Feb 23 22:06:58 rsalvaterra: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/atheros/ag71xx.c Feb 23 22:07:33 Yes, I was looking at it already. ;) Feb 23 22:13:09 pkgadd: That's good to know, with any luck whatever makes it into mainline won't require any extreme tweaks to dts' pll_data or anything whacky like that Feb 23 22:36:15 rsalvaterra: why is the upstream commit difefernt from the one you want to add to OpenWrt? https://git.kernel.org/linus/018b88eee1a2efda26ed2f09aab33ccdc40ef18f Feb 23 22:36:16 zx2c4: I don't see the "kconfig: use arm chacha even with no neon" at https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y - is it there, or are you planning to add it later? Feb 23 22:37:05 rsalvaterra: in the upstream kernel MBUS_ID is not modified Feb 23 22:38:00 Hauke: Oh, you missed the discussion. ;) Wait, don't merge that yet, I was just about to mark it as superseded, exactly to make it more clear. Feb 23 22:38:52 ok Feb 23 22:39:04 Actually, I already did. Feb 23 22:42:27 Someone was asking about Octeon and TZ settings. Ping that person ;p Feb 23 22:43:11 Hauke: I'll send a new patch which will include everything, three patches in logical sequence, enabling/fixing hardware buffer management and the IRQ storm I've been seeing for years on the Omnia. Feb 23 22:44:53 Hauke: If want to have a look at the result, meanwhile, here it is: https://github.com/rsalvaterra/openwrt/commit/a4da42b814e30f6a7b354e2418ba8486a9c82f2a Feb 23 22:45:00 Something is settng UTC to be UTC-3. I had to go back to -8 to read the correct time for EST Feb 23 22:45:03 Grommish: youre looking for Borromini Feb 23 22:45:25 Thanks pkgadd.. Ping Borromini then :) Feb 23 22:45:36 Or I'll remember later since he's not on Feb 23 22:47:37 lipnitsk: yea, it'll be in there this week after the net.git sync Feb 23 22:47:52 okay, I figured it was some process like that - thanks Feb 23 22:48:09 zx2c4: I just did a minor push to add a note to the backport patch before my sign-off. Feb 23 22:48:17 For now just stick with the commits i put in there originally Feb 23 22:48:20 Ah cool Feb 23 22:48:34 just for posterity Feb 23 22:50:39 rsalvaterra: thanks Feb 23 22:51:00 as they have a Fixes tag they will probably added to 5.4 later anyway Feb 23 22:52:32 Hauke: That's my hope, but we'll still need the hardware buffer management backport for 21.x. The other two patches will probably become obsolete with a future stable kernel update. Feb 23 22:53:54 rsalvaterra: ok Feb 23 22:54:21 does anyone know why CONFIG_HAVE_ARM_ARCH_TIMER is not unset in generic 5.10 any more, but was in 5.4? Feb 23 22:54:25 lipnitsk: are we ready to have Hauke or blocktrron merge? Feb 23 22:54:45 blocktrron said he will by this weekend Feb 23 22:54:59 or by next week :) Feb 23 22:55:06 Bah, so much waiting Feb 23 22:55:24 Hauke: maybe you want to do it now so we can get it over with? :) Feb 23 22:55:33 Hauke: I saw that too. CONFIG_HAVE_ARM_ARCH_TIMER makes no sense on Cortex-A9, only A7 and A15, if I'm not mistaken. Feb 23 22:56:02 https://github.com/openwrt/openwrt/pull/3885 Feb 23 22:56:10 zx2c4: yes, we are ready. I polish things as they come to mind, but it all works, so just a matter of any feedback from core folks at this point Feb 23 22:56:17 zx2c4: Oh, the WireGuard merge? Let me get the popcorn… :D Feb 23 23:02:24 zx2c4: I didn't look closely into the wiregurad changes Feb 23 23:09:51 Hauke: all the more reason to press the green merge button! Feb 23 23:10:12 Big improvements, anyway. Finally using the upstream code Feb 23 23:10:51 rsalvaterra: why does the CONFIG_HAVE_ARM_ARCH_TIMER make no sense on cortex A9? is this not needed for the arm global timer? Feb 23 23:12:05 Hauke: Different things. The global timer is shared by all cores, the architected timer is introduced with A7/A15 and is a per-core timer. Feb 23 23:13:51 zx2c4: I don't know if you want to push for cherry-picking the backport into 21.02, but 5.4 will eventually be deleted from master with no planned 5.4 release off master anymore, AFAIK Feb 23 23:15:35 zx2c4: Otherwise, 21.02 will use wireguard-linux-compat Feb 23 23:15:56 rsalvaterra: thanks for the clarification Feb 23 23:17:47 FWIW, I'd *really* love to see 21.02 dropping compat for WireGuard. Feb 23 23:18:49 I can just open a 21.02 PR and see where it goes from there Feb 23 23:18:50 :) Feb 23 23:20:10 * rsalvaterra would also like OpenWrt to drop compat entirely. And a unicorn. :P Feb 23 23:31:04 Hauke: I'd prefer the backport in 21.02 rather than compat. Let's get this in master first and then we can do 21.02 Feb 23 23:31:46 So hoping that PR gets merged soon (today? now?) so that we can move onto next steps Feb 23 23:32:06 lipnitsk: oh great Feb 23 23:33:02 yeah I can wait for now.. Feb 23 23:34:24 I do not have time before the weekend Feb 23 23:45:41 Hauke: did you see the fun with -ct firmware? uerr .... been busy on other task myself. Feb 23 23:46:26 * enyc ponders what https://github.com/greearb/ath10k-ct/issues/178 means for OpenWRT 21.02 .... switch away from -ct firmware? try to get it figured out further? Feb 23 23:46:35 03:53 < Namidairo> using the same hardware on my archer c5 and I don't see the same thing Feb 23 23:46:38