**** BEGIN LOGGING AT Fri May 29 02:59:57 2020 May 29 06:30:38 blogic: Thanks for remembering, I will take a more detailed look during the weekend. From first glance it looks very interesting May 29 06:38:53 My use-case is to recognize all devices belonging to a USB-devices (like an LTE modem). Right now I am doing it manually using a not very beatiful (but very functional!) solution May 29 06:39:43 Having some other tool collect all devices and export it would be ideal, and udevadmd looks like a very good fit May 29 06:42:34 I think I have found my summer project :) May 29 07:20:00 kristrev: I plan to add usb probing the next days May 29 07:20:11 so that you can get a list of the USB topology aswell May 29 07:20:15 is that what you mean ? May 29 07:23:42 blogic: Hm, I think so. What I do in my own code is to find/detect all the devices (/dev/ttyUSBX, cdc.wdmX, ...) that belongs to/is created for one USB device May 29 07:23:57 yeah May 29 07:24:07 that is what i plan to add May 29 07:24:34 great, looking forward to test (and throw out custom code) May 29 07:25:30 thanks a lot for your effort May 29 07:31:57 Would usb modeset tools has already chewed dataset available? May 29 07:33:49 do you mean modeswitch? May 29 07:34:15 Ah, yeah.. May 29 07:35:15 I think modeswitch just recognizes VID/PID and then sends a magic command to the device to trigger the switch May 29 07:36:40 Regardless, the "map" of a USB device has to be built dynamically and for each device. For example, Quectel-modems export different number of devices/endpoints for the same VID/PID May 29 12:22:27 hm, wireguard is broken May 29 12:22:34 when adding multiple peers under same interface May 29 12:30:30 only one peer entry gets created May 29 12:34:05 is that a valid configuration? May 29 12:36:28 yes May 29 12:36:36 even luci supports it May 29 12:36:43 its not generating the config correctly May 29 12:37:23 https://pastebin.com/raw/facFx6SB May 29 12:37:25 kyes edited out May 29 12:37:49 it just doesnt create the second peer May 29 12:40:32 works for me i think? May 29 12:40:47 this is latest master build from the otehr day May 29 12:41:55 https://pastebin.com/raw/XtWpP3YK May 29 12:41:57 oh. May 29 12:41:57 theres full config May 29 12:42:11 https://paste.debian.net/hidden/35ac2e72/ < that's on 19.07.3+ but that won't serve you then May 29 12:43:06 wireguard 20200506 on stable. May 29 12:43:15 is master already past 0506? May 29 12:43:46 how to check version? May 29 12:45:21 [ 21.160907] wireguard: WireGuard 1.0.20200520 loaded. See www.wireguard.com for information. May 29 12:45:26 yeah so newer May 29 12:45:33 its likely not the issue with wireguard May 29 12:46:10 hm maybe it is May 29 12:46:16 figured it was a script issue May 29 12:46:37 root@rooter:/etc/config# wg set wg1 peer xx allowed-ips 192.168.10.5/32 May 29 12:46:47 then not in showconf May 29 12:49:37 adrianschmutzler: I'm reading the lzma-loader code, trying to make sense of a few things. One thing is obvious though: we have multiple copies of that code in several targets, that seems like a very bad idea. See for instance c57e182b560e4c93377270d470600095c2b580fe - would it be possible/desirable to consolidate all these copies as a single package? May 29 12:51:03 just checked and it creates the appropriate config file May 29 12:51:11 wireguard just does not play nice May 29 12:51:20 weird May 29 12:51:35 f00b4r0: I've asked myself the same question a long time ago, but it looks like the lzma-loader has been adjusted for local demands of the targets in several ways (at least that's what I remember). Since I lack the deeper understanding and it would have been quite some work, I stepped back from it without checking demand/acceptance for that change. May 29 12:52:03 it originaly was introduced for ar71xx iirc and then copy-pasted to wherever it was needed May 29 12:52:38 and its a critical pice of code, so likely nobody feels like consolidating it due to the possible regressions in targets without test hardware availability May 29 12:52:40 but also I think Noltari also threw out some stuff for bcm63xx ... May 29 12:52:49 ... recently May 29 12:52:55 jow: indeed. And then "fixes" here were propagated or not, which may lead to problematic divergences May 29 12:53:32 most of that code can be used across archs. The key differences should be in the linker scripts, presumably. May 29 12:53:41 and e.g. ramips contains specific code for the mt7621 board May 29 12:53:59 didn't it also contain register writes and stuff? e.g. to configure switches early May 29 12:54:11 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/image/lzma-loader/src/board-mt7621.c May 29 12:54:17 we're going to need it on ipq40xx for RB devices as well, as it seems (although I still don't understand _why_ exactly we need it, and I'd really like to) May 29 12:55:07 jow: there are some board-specific bits here and there, but the bulk of the code belongs to (surprise) lzma decoding and kernel loading. That's pretty arch-indep May 29 12:56:00 adrianschmutzler: yes, it wasn’t printing anything for bcm3380/bcm6362 May 29 12:56:39 imho it would make sense to consolidate the arch-indep bits, so that fixes to this code can benefit all archs May 29 12:56:42 noltari: ah, wasn't aware you are here under the same name. May 29 12:56:53 what kind of fixes we're talking about here? May 29 12:57:01 this wireguard stuff is straaaaaange May 29 12:57:03 why does it wnat to fight May 29 12:57:04 lzma decoding broken on some devices and on some not? May 29 12:57:23 noltari: how would you think about a generic lzma-loader, since bcm should be a partially different implementation again May 29 12:57:35 jow: this ranges from very basic stuff like eeeee885fb497bb07041575b78fca4063145edb9 May 29 12:57:51 blogic: Are you aware of bug FS#3018, probably caused by your commit b5516603dd90? May 29 12:58:47 on another host running 20200520 i can create multiple peers under same interface May 29 12:58:49 same config May 29 12:59:08 jow: or 320aa306092383e7d2eaa37a2ce6fdca03186069 which is a typical kernel-wide change May 29 12:59:25 and that's only looking at ar71xx history May 29 12:59:33 I'm sure I can find similar examples across the various copies May 29 12:59:36 adrianschmutzler: it could be possible, as long as we provide a minimum customization for uart May 29 12:59:51 f00b4r0: that does not look like extreme diversions to me though May 29 12:59:59 it does not. But it adds up May 29 13:00:13 so do regressions May 29 13:00:23 and having multiple copies will only increase the risk May 29 13:00:53 $ find target/linux/ -name loader.c | wc -l May 29 13:00:54 4 May 29 13:00:54 jow: well sure. But hardware and kernel aren't frozen in time, so either way at some point you have to move forward and take risks May 29 13:00:58 looks mangeable to me May 29 13:01:34 it seems it even was considered at a time to consolidate, seeing target/linux/generic/image/relocate May 29 13:01:47 (i don't know if that's even used) May 29 13:03:20 and at the very least, I don't see how you would introduce regressions by consolidating arch-independent code. If there are arch divergences in that code, they can be handled with #ifdefs if no attempt to even try a single option is desired May 29 13:08:51 fml May 29 13:08:55 apparently one of the keys was bad May 29 13:09:14 one of the downsides about wireguard, fucking silence May 29 13:12:41 well that was a tremendous waste of three hours May 29 13:12:43 adrianschmutzler: let's try a lower hanging fruit meanwhile: thoughts on not hardcoding kernel/root in dts for rb devices? May 29 13:13:36 f00b4r0: cannot help you there ... May 29 13:13:42 why? May 29 13:13:59 cause I don't understand it well enough to judge May 29 13:15:47 well it would probably involve breaking forward upgrade path. If's that's a no go, then problem solved May 29 13:16:13 what's "forward upgrade path" for you? May 29 13:16:16 that's why I suggested doing it now, while we're bootstrapping RB to ath79. We don't need to carry old ways over IMO. May 29 13:16:56 a board that uses the current hardcoded partition scheme would not be directly upgradable (or at least not without hackish workaround) to a board that uses a "firmware" partition May 29 13:17:35 so, this affects "just" ar71xx to ath79 then? And I assume, upgrading with -n would still work? May 29 13:19:33 hmm. I'm reading package/base-files/files/lib/upgrade/nand.sh. It seems this was never meant to handle the dynamic split case with a top "firmware" partition May 29 13:19:41 maybe there's a good reason for that? May 29 13:22:06 who's the resident nand expert? rmilecki ? :) May 29 13:29:26 f00b4r0: i won't find time today to look at it i'm afraid May 29 13:29:33 f00b4r0: ping me on Monday please May 29 13:38:14 rmilecki: sure, will do, thanks. May 29 13:40:38 adrianschmutzler: re #3026: if I may suggest: I think there's no reason to delay this PR any longer. The submitter has really put a lot of effort to implement all the requested changes. The problems he's seeing now are probably common to all ath79 rb targets, I see no reason to penalize his PR and I think it would be a good signal also to encourage further contributions from him May 29 13:44:08 a rust hello binary for ath79 is 250KB just tested for fun May 29 13:44:26 f00b4r0: I totally share your view on the necessary reward here, but I really hesitate to enable TARGET_INITRAMFS_COMPRESSION_LZMA May 29 13:45:33 despite, I remembered that building with all kmods (buildbot config) will increase the kernel size, so the author will at least need to test that, so we don't deploy a build that fails on arrival May 29 13:46:00 makes sense. May 29 13:46:15 Let's ask him to test 4.19 without TARGET_INITRAMFS_COMPRESSION_LZMA May 29 13:46:45 though I'm also really astonished about his commitment May 29 13:46:58 and we should definitely reward that May 29 13:48:09 yeah he's been really cooperative. And if he contributes further down the road I expect his contributions to be of quality right from the start May 29 13:48:50 has xback also offered testing for that one? cause I'd like him as another pair of eyes on the device implementation as well ... May 29 13:50:28 didn't the author try without TARGET_INITRAMFS_COMPRESSION_LZMA and state it won't work on 4.19 without? May 29 13:50:57 i can't remember if he did, that's why I asked :) May 29 13:51:34 and he just confirmed it didn't May 29 13:51:43 thanks for you review-activity btw, otherwise I think this would have never been merged May 29 13:52:00 np yw May 29 14:06:13 adrianschmutzler: err, to me CONFIG_BUILDBOT is something entirely different. It tunes the build process, it doesn't provide the default seed or the default configuration May 29 14:07:09 if I check the option "Set build defaults for automatic builds", it will automatically select all devices on the subtarget and check a lot of stuff like building all kmod, target-specific packages etc. May 29 14:07:41 but I'm doing it in the menu, not by editing any config file May 29 14:08:07 (and typically, I'm deleting .config beforehand to get rid of old settings) May 29 14:08:15 yes, but that's all it does May 29 14:08:40 well, that's what needed. because the relevant thing are the selected kmods May 29 14:09:17 don't know how big the effect will be on ath79 though May 29 14:10:04 that's /not/ all it does, sorrry May 29 14:10:49 anyway, it's enabled in the default config.buildinfo so the net result will be the same :) May 29 14:12:00 what's enabled in the default config.buildinfo and what's default for you? May 29 14:12:27 I'm not sure I understand the question? May 29 14:12:44 just to clarify, the procedure I described on the PR _is_ what the buildbots do May 29 14:13:02 they update and install feeds, grab the .config seed and run defconfig. May 29 14:16:34 and where is the .config seed grabbed from? May 29 14:18:08 I'm not sure. That's a question for jow I suppose May 29 14:18:26 I assume it's manually put somewhere May 29 14:18:33 it's the dlconfigseed step in the buildbot process, if you're curious. May 29 14:19:25 however, if you don't get a seed from somewhere, but just start with a fresh clone, no config_buildbot is set and it won't be set by defconfig May 29 14:19:32 it's actually followed by a quick addition of the actual target in the 'newconfig' step, then defconfig; if'm I'm thorough. May 29 14:19:39 I assume that CONFIG_BUILDBOT is manually put into the initial config.seed May 29 14:20:02 https://pastebin.com/tLJ1Yamb May 29 14:20:07 that's why I suggested to download config.buildinfo, which is a seed suitable to reproduce an identical build. May 29 14:20:27 jow: thanks :) May 29 14:20:48 well, if you did suggest that download, then it obviously will work, I didn't read that May 29 14:21:22 but without that seed, the build would be useless May 29 14:21:41 adrianschmutzler: here https://github.com/openwrt/openwrt/pull/3026#discussion_r432495717 May 29 14:22:30 ah, okay, then it's fine, overlooked that May 29 14:22:37 np May 29 17:05:41 f00b4r0: my understanding about why a loader is needed for RB devices: It seems that RB bootloader can only execute ELF files directly (no decompression possible) and there isn't enough flash space to store a uncompressed kernel. so a small piece of uncompressed code is used to extract the actual kernel. May 29 17:46:07 ah shit, missed him May 29 17:46:17 there's plenty of flash space to store an uncompressed kernel May 29 17:51:14 gch981213: thanks for the input. However it makes no sense to me: there's plenty of flash space to store an uncompressed kernel May 29 17:51:35 also, the problem appears to be exacerbated when booting from initramfs (but not when booting the same image from flash) May 29 17:51:41 it feels like a boundary crossing issue May 29 17:54:57 f00b4r0: what problem? my IRC log was cleared a moment ago. May 29 17:55:22 gch981213: RB devices failing to boot too big _images_ (kernels as well?) May 29 17:55:47 gch981213: see for instance here: https://github.com/openwrt/openwrt/pull/3026#discussion_r432600422 May 29 17:55:56 can't netboot, but can boot from flash May 29 17:55:58 same image May 29 17:56:41 in fact if it were a flash space problem we wouldn't need to compress the initramfs as well, would we? May 29 18:01:48 anyone else getting alignment exceptions on ipq806x? May 29 18:02:38 I have 2 R7800 and only one of them is throwing alignment exceptions with the same firmware: https://gist.github.com/Noltari/6219986e2dd2141dd54c7af00e97325b May 29 18:05:22 f00b4r0: I think we don't need the loader if we can give bootloader an load address. Otherwise a piece of relocate code is needed. (under target/linux/generic/image/relocate) May 29 18:07:09 noltari: compiler bug ? May 29 18:11:02 gch981213: well I'm not sure about that. The bootloader finds the kernel on its own and then loads it May 29 18:11:36 i'm starting to wonder if what we're seeing is a side effect of kernel2minor doing something stupid in fact. May 29 18:11:56 then again, it's all commented in Cyrillic :/ May 29 18:13:35 i think i'm going to rewrite that piece of garbage :P May 29 18:15:34 :D May 29 18:16:01 and add some comments in hindi or sth. May 29 18:16:25 I'll comment in my native french, with proper slang for style, of course :D May 29 18:19:06 'pauv' con ce russe là'? ;) May 29 18:19:23 :-> May 29 18:20:04 it's a good thing google translate exists May 29 21:24:25 I don't understand how kernel-bin picks the kernel. How do I go to make a target use a raw elf kernel? **** ENDING LOGGING AT Sat May 30 02:59:59 2020